Don’t Baby Your Builds

In a conversation this week, one developer insisted that a special build machine should be built to assure that the build is always comes out the same.  My response: if your project is building differently on different machines, then you have a much deeper problem. Continue reading

Don’t Suffer Poor Names

You know the problem: you write a method for one purpose and give it a name.  Later, it become useful for something else, or maybe you change it slightly to accommodate another use, or maybe some names change elsewhere making the current name obsolete.  You have all seen code where someone says that the name “is historical” or traditional.  This post is to say with conviction that that history is NOT interesting, and get rid of it.  Get a good IDE and change those names to be correct. Continue reading

Trasparency Advantage

This is an example of some open source software that I had difficulty using and how to improve it.  A common principle is that of transparency: when something goes wrong, don’t hide it.  Don’t cover it up.  Don’t attempt to continue as if nothing happened.  Report it properly and immediately.  A simple explanation of the situation will help a lot. Continue reading

Classic Date Drift Case Study

A waterfall project is required to predict dates that certain things will happen in the future.  There are usually many pieces of the project, each with their own date, and each dependent upon others.  No one can change a date without effecting others, and so a game of “chicken” ensues where people report dates they plan to complete and never hint there is a problem.  At the last possible minute they declare a change in date, and when you look at the history, you can easily conclude that they should have known ahead of time that the deadline was to be missed.  But everyone waits for someone else to change first. Continue reading