The formal term for the
waterfall
model in software development was introduced in 1970. These days an
iterative
approach is more popular for its many benefits including risk reduction, etc.
These are real-world, formalized methodologies that have been acknowledged in
the industry. However, there are other informal methodologies that run rampant
in our industry that most of us who know what we are doing mock and criticize
behind closed-doors while management informally dictates them under the guise of
a real process model. Because of its popularity and high frequency, this
developer has decided to give one such model a formal name: the duct taped
soccer ball model. In this article I hope to become the pioneer of
formalizing this model, although I certainly do not deserve credit for its
existence and popularity. Not even the
Daily WTF could claim
credit for this debacle of a methodology. Nevertheless it is my intent to define
this model as it exists in the real world as it truly exists in its secret,
cult-like society where individuals who propagate its existence are still
floating down a river in Egypt and will deny its existence until the end of
silicon as we know it.
The duct taped soccer ball model is a term I decided to use based on an
analogy. Many years ago, I watched as my younger cousins would play soccer in
rural Tucson, AZ. Every so often the soccer ball would leave the boundaries of
the grassy yard into the desert full of cholla and other cacti which would pop
holes in the ball. The inventive children would use their father's duct tape to
patch the hole(s) in the ball, continue to play, and repeat the process over and
over again as the ball would continue to gain more holes and continue to be
covered by an increasing amount of duct tape until such time that the soccer
ball was no longer a soccer ball as we know it. Instead it was a misshaped,
somewhat-spherical ball of duct tape with a flat soccer ball hidden somewhere in
the middle. Much like a program written without a plan by programmers that don't
care about neatness or organization and managed by an organization focused on
selling the misshaped, unmanageable code that is the duct taped soccer ball.
The methodology itself is difficult to describe. It is true chaos. Almost as
complex as the chaos theory. If I were forced to define its phases...
1. Coding
The first phase in the duct taped soccer ball model is to have a few
quick conversations about a given project, possibly a flow chart or two,
perhaps an email, and then immediately begins the process of coding.
What is actually being coded? Typically there is a vague idea of what
certain screens should look like, and idea of where to get and put the data,
and possibly some generated code and third party controls to throw in the
mix. Tying it all together is a process usually done in phase 2 and phase 4.
Although usually there are a few team members that copy and paste code from
sections of other related applications and try to retro fit the code into
their given problem space. If any code exists in the new project, that too
of course can be copied, pasted, and retrofitted.
2. Debugging
Forget compiling all together. This phase is where the code written is
often run by the developer in Visual Studio by clicking F5 immediately after
coding. Next, the developer figures out that the code won't compile and
makes the necessary syntax changes so that the next time they press F5,
hopefully they won't have any more stupid compiler errors. Nostalgia for VB6
is sometimes present in this phase because VB6 didn't really have a
compiler. Compilers are stupid and its all Microsoft's fault. This process
is repeated until the application runs successfully in the debugger.
Optionally, if an exception is encountered, the developer may step through
the code to figure out why. Usually, this is not important and a try...catch
block is placed around the offending code (with nothing in the catch block
of course) so as to not offend further by any exceptions leaking to
the UI or other developers trying to debug in the future. Exceptions are bad
in the duct taped soccer ball model and need to be hidden at all costs.
3. Confusion
In this phase, the developers get together and try to figure out why the
application isn't architected well, isn't working as planned, isn't on
schedule as planned, and the customer doesn't like the beta
application..because there really never was any formal plan even though the
contention may be that there actually was a formal plan. So a new plan is
put in place that covers the 80/20 rule where 80% of the existing code (a
flat soccer ball surrounded by duct tape) can hopefully be salvaged. If not,
1/2 of the code will simply be regenerated because nobody like to write code
manually these days. That's for losers.
4. More Coding and Debugging
In this phase, the confusion is now clarified at least to the point of
being a muddy pond rather than an actual mud ball. Since the project is
already behind schedule, more developers are brought into the project
because bringing in more developers to a late project will fix everything.
We all know that to be true. Coding at this point involves copy, paste, F5,
fix compile errors, F5, repeat, run, test, copy paste, fix compile errors,
F5, etc. This is not a hard and fast rule; after all, the duct taped soccer
ball model is one that promotes flexibility within an organization.
Therefore, any order of "copy, paste, F5, fix, repeat" can be applied. Of
course if that is not working out well, you can take a step back to phase 3:
confusion.
6. Release to Production
Once the project can compile and the developers have run a few quick
tests, it is time for an RTM build. This is self-explanatory and it should
not take more than a few minutes to do a build and release. Did we miss
anything? No, I don't think so.
7. Debugging and Testing
OK, so we did forget some things in our phases, but that's OK we can just
do some more debugging and testing until the problems disappear. This
includes adding more try...catch blocks with the catch doing nothing in the
code.
8. Re-release to Production
Do a build and ship it.
The real benefit to this entire model comes after deployment. After
deployment when problems in the system are identified, instead of truly fixing
the problem, your organization has the flexibility to use a duct tape
solution! Rather than fixing problems the right way, a more cost effective
approach (usually because it takes far less time) is to cover up the problems
with programmatic workarounds while hiding the root causes of real problems and
piss poor design. This is self-explanatory to many people. If you don't
understand what I'm describing at this point, then that is actually a good sign.
The duct taped soccer ball approach has many "benefits" in the eyes of
managers who adopt it. First, it provides the illusion of being cost effective.
You are probably in the business of selling software or writing solutions for
your company, and nobody wants to waste money on documentation and design work
up-front, after all we are paying developers to develop things, not write novels
and draw pretty pictures. Second, without any sort of paper trail, anyone can
point fingers at anyone else for failures! That kind of flexibility is important
in an organization. Furthermore, most managers want the option of
selective amnesia - this methodology provides that feature and is perfect
for breeding this behavior due to its fast pace and lack of a paper trail. In
future writings I hope to clarify more of the processes involved in the duct
taped soccer ball approach. Comments or additions are welcome, but remember this
is not a wiki.
