2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- July 7, 2009
- Rants
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.
Previous Post: « Webinar: Writing Quality Software – June 3rd, 2009
Next Post: Code Comments: Good or Bad? »