“Done” is a surprisingly ambiguous word in software development. Back when I was in college I thought an assignment was “done” if it compiled and produced more or less the result I was expecting. Then I got a job in the industry :)

It turns out “it compiles” doesn’t mean much when you need to ship software that handles edge cases correctly and works in more than one browser and doesn’t throw exceptions when it’s used just slightly differently from the way I assumed it would be when I built it.

Another complication is that people use the word “done” to mean a lot of different things. I’ve heard people say “it’s done, I just need to test it” and “it’s done, I just need to integrate it” and “it’s done, it just needs to go through QA” and “it’s done, I just need to fix a couple of bugs.” It’s certainly useful to know what stage of development a feature is in, but none of those are done.

To me the only meaningful definition of “done” is “ready for production.” That is, is when the developer has tested the feature, QA has passed it, it’s been merged onto the production branch and any regression testing that needed to happen is done. When it’s ready to be deployed it’s done and not before.

That may seem overly picky but imagine how far off the rails things go when one person thinks done means “ready for QA” and someone else on the team thinks done means “ready for production.” If your feature (or project or report) isn’t actually done, your team lead needs to know that whatever other task they give you might get bumped if your original task comes back from QA with bugs. Obviously you should aim for bug free features but in reality things don’t always go according to plan. That’s why we have a QA department in the first place.

And to go on a bit of a rant, that example above of “it’s done, I just need to integrate it” is not even slightly done and is almost always a terrible idea. If you’ve developed something outside of the system it’s going to be a part of, you’ve exposed yourself to an enormous risk of terrible surprises. Sure, you’ll be fine if you just happen to have a perfect understanding of every little quirk of the larger system, but let’s be honest; you do not. Unless it takes a truly intolerable amount of time to compile the main system, you will actually save time in the long run by building your feature directly where it’s going to be used and just getting up for a drink of water or something while your project compiles. You’re almost guaranteed to have to compile repeatedly while you get your feature integrated anyway, so you’re really not saving any time by developing in isolation. Now, the plural of anecdote is not data and other people have probably had different experiences, but I have personally never seen that turn out well and strongly advise against it. Okay, rant over.

We like to pretend software development is perfectly logical and unambiguous, but you’ll actually run into issues like different definitions of done all the time. Even if you feel dumb doing it, it’s often really helpful to ask teammates exactly what they mean. A surprising number of the problems you’ll run into developing software are just miscommunications that could have been cleared up with a five minute conversation at the beginning of the project. Interfaces between client and server code in particular can be tricky. I’ve personally had to throw out work because I misunderstood what the client team actually needed and built something that was pretty close but not quite right.

Just because you think you know what your teammates mean when they say something as simple as “done” doesn’t mean you actually do. I’d love it if we could all agree what done actually means, but until then you can save yourself a lot of trouble by asking questions.

In the programming field, it’s pretty rare to find a book that’s still relevant even five years after it was published. The Mythical Man-Month is still useful forty years after it was first published, which is either amazing or depressing depending on how you look at it.

What depresses me about how useful the book still is so long after it was written is that in the forty years since, we clearly haven’t learned that much about how to run projects. I first tried to read The Mythical Man-Month ages ago, and I got so frustrated about how little we’ve learned since it was published that I had to set it down. Then I completely forgot about it for a few years because I’m just that organized :) I finally finished it this year, and it’s just as relevant as ever. By all rights everything in that book should be totally obvious and taken as a given by every project manager out there, but sadly it’s not. It is, however, kind of comforting to know that other people have run into the same problems I have.

The amazing part of The Mythical Man-Month is how clearly it shows that the actual programming is the easiest part. Code is simple compared to trying to coordinate a large team and hit a deadline, but as programmers we seem to get hung up on the easy part and largely ignore the hard part. One of the many terrible ironies of programming is that a field that attracts introverts who just want to be left alone to code actually requires huge amounts of communication if you want to get anything meaningful done. For me and probably for most other programmers the code is the fun part, so it’s understandable that we’re not as good at communication as we should be but eventually we’ll grow up as an industry, right?

As sarcastic as that sounds, I think a large part of what we need to do as an industry is accept that things just aren’t as easy as we wish they were and learn to work around it. It’s pretty similar to the way children grow up and understand that the world isn’t as simple as they thought and learn to work around it. I and every other programmer ever have massively underestimated how long something was going to take, and no doubt we’ll all keep doing that. But understanding that underestimating tasks is common allows you to leave extra space in the schedule and/or prioritize features so you know what can be cut if you aren’t going to hit your deadline.

Basically we just need to learn to account for human nature. Should be easy :)

There is an amazing, near magical word that can save projects, hit deadlines, prevent burnout, and gain the respect of your team. Sadly, few project managers seem to know it. What’s this magical word? “No.”

Really, it’s that simple. Just saying no (respectfully, in the right situation) can do all of the amazing stuff I listed. It’s not a guarantee of success, but it will give you a fighting chance.

How does “No” save projects? If you don’t commit to more than your team can actually do, your project’s odds of success skyrocket (this isn’t news, is it?). If you say “No” when someone tries to add features without taking other features out or pushing out the deadline, again, that can only be good for your odds of success. If someone tries to change a feature repeatedly, say no until they figure out what they actually want.

How does “No” hit deadlines? If you have too much work for the time you have left, say no to some of it or say no to the deadline. Developers are not magicians, we can’t fit infinite amounts of work into a fixed time period. Say no to some features planned for the next release if you know they aren’t going to fit. Say no if you can only hit the deadline if everything goes perfectly.

How does “No” prevent burnout? One of the biggest causes of burnout is working excessive hours. If you say no to unreasonable deadlines, like magic your team will be able to get everything done on time without living at their desks. They’ll also be happier because they’re being treated like people instead of cogs that can be replaced when they wear out.

How does “No” gain you the respect of your team? Developers actually aren’t idiots. We can tell when you’re sacrificing our time to make yourself look good or because you’re scared to stand up to your boss. We can also tell when you got us the best deal you could in the face of political pressure to manage the project incorrectly, and we will respect you for that.

So if “No” is so awesome, why won’t people say it? Because they want to be nice, because they want to be seen as a go-getter, not a downer, because they’re afraid they’ll never get promoted if they say no, because they’re afraid to stand up to their boss, etc etc. Those are all compelling reasons, but here’s the problem: refusing to say no doesn’t work.

Sure, you look good in the moment, but when it’s time to deliver and the product is buggy or doesn’t have all the features everyone was expecting, you’re in much bigger trouble than you would have been if you had just said no in the first place. If you do that repeatedly, all you get is a reputation for not delivering. If you don’t want people to trust you that’s your call, but you’d better be amazingly charming (or related to the CEO) if you can’t actually get things done.