Another easily missed point on software development is that: you always need to choose long term solutions over quick fixes. It’s not something you want, but it’s something you need, because you always need to take advantage over mounting complexity by automating and solving as many problems as possible, saving as much time as possible in the future.
You always need fixing bugs before implementing features, but you re-invest the time saved in learning lessons from what you didn’t know with the previous release and you address the problems, again saving time otherwise lost on future support activities. The most important is the dynamics of how fast you tackle issues, as much as it’s direction on fixing them in the first place. To master mounting complexity you need to be making enough savings of time by solving enough problems, by staying ahead of the ever increasing complexity of software requirements and amounts of data being in processing at all times.
Tweaking requirements, patching data, playing cat and mouse with end users appears like a way to go because you appear like solving most current issue instantly. However by not providing a long term solution (and thus not creating enough savings in time spent on solving tomorrow’s problems) you leave software projects with something I’d personally prefer to call “software debt”. This isn’t dissimilar with debts of all kinds, meaning that one as well needs to be paid off at some point. Constant investment in software (certis paribus) initially seems like an option to unskilled eye, but in real life scenario it’s always a neccessity. Over years, you’ll learn that you need to sprint fast in order to stand still.
It’s suffice to say that the debt can be indeed paid off at any point in time, because it grows with complexity of the system and chances of actually paing it off are reduced with each day of increasing amount of time spent on support activities instead of paying it off. It’s like with any other kind of debt, where interest payments dig their tooth deeper and deeper into your capital. You might simply not have any time left to spend on paying off the debt if you’re constantly pre-occupied with paying off interest on software debt.
The result can be some sort of “software bankruptcy” which takes a form of one of the following possible results: subcontracting the development efforts, replacing the system with third party solution or an effect of breakaway IT development teams (by creation of alternative development departments). Last, not least: abandoning the software project at all, which in a case of IT provider can drag the whole company down.
Mastering the complexity and staying ahead of any “software debts” you might have in your warehouse is also the only way to building quality in software. The closer you can get to being on top of all the usage scenarios, execution paths, exception conditions, etc., the less debt you have to pay off, but as a result you’re also better off in space of quality of your software. You cannot focus on minimising the risk, if you’re not investing enough time into mitigating risks by constantly spending all your time on paying of interest on the total amount of debt you’re software carries.
Despite the fact that you shouldn’t ever let software debt spiral out of control, it’s pretty amazing to see what happens when software debt mounts to a unprecedented level causing a sea of change in company’s approach. With the moment of realising the size of “software debt” (which can be named a thousand ways, but a good manager will always know the smell of it anyway), even non-technical management dives into technical details to reveal the scale and the nature of the problem. It appears like dragging the senior management into managing software (with all nitti gritty details) made sense in the first place!