For a good part of my early career as a software developer in the 1980s I didn’t really seriously consider the maintainability of the software I wrote. I was just concerned with getting it to run. Soon after that I would focus on trying to make it consume as little space as possible and to run as quickly as possible. Computers back then were very slow and with only 640K in 10 segments I’d often have to reduce or remove a feature I so that I can add another feature.
Today computers are fast enough, memory is cheap enough, and the problems we are trying to solve are complex enough, that the next most important priorities for the software I write is maintainability and extensibility.
A lot of the software that I wrote 20 years ago was less than 20,000 lines of code. Today the software that I work on in a team can be at least 50,000 to 1,000,000 lines of code or more. Once the system reaches that size it hits what I call “The Wall”. This is where a poorly written system begins to break under its own weight.
At this point, code quality, development standards and practices such as automated builds and continuous integration are not optional, they become essential. Without building software with standards and practices that support maintainability our code will quickly degrade as its size increases.