SGMLXML.net A place for SGML and XML application developers.

Entropy is defined as "A measure of the disorder of a system."

While entropy got it's start in thermodynamics, it applies equally well to software development. Specifically late changes to the system design or bug fixing after a release.

Theoretically if you have a small system with only a few developers and you designed your architecture well, the initial version of a system is fairly clean. No nasty patches, no hacks to keep the thing limping along. Yeah right. Either way, the original development team has probably poured their guts also know as energy into the system to create order from disarray (like the socks in your drawer).

As additional releases with new features and patches are applied to the system entropy increases. The system starts to break down. The system requires more and more developer energy just to keep it going as the patches and new features take away from some of the original elegance. What's the smart developer to do?

I advocate that certain releases of a system introduce no new features, stop attempting to fix bugs and simply get the house in order. Allow modules to be rewritten taking into account all that has been learned since the original release. In short decrease the systems entropy again.

I like the way this is summarized by Frederick Brooks, JR in "The Mythical Man-Month"

..program building is an entropy--decreasing process hence inherently metastable. Program maintenance is an entropy increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.

Charles Angione

The 12 questions were originally developed by Joel Spolsky a former program manager at Microsoft that worked on Excel. Under each question additional observations from my experiences.

1. Do you use source control?

   If not you are out of control. Even with a single developer.

   All code, support programs, build files, help files, etc, should be put into the repository. Code should be checked-in frequently once it is in a state that it is not likely to cause problems to other developers. A private branch can be used to check-in intermediate work without affecting other developers, to be merged into the main project branch once it is in a stable state.

2. Can you make a build in one step?

   This is the only efficient way to make sure you are not introducing human error into the build.

3. Do you make daily builds?

   Computers are only too happy to work overnight. Continuous integration helps make integration weeks a non event.

4. Do you have a bug database?

   MS Excel doesn't count. Resist all attempts by the program manager to export the Bug List to Excel! Anyone (including customers) should be able to log a bug. Don't stick the bug database behind your corporate firewall. It leads to MS Excel documents.

5. Do you fix bugs before writing new code?

   Important ones anyway.

6. Do you have an up-to-date schedule?

Vacation schedules. Agree upfront that vacations are sacred. The project team should be able to do without a team member for awhile. Release schedules are also important although problematic.

The word just should NEVER enter a schedule discussion....just means it should already be done.

7. Do you have a spec?

   Not a novel. A spec may be a cocktail napkin, UML diagrams, UI Mockup whatever is useful. Define useful as someone actually reads it and comments on it!

On UML

UML gets a bad name from Use cases. All those little bubbles and stick figures. Who cares? They are really the beginning not the end. Use cases should turn into activity diagrams etc.

One of the things that I find amazing is that you can write a hundred page spec and get no comments but you can present a series of UML diagrams and get everyone to actually read them! A picture is worth a thousand words.

8. Do programmers have quite working conditions?

   Quite conditions for coding. You also need a team area for integration and testing.

9. Do you use the best tools money can buy?

   Money isn't everything but it sure helps build and infrastructure. Lots of applications don't cost money these days but hardware and infrastructure do. Don't skimp.

10. Do you have testers?

    Should be familiar with things like virtualization.

11. Do new candidates write code during their interview?

Spend time interviewing candidates. New people are disruptive.

12. Do you do hallway usability testing?

Solicit others input.

Comments (0)