Posted by chet
on January 17, 2008 at 1:19 PM PST
Process, process, process. Process.
Not only am I a huge fan of
software design patterns , I'm also strongly supportive of process
Process makes us strong. Process enables us to achieve highly metric-driven
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
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
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
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
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
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
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.
Object Oriented Programming (OOP) methodologies, the Oops system seeks to develop
reusuable objects, but never quite makes it. Previous components are
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
Engineering process, which strives to produce software
whose quality can be certified. Clean Your Room, on the other hand, takes a different
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
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
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
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