The Wild Wild West
Sunday, October 27th, 2013It’s been my experience that Delphi applications are often produced by a single developer or a very small team working largely independently to “get it done”. You know…no in-line comments, design or requirement documentation, just the code. Sometimes I have even been told that developers don’t write documentation because the code is self documenting. While Pascal is very readable for most part there are times you still have to interface with raw APIs, and that code tends to be less readable. The code itself also never documents assumptions made, how the class instances interact, or reasons for writing things certain ways some of which may no longer apply as RDBMS and other software depended upon, has evolved over time.
Very often these developers are self taught, and there are still many developers actively writing code who started before object oriented programming came into vogue, and design patterns, TDD and other software development best practices became known and proven (I’m one).
Sometimes people continue to develop in ways they are comfortable with, and are understandably more concerned about “getting it done”, than “doing it right”, or they simply haven’t taken the time necessary to hone their skills. The problem is that eventually they code themselves into a corner where they can’t easily make any changes without risking breakage, and major changes require a rewrite because the code is so tightly bound together. This “technical debt” can creep up rather quickly when you have cowboy coders, or management that is always pressing for new development to expand the business, and doesn’t understand that payments against technical debt must be made.
Just like the real world, the world of software development has become much more civilized. You can start a product with cowboy coders, but the moment you want to build a company around it you need resources, and the cowboy coding methods just don’t work in a team environment. Teams need documentation to disseminate information without requiring a senior (more experienced with the code) member to teach more junior ones (not necessarily junior in terms of technical skills). This causes a kind of paralysis as you try to grow the team, resulting in significantly higher declining rates of return for the investment in new developers.
It’s never too late to change your ways, and turn in your six gun. I am reading Working Effectively with Legacy Code by Michael Feathers, and although I’m not that far into it, I would already recommend it.