The old way of building software

In the not so distant past, developers built software without tests, without refactoring and consequently without hope. The company I currently work for has inherited one such piece of software, which we're now tasked with developing a plan of attack to fix it. I can't begin to explain the number of bad decisions that were made in developing this software, they range from architectural, to code, to build and deployment. From where I sit, most of the problems stem from a lack of process.

The last project I worked on used the notion of "going dark". This is where you spent a considerable length of time going off on your own, without using the test, code, refactor cycle (with regular commits). I've seen this (and used it myself) for most of the time that I've been developing software, and had previously thought it the norm. This style of development lends itself to isolated development, lack of knowledge transfer, integration hassles, non-testability and poor code. As this is the norm in the software industry, it's not surprising that it isn't questioned and other methods are not considered. I certainly wasn't aware of another way until very recently.

However an alternative does exist, and it's not that hard to achieve. This alternative involves short development cycles, doing a small amount of tested fully refactored work, and regular commits. There's no magic involved, and it lends itself to fully tested code, constant integration, knowledge transfer and robust code that is easy to update as requirements change (which they always do). Of course if you throw pairing in on top, you get even more of the benefits, however judging by recent experiences this is something that managers and most developers are not ready for, even if it produces excellent results.