Last week, I received a notification from someone who was looking for a developer to continue development on an existing web application. This was your run-of-the-mill contract job posting, until I got to the following sentence:

"This platform has been upgraded recently with our current programmer who has faced a tremendous number of troubles which created him over 150 extra hours of work over his maximum estimation so far and yet he hasn't finished the job."

Whoa, 150 hours over their estimate, and they still haven't finished the job? That's pretty insane. If they were working a 40-hour week, this is almost one full month over when they thought they would be done.

Having been working in software development for over ten years, I know that developers are notoriously horrible as estimating the time needed to complete their tasks. Whether it's because we're afraid to tell our bosses or clients about how a seemingly trivial task to them will take weeks, or because our egos get in the way and we think we're much better than we really are, or any other reason, we usually fail to get our target dates wrong. And more often than not, they're off by an order of magnitude of the original time given.

There's a really interesting Quora thread which has over 250 answers (!!!) to the question "Why are software development task estimations regularly off by a factor of 2-3?". I highly recommend reading the first few answers, because not only as they well-explained and well-written, but they're also pretty entertaining (especially the answer using a trek to San Francisco to Los Angeles as an example).

However, regardless of how terrible software developers are at giving estimates, there's simply no excuse to let a project overrun by weeks without someone doing something about it. I don't know the reason behind the poor estimate from the person looking for a developer, but I'm 99.9% sure that the problem boils down to one single thing: communication.

In all my years working at various startups, almost all problems between developers, non-developers and management is due to poor communication at some level. There are very few instances when problems are due to something else. I've seen all types of communication breakdowns. Sometimes it's unintentional:

  • The developer is heads-down in a project for days / weeks and doesn't share what they're doing with others.
  • Product / Management groups change things around in the project and don't trickle down the information to the developers.
  • Common misunderstandings between developers and product / management groups.

Other times, the communication breakdown is entirely avoidable:

  • The developer encounters an unexpected problem and gets into a sort of "superhero mentality", thinking that they can fix things on their own without anyone's help.
  • The developer blatantly lies about their progress when asked.
  • Management blatantly lies about company issues.

Regardless of the reason, I think all of us, myself included, can do a much better job at trying to be as clear as possible when communication details about a project. I've been asked what sort of things I think would make a project run smoothly, whether it's a remote contract job or people working together full-time every day. Here are some of the things I try to do well in every software development project I work on:

  • Don't lie, especially when things are not going as expected - It's weird that this has to be explicitly mentioned, but like I said before, I've seen plenty of people lie for the sole purpose of covering their asses. This is a recipe for disaster. If something is not going as intended, or you screwed up big time, own up to it. It'll be painful in the beginning, but in the long run this will save everyone a lot of headache and most likely save the project from impending doom.
  • Constant communication on a daily basis about the progress - I'm pretty sure that the whole "150 hours over estimate" issue would have been completely avoided if the developer and the client were talking about the progress of the project every day. The caveat here is to find a way to do this as part of a daily routine without interrupting people constantly throughout the day. My rule of thumb is to email or talk about the overall progress once a day, and use other methods like chat or Skype to ask questions about smaller details.
  • Never assume that everyone knows everything - If I had a nickel for every time I've been told "I didn't mention it because I thought you knew", I'd probably be able to take a trip anywhere in the world. Often, it's true - the other person honestly thought you knew. But too frequently I've noticed some people use this as a crutch when they know they messed up. My train of thought is to always err on the side that the other party does not know what you do know. I'd prefer to bother someone by repeating something they know, rather than bother them when they find out too late.
  • Have the developer show what they have done frequently - If your boss or client has a technical background, they should be able to easily pull your changes and run the code themselves, or at the very least skim the source code repository to see what changes you've mad throughout the day. But more often than not, that person doesn't know how to run their code (which is probably why they hired you to begin with). I often try to demo what I've done every couple of days, or when a major feature is near completion. This will make sure you're on the right path and avoids nasty surprises down the road.
  • Be very clear about what you expect to do / be done - I've frequently been given tasks that are extremely vague. Whether it's because there's an assumption that I should know what the task is, or because they person assigning the tasks doesn't have a clear idea themselves, I always push for as much clarity as possible with what everyone is expecting the end result to be. I usually don't need details about everything that needs to be done, since there should be constant communication every day, but at least knowing what the final result will be can serve as a marker on your path.

I know that sometimes communicating can be tough. But talking things over, whether it's good or bad news, really can make things better. It prevents issues from escalating, and for the most part your friends and coworkers genuinely want to help you. But they need to know about it first, so let them know as quickly as possible. There are plenty of times when I wish I had communicated more, both at work and in my personal life - I'm certain I would be in a much different place in my life now.

Avoiding conflict will keep you trapped in it forever. Be free.