Article summary
Though we all (hopefully) know the dangers of last-minute big-bang integration, large multi-team, globally-dispersed projects still fall into this trap all too often when crucial deadlines are looming.
Wanting/needing things to be done, despite the reality that multiple pieces have run past their expected/planned completion dates, does not warrant cutting corners. In fact, these times are where our scientific/engineering ethics tend to clash with our business ethics and create a very toxic environment for all.
Integrate Continuously!
When developed and applied diligently, Continuous Integration (CI) has proven itself time and time again to keep ever-changing code bases tame as they are evolving. It is especially fruitful when multiple teams are integrating multiple changes to add new features and fix defects identified along the way.
Kent Beck created Extreme Programming (XP) in 1999 to help the world of software development learn from the repeated mistakes in the past, with the desire to bring order to chaos that normally ensues in real-world projects.
Extreme Programming eventually led to the birth of the Agile movement, which is now practiced by tens of thousands of companies worldwide today. It has also been found that many of the principles of Agile, defined in the Agile Manifesto, are more widely applicable to all forms of engineering and design, and are actively being incorporated into the realms of Electrical, Mechanical, and other forms of engineering.
Why? Because We Are Scientists!
In a previous post of mine, Practicing ‘Agile’ Doesn’t Necessarily Make You ‘Agile’, I noted that the driving forces behind many Agile’s techniques are derived from either directly of indirectly from the good ol’ Scientific Method — specifically the concept of introducing changes in variables, one at a time, into experiments in order to iterate on ideas/hypotheses along the way. Doing this in a controlled fashion is crucial for success — both because it lets us reproduce the situation and because it allows for the integration of additional changes only once the system is proven to be stable… with each incremental change.
Changing multiple variables simultaneously, prior to the due diligence being invested as each change is introduced, is a recipe for disaster. Lack of this due diligence also leads to defects being found after multiple things have changed, which makes tracking down the root causes of these defects exponentially more difficult and time consuming. This inevitably leads to more stress, frustration, finger pointing, and so forth.
Bottom line: all developers, testers, product owners, and management must own and enforce that changes be integrated in a serial fashion, only after each integration step is completed and fully verified. Cutting corners such as incomplete validation, especially not creating and maintaining automated tests, so that regression testing can be expedited is further adding risk that new/old defects can creep back in undetected along the way… further increasing the likelihood of deadlines not being met, and defects being released to large-scale validation teams and possibly the customer. All of which are strongly undesired outcomes.