A Lesson From Kalashnikov
November 26, 2008
Ok, don’t panic, we haven’t gone gun crazy, but we picked up an interesting analogy today from one of our business sponsors. It went something like this : “The Kalashnikov AK47 only has 13 moving parts and is the most successful weapon ever invented, remember this when you start designing your next software delivery. Keeping things simple is the key to building something that is reliable, will accept the abuses imposed by our operating environment and will stand the test of time”.
This is a more colourful way of repeating our mantra “Keep IT Simple Stupid”. Applying this ‘KISS’ principle has enabled us to deliver robust and reliable software into a production environment over and over again. More importantly that software is Maintainable and Extensible - qualities that are often forgotten by the project team, most of whom have no intention of hanging around after ‘Go-Live’.
If I were to pick the biggest challenge we have faced on our current project it would be the transition of project to ‘Business As Usual’. Despite a large comms budget and endless workshop sessions in an attempt to engage the future custodians of our systems it has been an uphill struggle. Our team has suffered less than others, despite being one of the larger elements of the overall program, and the one thing that has made the process more palatable is the fact that we have tried to reduce complexity at every opportunity. If I were to list the top 5 tips for ‘Keeping It Simple’ they would be :
- Don’t accept the early version s of the solution architecture without thorough review. It has probably been conceived from a 60,000ft view and is likely to be over engineered. Review it, Challenge it, Simplify It
- Any steps that result in writing less code is good, as long as it is not at the expense of true requirements. Less code means less testing and fewer points of failure.
- Keep the number of ’systems’ involved in an end-to-end process as few as possible. Each step in the chain is a potential point of failure, and with different systems using different logging and exception mechanisms means the process of diagnosing issues becomes a phorensic excercise of huge proportions.
- Standardize your development process and avoid ‘Specialists’. Each member of your design, development and testing team should be as interchangeable as possible. They should subscribe to a common set of goals and processes, and should collaborate regularly. If a team member is working in isolation for long periods of time you can bet he/she is building a problem.
- Integrate small chunks of functionality at a time. It’s much easiler to resolve issues and refactor components if you and introducing small changes to the code base regularly rather than attempting large integrations. Your options are severley limited if you find problems after a large integration (in terms of time and resources), especially if a signisifcant redesign is needed.
