Most common software development mistake
Construx recently wrote a white paper about software development’s most common mistakes. These mistakes are often called classic mistakes because they happen so frequently and have such predictable results. You can read the full white paper here (you’ll have to register to download it).
Of all the classic mistakes, the most frequent one is having an overly optimistic schedule where not enough time is given to complete a project. As I reflected on this it didn’t take me long to realize that it is also one of my personal classic mistakes.
In my first job I didn’t have much control of this mistake. Upper management personnel were the ones that set the deadlines for projects, and although my teammates and I regularly fought back and said we needed more time, the deadline was rarely extended. We were always able to meet the deadline, but many times we spent the next two to four weeks working out the bugs that were missed, and it didn’t make a good impression on our clients.
Currently I’m working at a place where I’m the only software developer, and although I am now the one that sets the schedule, I find that I also have the tendency to be overly optimistic on the deadlines, and I don’t have anyone to blame but myself. So I got to thinking why I have the tendency to be overly optimistic on project deadlines.
One of the causes I’m most prone to use is thinking in terms of how long it will take to create a working prototype of the application instead of creating production ready code with test coverage and clean, organized code. Many times I can get an application up and running within a day or two, but it doesn’t have any unit tests and the code is sloppy. It can take another week or two to clean up the code and write unit tests to get it production ready.
Another reason I find myself making overly optimistic schedules is because I base the schedule out of being able to work on it full time. However, I’m never fully able to actually work on the project full time because I get pulled into other projects and tasks.
I love playing with new tools and libraries, but I find that they are also another cause for this classic mistake. Tools usually save time on a project, but the learning curve when first learning a tool can drastically add time to the project, and I often times forget to factor in the learning curve time when deciding on deadlines. /For example, NHibernate has been a great tool I use and saves a ton of time, but the learning curve is large and it took me quite some time before I was up to speed with it.
I often like to think that I’m too good a software developer to fall into making classic mistakes, but it is evident that I’m not much different from others and have the same tendencies. But now that I know this mistake is one of my weak spots, hopefully I can be mindful of it in the future and not fall into making the same classic mistake.
