When I got back, I found out that people were not happy. I felt I was going to be fired. My stress and anxiety levels went from 1 to a 9 on a scale of 1 to 10 quite rapidly. But, out of this chaos, our project manager stayed calm, and used this experience to expose the real culprit: requirements.
We needed to slow down and spend the time to define all of the rules in detail. We had to be clear on any alternative paths that could be done and how they worked. We also had to create a thorough test plan that had to be accepted by various members of the team before we agreed to push new code to production.
It took about two to three months to put this formalization in place, but once we did, our next release was stable. So was the next one, and the next one, and soon the business gained confidence that we could deliver new features without breaking the system. Things ended up in such a good state I was asked to work on other applications at that client, either to help them out and get them back on track or start them from scratch, applying our approach right from the start.
It's common these days for people to talk about the "minimum viable product." There's a mentality that getting to market faster than your competitors is essential, even if you know there are bugs in the product or you had to cut corners to make everything work.
To an extent, I understand this view and there's validity to it. But if you can't even define what the application is supposed to do at a fundamental level, you're screwed. At some point, all it will take is just one line of code to do a lot of damage (that's literally all it took to crash that payroll file processing code).
Having clear, well-defined requirements is a basic that every application must have. This is an evolutionary, iterative process, but it's one that must be in place for a software project to be successful. Until next time, happy coding!
Sign up for CIO Asia eNewsletters.