Re: Greatest programming mistakes and what to learn from

[mr_mischief]

First, for anyone in the computer field who hasn't been around very long a quick lesson... If you meet someone in a bar or at a party who asks for your phone number immediately after finding out you're in the computer field, don't give it out or you can look forward to Windows tech support calls at 3 AM from someone you barely know. :-) My roommate at the time gave out our number and told a couple of people what we did for a living, and they told their friends. Pretty soon we had to change our number.

As for something having to do with the practice of programming, one thing I learned the very hard way is that if your job consists of both programming and other duties, make sure that the time estimates you give people for getting units done or adding new features to a project make clear that they depend on the percentage of time you spend at the task of programming. If you estimate something will take three days, be sure your boss knows that's three days of design, coding, and testing exclusive of maintaining hardware/server configs/client consulting relationships.

When you get pulled away from programming, make it clear that your target delivery date is slipping because of the shifted task schedule. Be sure to mention that the time needed may be related not just to how long you have been doing other things but also how much of your programming time has been in uninterrupted segments. If you're the type of programmer who works best in a certain mental state and it takes time for you to get into that state, then every switch away from that state causes additional lead-in time for the next session.

I've seen many projects delivered late or even fall by the wayside not because of bad time estimates, but because there was a lack of communication between the developer giving the estimates and the manager reassigning task priorities with little thought about how the software project is estimated. If you know you'll have four hours a day on a project, and that it'll take six four hour sessions to design, test, code, and deliver properly, then that's six working days. If two of those days you're on a junket, and on the day after the junket you're too tired to code, then that's nine working days or maybe ten because of the break. If you originally told your boss two or three days because it's 24 hours of coding and fail to point out that junket in between, you're substantially late on your project.

If a software project is a back-burner project, then estimate the number of hours for each function or small group of functions. Make sure deadlines and the time for the functions absolutely needed make some kind of sense together. Make sure you actually get some time to work on it, even though it's a back-burner project.

Whatever the case, it helps to remind people that estimates for delivery are based on certian assumptions and that when those assumptions change, the delivery estimate should too.

Update: added a word I omitted originally.