9 Tips on Surviving the Wild West Development Process

This is a post originally published by our latest JCG partner, Brian Du Preez from the Zen in the art of IT, who we are really thrilled to have on-board. Bryan talks about Surviving the Wild West Development Process, a quite unorthodox, yet common development process. Let’ hear his suggestions on how to survive on such an environment.

(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:

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


nine + = 10



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close