2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
(c) 2024 To Be Agile
Would you pay $10 to spin a roulette wheel with a potential payoff of a million dollars? Maybe so but you probably wouldn’t do it if you had to win 100 spins in a row, right?
Risk is part of life; we have to take them but we want our risks to be calculated. Yet when it comes to software development we often set ourselves up to play “all or nothing”.
On most projects where integration happens at the end of the project we accumulate risk and it continues to accumulate throughout the project. Each line of un-integrated code holds potential risk. We set ourselves up so that every feature has to work on order for any feature to work. One tiny bug can keep the entire system from working. Not even the most hard-core gambler would take a game with those kinds of odds yet we do it every time we embark on a waterfall project. No wonder that most software projects are not successful!
There is a better option.
Integrate as you go. As soon as you have a new bit of functionality that compiles, integrate it, first on your local machine where your core unit tests run, and then on a build server where all the automated tests run. Do this several times a day and you will always have a buildable system. This drops your risk of being able to ship something to close to zero. Maybe you won’t get every feature done by the ship date but you’ll have something and if you plan well then what you’ll have are the most important features.
Maybe this seems obvious to you but in my experience the biggest companies building the most complex systems do not do this. Waterfall projects are still the norm and “integration hell” as we’ve called it is the inevitable conclusion of a waterfall project.
If you still write code the old fashioned way where you have to completely implement a feature before you can even compile then you may as well come to work blindfolded with one hand tied behind your back. The power of your computer is idle, unable to check you work, help you with syntax or verify the code you just wrote will “play nice” with the rest of the code in the system.
We are software developers. Our job is to automate business processes and the first place we should look is to our own work! Don’t set yourself up to fail. Take little wins as frequently as possible by integrating as you go. It will give you confidence and momentum and you will always have something to show for your efforts.
Previous Post: « Integrate Early and Often
Next Post: Solutions Thinking »