(NOTE: The original post has been slightly edited to improve readability)
In a perfect world, we all strive for some kind of development process, be it Waterfall development, Prototyping, 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 behind it could be summed up by the phrase “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 an eager marketing department and some press releases in the mix.
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 am 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’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.
Focus
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 counterproductive 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.
Solid tips from Bryan Du Preez. Don’t forget to share guys!
Related Articles:
