Not only am I a huge fan of                 software design patterns, I'm also strongly supportive of process             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, "Software Is 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 Scrum                 development 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."

Fragile Programming

                As I mentioned in my                     earlier article, Fragile Programming is an important element of the Delicate                 software pattern. It is related to                     Agile programming, 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.

                Testosterone-Driven Development

                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.