The Wild Wild West

It’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.

6 Responses to “The Wild Wild West”

  1. Wodzu Says:

    This is next book on my “to read” list. Currently I am reading Code Complete 2, I am stuck around 900th page:)

  2. A. Bouchez Says:

    Very good post.

    I’ve done maintenance on such “WWW apps”. First task was to document, and make the implicit explicit. And there is even worse than no comments in code: wrong comment! I mean, I’ve seen untouched comments which did not reflect the code modification… a nightmare to work with!

    I like very much the M. Feathers’ book. And I use it daily when migrating a huge code base in Delphi, Java and C# into Domain-Driven Design. In fact, DDD implements the needed techniques for introducing what Michael calls, in his book, a seam. A seam is an area where you can start to cleave off some legacy code and begin to introduce changes. See

    WWW coding is not the paradigm of Delphi.
    Even if RAD tends to be a cow-boy design, I’ve seen WWW in all languages and frameworks, including the latest.

  3. Andris Says:

    I think the biggest problem may be that Delphi actively encourages bad practices and makes it hard to use good ones. It made it’s name by promoting “RAD way” - just drop TTable, TDatasource and TDBGrid on a TForm (assigned to a helpfully predefined global variable), open the table in some button’s OnClick event and you have a nice working application in just 5 minutes! New developers see this and do exactly how they’re told. Follow this development style for 5 years and you have a big unmaintainable mess with several huge TForm descendants with business logic scattered in combo’s OnChange events and so on.

    Have you seen Borland/CodeGear/Embarcadero (if not created, then at least promoted) materials about separating business logic from GUI? How to do ATDD/TDD in Delphi? Where to find and how to use MVP/MVVM/whatever frameworks?

  4. Alister Christie Says:

    Yes, Working Effectively with Legacy is good reading. I’ve just finished it for the second time and am now re-readng The Pragmatic Programmer. Another book I’d recommend is Martin Fowler’s Refactoring book.

  5. Richard Marsden Says:

    Reading this article last year lead to me buying Working Effectively with Legacy Code as a Christmas present for myself. I’ve just finished reading through it for the first time and I am now trying out the techniques it covers to improve my skill. Many thanks for introducing me to it.

  6. Este Says:

    Fantastic a startup, in San Francisco, using Delphi. I end up hanvig conversations about Delphi ( dead? ) quite often, and always summarize the same way: Delphi isn’t close to the top of heap in popularity (with Java, C#, etc.), but is nonetheless reasonably popular in certain niches, where it is very well suited for the work at hand.

Leave a Reply