Chaos theory suggests small changes in initial conditions can result in vast differences in the future.
It implies that massive, unpredictable events can be directed with a few small early changes in the right place. While this is a simplification, it’s a useful one when it comes to enterprise software development.
Consider how many times a tiny decision has snowballed into a major situation.
It rarely seems like a significant decision when it’s made, but by the time developers spot the issue it’s an avalanche that threatens the entire project.
It seems impossible to avoid those random setbacks. After all, no developer can see the future.
In practice, though, developers can head off the majority of unpleasant surprises by embracing and preparing for chaos.
Why does Chaos happen?
The seeds of chaos are planted by dangerous mindsets that might seem like positives in the beginning: faith, optimism & bliss.
In this context faith refers to a belief that all initial assumptions were correct.
It’s an unrealistic confidence in one’s own skills, thinking experience means the team has all the answers and there’s no edge case they may be missing. The truth is that no one can foresee every potential problem.
Good developers are always open to learning and overcoming their limitations.
Optimism is general feeling that the easiest, most fluid path will cover 99% of situations. It’s a mistake to assume that a basic implementation is enough to cover most scenarios.
Operating under the belief that nothing too disruptive will happen removes the incentive give to create functional contingency plans.
If ignorance is bliss, the reverse is true as well. Bliss here describes a cheerful lack of understanding of the technology stack, the project’s scope, and business requirements.
Every tool has strengths and weaknesses. Developers have to know those weaknesses to compensate for them.
These mindsets invite chaos into the development process right from the start. Left unchecked, they increase the risk of a major oversight.
There are ways for developers to stay on top of potential chaos without knowing exactly what form it will take. Start by prioritizing evidence over faith.
Turn the unknown into the known through a solid discovery. Best case scenarios are rare in software development industry; anything that can go wrong, will. It’s better to be over-prepared than caught off guard.
Don’t make assumptions without strong supporting evidence.
If no evidence is available, commit to a course of action as late as possible to allow room for change.
Practice “inversion thinking” during development. Game out the potential hazards ahead of time. What are all the negative things that can happen? How likely are they?
Brainstorming worst case scenarios provides the chance to create viable contingency plans.
It’s also a good idea to communicate thoroughly with the product owner about the impact of certain requirements.
Make sure everyone knows which options are riskiest. Provide a full risk-benefits analysis to guide product owners in making decisions about feature priorities and change orders.
Rolling with the Punches
Be alert for early signs of chaos and head them off at the pass.
Defensive programming is key. Test early and often. Every time a bug is found, write a test against that bug.
Knowledge is the currency of success. Have a clear understanding of the requirements before writing a single line of code.
Always understand one level below the level being worked on. Never stop learning. The technology steamroller is constantly moving, and it can roll over those who don’t keep up.
Finally, remember this: developers aren’t paid to write code (although they do). Developers are paid to think and solve problems. Don’t just patch based on assumptions.
Work through the actual problem to create a solution aligned with the products owner’s business requirements and stack technology.
A problem half stated is a problem half solved, so understand the actual problem from its roots before taking action.
Stay Alert, Stay on Schedule
Pessimism in development allows optimism in production.
Controlling for the mindsets that feed chaos leads to fewer and more manageable disruptions later in the game.
There’s always an element of chaos in software development, but the best teams know how to channel it into better software. Schedule your free consultation to hear our plan for your next project!