Not only am I a huge fan of software design patterns, I'm also strongly supportive ofprocess in software. Process makes us strong. Process enables us to achieve highly metric-driven quality levels. Process allows us to attend meetings throughout every day, ensuring that any coding time we get will be that much more intense because it is necessarily so short and focused. And finally, process allows us to draw pretty charts and graphs on endless presentations.
Or, as I like to say it every morning when I wake up, "SoftwareIs Process." For without the process, where would software engineers be but in their offices, cranking away code, pretending to be productive?
Now that people have had time to understand and incorporate the important patterns I discussed in my earlier Male Pattern Boldness article, it seems high time to tackle the larger topic of Software Processeseses. The field of Software Methodology is rife with theories, names, buzzwords, and descriptions that improve our tawdry geek lives constantly by letting us focus on that which makes us most productive: studying and then trying to implement completely new software processes to attempt the same job that we could have been actually doing in the meantime.
First, here is a historical perspective. Traditional software implementation was a rather simple and straightforward process, resembling something like the following:
Figure 1: Comprehensible, and therefore wrong, software process.
But this process was flawed by its inherent simplicity; if everyone could understand and follow it, what hope did the industry have in creating more meetings and process documentation? Changes were suggested for this methodology, resulting in more comprehensive models like this one:
Figure 2: More complicated, and therefore better, software process.
Eventually, some rogue elements of the community came up with a different process model, based on fundamental programming philosophies:
Figure 3: Simplified Software Process (SSP) model. Pretty dumb. Incredibly popular.
But the field has been somewhat quiet lately, leading to more coding than is really good for us, so I feel motivated to introduce some of my favorite new process models into the community. There are obvivously more than I can cover in a simple article like this, probably deserving an entire bookcase of unread tomes, but these will have to do for now as I have to go brainstorm with my team in an offsite about how we can be more effective (this week's task is to come up with a mission statement).
In the Scrumdevelopment model, the focus is on short iterations and constant communication. The Scum model, however, focuses on the individual. In particular, each engineer works completely on his or her own, producing code at an alarming rate. Changes are integrated and merged willy-nilly, causing untold breakage due to the complete lack of communication. At each fault, the offending code, putback, and engineer are indentified as scum and are tossed out of the project (this step is called "Hack-n-rack"). The resulting code and team are thereby better over time, having weaned out the weak members through natural selection.
As it's inventor, Dr. Feen Bookle, PhD, Mrs, QED, JRE, said at its unveiling at the Conference On Terribly Important Academic Philosophies and Theories on Software Process Methodology Discoveries (CTEAPTSPMD), "Scum will always float to the top. Skim it off and you've got just the juicy bits left. Plus the bottom-feeders."
As I mentioned in my earlier article, Fragile Programming is an important element of the Delicate software pattern. It is related to Agileprogramming, which is typified by small development cycles that are designed to meet the reality of constant requirements churn. But in the newer, and therefore better, Fragile methodology, each iteration is started from scratch based on only the latest requirements. Instead of building upon the existing code base, which has presumably attained some amount of stability and robustness through its existence and evolution, Fragile projects rewrite the entire project anew in each cycle, thus generating brand spanking new products that adhere more closely to the latest whim of the client. This process results in software that is tuned exactly to what the client asked for, and the resulting instability of the code base can thus be blamed directly on the client, allowing a convenient excuse for the failing development team.
Conference Drive Development (CDD)
This brave new methodology, suggested to me by Charles Nutter, looks like it has serious potential. As anyone who has ever developed software and demos for a conference before knows too well, there's nothing like a looming keynote or session deadline to enforce good coding standards, carefully thought-out APIs, and integrated feedback from the larger community. Developers typically end up at conferences with completely spec'd out products that only lack for a smattering of documentation before being released out onto the masses like white cat hair on a black sweater. It's just that whole "Quality" part of the release process that drags it down for the next couple of years and keeps it from being an instant product reality.
With the increasing volume of conferences around the world, I see CDD as becoming more and more interesting. Products that hinge releases upon the mad rush of pre-conference development will be able to ship new versions every month, or even faster. Sure, they'll go out with bugs, no documentation, and a complete lack of testing, but the demos will rock!
Rabid Application Development
Rapid Application Development helped move developers from the more stodgy development processes of earlier decades when people were dumber onto quicker models of development, based on fast prototyping work. Rabid Application Development takes this a step further. Instead of using prototypes as ideas to help with future, more stable work, the prototypes are the product, and are checked in as soon as they are complete, or in many cases, sooner. The key to Rabid Development is to keep the engineering team going at such a frenetic pace in coding and checking in code that nobody, including the client, ever realizes what a complete load of crap they've produced. This model is used throughout most university CS courses and has become the default process basis for all homework assignments. It is also the mainstay of software startups everywhere.
Developed as a response to the Waterfall model, where software goes through various stages of development during its life cycle, the Cliff model leaps suddenly from the starting point (known as the Hairbrained Idea) to the end (known as the Product, but informally referred to by Cliff teams as the Corpse). These projects are generally executed overnight with several pots of coffee by developers with no social lives. They start from an idea in a chat message during a World of Warcraft session and result in the engineers checking in the Corpse by the start of work the next morning.
No output of the Cliff model has ever been useable outside of negative case studies, but interest in this approach persists by those engineers still lacking in better things to do at 2 AM.
Related to Object Oriented Programming (OOP) methodologies, the Oops system seeks to develop reusuable objects, but never quite makes it. Previous components are never exactly what they need to be, thus requiring that the functionality be rewritten from scratch, resulting in a general "Oops!" exclamation from the teams involved. But as all engineers know, and all managers hate, it's always more fun writing things from scratch anyway. The Oops methodology is the one most favored by all programmers.
Clean Your Room (CYR)
This methodology comes as a response to the Cleanroom Software Engineering process, which strives to produce software whose quality can be certified. Clean Your Room, on the other hand, takes a different tack, basing its philosophy upon the teenage kid tenet: "Why should I clean my room when it's just going to get dirty again?" In this process, the focus is upon implementing cool, new features (called Wall Posters after the typical decorations in most teenager bedrooms) and not on tests, documentation, or bug-fixes. The belief with these other traditional elements of software products is that as the software changes, tests would be obsoleted, documentation would have to be rewritten, and new bugs would be introduced. So what's the point in doing the work twice? All CYR projects are run under the theory that eventually, when the product is completely done, the other non-coding aspects of the product will eventually be seen to (hopefully by someone else). Since no CYR project has ever reached completion, this has yet to be proven in practice.
Like its namesake Test-driven Development, which is known for the requirement of engineers writing tests before code, Testosterone-driven Development focuses on testing first. But it does so in an an extremely aggressive manner, requiring every engineer to produce entire test suites, test frameworks, and test scripting languages for every line of product code written, including whitespace and comments. Engineers violating this contract are taken out back where they have the crap kicked out of them. Any code found to have bugs not caught by tests results in the offending engineer having to go three rounds with the project manager (with the engineer being handcuffed and blindfolded during the match). Finally, any bug found in tests will result in the engineer's body never being found again.
Expectations are high from this newcomer to the field, although to date none of the products using this process has left any survivors.
I realize that the above list is quite a small sampling of the many wonderful methodologies which are possible. But I hope you will try at least some, or maybe even all, of these out in your team, throwing the entire project into disarray every couple of years while you reinvent everything. If you find either success or complete abject failure in your attempts, I encourage you to write a paper, speak at conferences, and publish books on the topic. Then form a consulting company that helps other development teams try to adopt the same methdologies.
Software products are a journey. They aren't just about the code you see at the end; they're about the path taken to get there. And the paths not taken. And the signs on the road. And the maps used. And the gas station attendants asked for directions when you got lost. And the hikes through the wilderness when you ran out of gas. And the ceaseless talk radio that your parents played while you got carsick in the back all over your sister. Process is the car that gets you there; you just need to pick the right one, pay too much for it, and then build it from scratch first.