Monday, February 7, 2011

Surviving the Wild West Development Process

Now in a perfect world, we all strive for a some kind of development process, be that: Waterfall development, Prototyping, all things Agile or whatever process the CIO / CTO /CEO got sold on by some consultancy.

But in the real world what sometimes ("sometimes" being quite often actually) happens is:
What I like to call the Wild West Development Process (WWDP)... the main principle is basically “promise first and ask questions later”.

Getting started with WWDP is pretty simple:
1. You need someone, somewhere in a place of power and influence in your organization to promise software by some unachievable date.
2. Add in a eager marketing department and some press releases…
3. stir and leave to simmer.
4. After simmering for a while inform the software development department that they must have something, that does "stuff" and the release date can not change.

I am not sure if this is a result of a immature IT industry in my country, but I have spent many years in environments like this. It even seems to find me in the most unlikely employers, the large corporate organizations like insurance and banking institutions, where general red tape and corporate processes should limit this. I started my career in one of those “startup-sell-information-tech-and-business-processes-to-anyone-cheaper-than -anyone-else-type-consultancies". Which means every project was driven by WWDP so I started in the deep end, and for about 4 years I knew no other way of developing software. I currently find myself in another one of those projects. I'd like to share some points that I found helpful in actually delivering some software in unimaginable unmovable deadlines.
(to be fair some of these are in the standard development processes mentioned earlier, maybe with just different priorities)

Pick the right developers
Not everyone can cope in this environment, knowing your staff / team is very important: late nights, constant crisis, constant changes and bucket loads of pressure and stress aren't for everyone. Some people thrive, some survive and run for the hills after, some just end up whimpering in the corner and need to be replaced (which is a disaster).

Have the developers involved.
Projects like these don't allow for the usual requirements / design / develop / test paradigm, all of these functions run concurrently. Having the developers know as much detail as the architect, analysts and testers is vital. Developers will have to make decisions affecting the architecture and business functionality constantly, if everyone has the same picture you'll save time.

"Prototype" early
I say "Prototype" in quotes because unlike an actual prototype there won't be time to throw this code away. This "prototype" is to have the system in it's entirety up and running very early in the project. It can be a "shell" but having it up means testing can start early even if it's just the basics and no business functionality. Since there are no real requirements, make sure the design caters for adding them as they are defined.

Integrate early
If the system has any integration points, between systems, teams or external parties, make sure this is also in the "Prototype Shell", integration always takes longer than you think, having the interfaces up and available to test is crucial.

Keep track of communication
When the shock of not meeting an unachievable deadline kicks in, someone will always look for a scapegoat, always keep at least an email trail making sure you aren't that goat.

Automated builds and deploys
The standard agile practice of continuous integration is as important as ever, and even if you skip other parts of you software development cycle this is something that should not be dismissed.

With hundreds of things that need to happen a matter of days or weeks, it's very easy to try do 6 things at a time. Don't. Micro manage your time and tasks and focus. It's easy for us developers to start a task, see something, change something and lose a day which you don't have in the first place. If you have to, have someone keep an extensive list of "TODOs" that can be used in the cleanup phase.

Clean up
Once the unachievable deadline has been met, before starting the next phase, have at least one "cleanup" release. This cleanup phase should add very little or preferably no new functionality, but will allow for design and development decisions made in haste to be reviewed and refactored.

Pace Yourself
No matter how super human you may think you are, all of us have a limit to how many hours we can keep going. At some point you are actually being counter productive and a couple more hours sleep will actually help the project a lot more.
Know your limits.

I am sure there are a couple more, but currently being on a WWDP project I need to re-focus and leave that for the clean up phase later :)


  1. Awesome! Its good to know we are not alone! :)

  2. Huh, not only I am not alone, there's a bunch of us!!

  3. Lol perfect timing of this post as just today I've reached such "unachievable deadline". What is really p*ssing me off with WWDP is that the clean up phase will make this project longer than it would be with realistic deadline.

  4. Thanks for the comments:
    Yeah this seems to be all to common, you are not alone,
    @anon: That is unfortunately often the case, if they just gave us a little longer on the initial deadline, we'd save so much more time in the long run.

  5. He he - Wild West kind of implies a happy East somewhere, where developers and architects sit and drink tea, discuss requirements, and say things like, "We can't possibly do that by then. We're going to have to get business to move the deadline back on that one. Lunch anyone?"

    If anyone finds such a place, let me know.

    Good article Brian!

  6. Really enjoyed.
    I have the very same situation.
    But, what to do when during WWDP your manager demands application to be sent to QA which involves additional time for tasks like:
    - documentation
    - training QA (because it is completely new software)
    - release

    Generally, how do you defend yourself and the team from manager who doesn't understand that development is unbelievable race and every hour is precious, so he keeps insisting on his dogmatic principles to be applied?

    In WWDP everything is about time and keeping mistakes at minimum. That's why I think all your points are completely valid.


  7. When picking the right developers, avoid, avoid, AVOID any developer that seems to value personal well-being, fair compensation, have a marketable resume or any knowledge of labor laws in any shape or form.

    They will be the first to jump ship and they will be right.

  8. Enjoyed the reading. Nicely summarized typical software development process in disfunctional organizations (which is most of them).
    Like the scapegoat technique - the noobs should take a note of it to spare themselves of learning it in practice.

  9. Good write up man :-)

  10. Thats exactly the startup demands are, nicely summarized. I was in those situations past 10 years, i have my options list overtime i start a project...

  11. Very useful stuff here you describe.

  12. I like this excellent post which has full of informative stuff. Also impressed with creative writing. Much appreciate the author who takes time and shares a wonderful post with us.


Popular Posts