Stop saying "only," "just" and "All we need to do is..."

Developers, please stop saying "All we need to do is..." and "Oh, that's just..." and "That should be pretty simple, we should only have to..." Don't say it aloud; don't say it in your head. You're kidding yourself. Even on the off-chance that what you said turns out to be correct on a technical level—even if it was only a two-line change—you are buying into a wrong view of software.

I am not the first person to say something like this. In fact, I'm not sure that much if anything I'm about to say is truly original. Fred Brooks famously claims in The Mythical Man-Month that all developers are optimists. When I first read this statement I thought the guy was crazy. I knew two developers who kept complaining that the weather was too cold. When the weather warmed up, the first developer complained about the warm weather because he couldn't be outside to enjoy it. The second one complained that we had skipped over spring and landed directly on the heat of summer. When, acting like spring, it cooled back off again, both of them complained that it was cold again. If you ask me, developers can be pretty fickle, even cynical.

But you know what, Brooks is right. My friends who complain about the weather still talk like this: "Well, all the data is there, right? All we have to do is..." "Yeah, that shouldn't be too bad." They still make estimates, from my perspective, as if things go well 80-90% of the time in software... Dear Reader, how often does everything go well for you?

• [Monday standup] I'm working on X. It's not too bad; I should get it done today, or at the latest tomorrow.
• [Tuesday standup] Yeah, so I'm still working on X. Should get it in by later this morning.
• [Wednesday standup] So I ran into all kinds of **** problems with this **** thing. I don't know why it doesn't just work and we have things all **** and I don't know why. Anyway, I'm working hard to get it done and hoping I can get X done by the end of the day, or at the latest tomorrow.
• [Thursday standup] So this is killing me. I just want to take a day off.
• [Friday standup] Okay, I think I got this figured out. I will try to check it in right after this.
• [Monday standup] I just checked it in after the standup on Friday, but it broke the build and I had to roll it back. I just checked it in again now and the build is green. Finally! So sick of working on X.

I can't tell you how often this happens.

There seems to be something about humans that when we think of a task we only thing about the amount of time that the core essence of the task takes. Even as a child I would see my dad time after time accomplishing less than he had hoped to in a day, in spite of being quite industrious. To illustrate this, let's assume that you have stated that something "Shouldn't take too long; it's only a two-line change." And let's assume you are correct about the number of lines of production code that need to change (though you are probably being too optimistic about that anyway). In that case,

• What about automated tests? Aren't you going to need to test-drive that?
• What about any potential refactoring? Could it be that your two-line change shifts the intent of the code so that if you are being thorough, you will really need to rename some things?
• What about updating documentation, or release notes?
• What about manual testing and verification?
• What about if you aren't the person who does it, and someone who knows the area less well ends up working on it?
• Do you have the source code already up to date on your machine?
• What about typing up a good commit message? That takes a little thought.
• What about updating the story or bug in your issue-tracking software?
• What if it turns out there is technical debt that needs to be paid off in the area you are working on, and your organization has a pay-it-down-as-you-go policy?
• Can you get your environment set up for development easily?
• Does the project have good automated tests to give you confidence?
• What if you have to do some debugging?
• What about the cost of integrating your changes with whoever else might be working in the area?
• Do you need to roll up those "two lines" into a different version of the software?
• How sure are you really that you can do that without breaking something else?
• How fast are your build machines? Will you have to watch them to make sure they've passed? Or if you don't do continuous integration, who is going to build with your changes independently to verify, and how long will that take?
• You were going to get that peer-reviewed, right?

When you are picturing those two lines mutated in your mind, you are not giving an accurate representation of the cost of the change. Some of the questions above may not be an issue for you, or they may only cost you five minutes. But some of them could bite you for days. And even the ones that only take you five minutes will add up. We all need to come to grips with this: The amount of time you spend typing production code is by far a minority of your time, even if you are someone who does not have other responsibilities in your organization.

And then, you reap what you sow. If you have claimed that something isn't going to take long and then it starts to take a while, you are likely to rush. And when you rush, you aren't going to write those unit tests. And you aren't going to get it peer reviewed. And you are going to forget to add release notes. Then you will break the build, and you will have to go back and update the unit tests—but you'll just patch them up so they pass, forgetting to rename them for the new behavior. Bottom line: when you or I say "It won't take that long," we are setting ourselves up for a failure in quality. There are many, many activities outside of actually changing lines of code that are a healthy and even necessary part of developing software.

I said that little or none of this is truly original, but I hope you see it is sadly all too relevant. I wrote this because I have fallen into this myself multiple times and I constantly see those around me falling into it. My advice to you is that if someone asks you for an estimate, do your best to give a good answer. But a good answer, even if the estimate is small, will not contain extra weasel words like "just" and "only" to make the estimate seem even smaller or to exaggerate your level of confidence in its being small. It might be a five-point story, but I would still advise that you not call it "only a five-point story". Learn the wisdom of moderation in such statements. Why go to needless conjecture about tomorrow's work? Tomorrow will bring its own worries...

And, if no one is breathing down your neck for an estimate, don't make a statement about whether it will be hard or not, if for no other reason than to keep yourself out of that starved view of software development that is so pernicious. Stop applying so many diminutives to your work. Software is hard.