project management

Software best practice: Never say “X% done”

Note: This is a post from 2007 that I just updated a little bit because I think there’s still some value in it.

A lot of people have written to say that it’s unfair that I think developers should never say “I’m 75% done,” or “I’m 90% done.”

So, to explain myself, here’s why I think you should never use a phrase like that:

The magic of deadlines (Software best practices) alvin August 6, 2011 - 2:16pm

Wow, I've been reminded lately how important deadlines are.

I've been working on this website all summer, but at a moderate pace. Then recently I put together some goals for the end of the year, which, in turn, led to other short-term goals. Now, it turns out that my short term goals are hard to meet, but not impossible.

A simple software process review saves time

A few days ago I sat down and talked to myself (you can do that a lot in a small cabin in Alaska) and tried to think if there were any ways I could be more productive.

The biggest thing that was bothering me (the problem statement) was the time it takes after I've "finished" writing a long, multi-page tutorial before it can be published. I prefer writing longer tutorials, but they do take a fair amount of effort.

Software cost estimating presentation slides updated

I've converted my Function Point Analysis (FPA) and software cost estimating slide presentations, and they now play much nicer with IE. They aren't perfect yet, but they are much better.

For the record those presentations are at these URLs:

Bad things happen when developers don't communicate

I was recently reminded of the danger of leaving less-experienced software developers alone to create new functionality in a technical area where they have no prior experience. For instance, suppose you have one or more good but less-experienced developers, and you ask them to work in a technical where they have no prior experience. These aren't totally inexperienced developers; they may each have at least five years experience. Given that their are other people on the team with experience in this area, how do you think this should be handled? Choices include:

Software rot, too much magic, and spaghetti code - the Kirk/Scotty syndrome

There is a disease I see so often in the software development industry that I've decided to give it a name. I call it "Kirk/Scotty Syndrome". This disease is related to the concept of "software rot" and "spaghetti code" inflicted by the management team. You'll know this disease when you hear it, because it will sound a lot like the following conversation, taken from most Star Trek episodes:

Fri, Nov 21, 2003

Here are a couple of links as I found yesteday as I continue my personal "software quality" quest: