Necessary Rudeness and the Effective Use of Your Time

Pop quiz, hotshot – you have a task of known importance in hand. You have an interruption (phone call, eMail, fax, someone hovering in your doorway) ofunknown importance coming in. What do you do? If you’re truly interested in being effective, you turn off your ringer, close your office door, and shut down your eMail client until you’re done with your task.

Here’s a scenario – tell me if it sounds familiar. You’re diligently trying to maintain your focus on a critical task, only to hear your phone ring. You answer the phone, provide the answer to a co-worker’s question (a questions could have been answered by Googling), then return to your task. Blinking your eyes twice, you get yourself back in the groove and continue. A few minutes later, another phone call with another question pertaining to an issue of low urgency. Again, you breathe deeply and slog onward with your task…until another phone call comes in. And an email with the little red flag indicating that the message is "urgent" pops up in your Inbox, so you start reading it while you’re on the phone. Then you notice Bob from Accounting hovering in your doorway, asking if you "have a minute" as you try to type an eMail reply while finishing up your phone call. Then a phone call comes in on your other line before you are done with the call you’re on. Wait, what was I trying to do again?

Let’s look at the culprits here:

  1. The Phone. The telephone is, without a doubt, the #1 most ruthless time-waster in business life today. And not only do we have them on our desks, we strap phones to our belts and carry them with us all day! The specific problem with the phone is that while you know exactly how important your current task is, you have no idea if the next phone call you take will be a trivial question or a bona-fide emergency. Here’s a hint: true emergencies are few and far between. To paraphrase Dan Kennedy, never interrupt a task of known importance for a potential task of unknown importance.
  2. eMail. Ah, eMail. I love eMail. But even eMail has a dark side – when someone sends you an eMail in an office environment, they know that you receive it more or less instantly. This often leads people to expect a response more or less instantly. Every office has at least one person who follows up every eMail with a phone call “just to make sure you got my eMail”. If you are going to make effective use of your time during important tasks, you must not allow anyone to pressure you into providing a reply according to any timeline other than your own. Shut down your eMail client when you’re working on important tasks. Fire it up when you’re not. It’s simple, but so few people do it.
  3. The Person Hovering in Your Doorway. If you are in the midst of working on a truly important task, your office door should be closed. If you do not have an office with a door that closes, it is acceptable to simply not acknowledge a person who hovers in your doorway. Let the person announce himself or herself. Then you have a few options. I used to offer “5 minutes now or 30 minutes by appointment later”. I found that almost everyone prefers to take the second option, which is good. It allows you to continue your task, and it gives the other person a chance to gather some info and bring you a well thought-out issue to discuss, rather than some extemporaneous doorway rambling. It also sends a message to other would-be time-wasters that they need to have their game in order before approaching you when you’re in the middle of an important task.


I will go so far as to say that if you are not 100% unavailable for at least 2 hours a day, you probably aren’t getting much done that’s of any importance.

Now, despite the title of this post, I do not advocate being rude to people; quite the opposite. The term “necessary rudeness” is meant to acknowledge the fact that if you make yourself unavailable while working on critical items, some people will perceive you as rude, and this is OK. Most people – the ones who are themselves effective – will understand. Those that do not understand are likely to be the same people who don’t accomplish much. Open-door policies and their ilk sound fantastic in corporate seminars and on the dust jackets of business books written by guys who’ve never really run businesses, but in the real world being too available rarely does anything but allow people to take advantage of you. Ours is such a culture of accommodation that we often forget that getting things done is what keeps us prosperous. During times of critical work, it is acceptable to demand that people respect your time. During times of critical work, it is acceptable to demand that people call ahead rather than hovering in your doorway, trying to interrupt your task. During times of critical work, it is acceptable to refrain from answering faxes and eMails immediately – that the message is delivered instantly does not entitle the sender to an instant response.

I can almost hear all of you lone-wolf, “slide pizza under the door until I tell you I’m done coding” types rejoicing as you read this, ready to print copies out and tack them up in your cubicle in an attempt to justify your teamwork-avoidant behaviors at work. Don’t worry, I’m about to burst your bubble. 😛

The flip side of all this is that you must be able to determine which tasks can afford no interruptions, and which ones can. If you are unable to make this determination you will either fail to get the truly important tasks done, or you will fail to provide sufficient value to your colleagues and customers to keep yourself employed for very long. Nobody works in a vacuum, and it is critical to strike the right balance between single-minded focus on critical tasks vs. availability to support your team and customers. When you know that your task is of the highest importance, by all means turn off your ringer, shut down your eMail client and close your office door until you are done. But be surgical about it – when you switch to working on relatively routine tasks, make yourself available. And remember to extend as much respect for the time of your colleagues and customers as you demand they show for yours.

It is a difficult balance to find, and being able to find it is one of the marks of a true professional. Finding this balance it will make you more productive and much less frustrated.

The 5 Pitfalls of Estimating a Software Project

Updated June 27, 2016

People often ask me why estimating a software project is so fraught, why software projects are chronically late and/or over budget. Naturally, I always take that question as an opportunity to brag about my current level of skill at estimating projects.

It took until I was 6 years into my career to learn the art of estimating a software project so that it was acceptably accurate.  Along the way I discovered a set of behaviors that always lead to blown estimates and broken budgets. Avoiding these pitfalls will put any organization on the road to more accurately estimating a software project.  This will lead to happier clients and profitable projects.

Before we get started on the list, I want to make one thing clear:

Estimating a software project well is hard.

Know-it-all articles that tell you “just do this and everything will work out!” annoy me, and they probably annoy you, too.  Prefacing any kind of advice-giving with “just” is reductive and unhelpful.  Understand that what I’m offering you here are my particular experiences, offered in the spirit of “maybe try this?” rather than “just do this!” – because I acknowledge that what we’re trying to do when we develop estimates is hard.  In other words, these 5 pitfalls have been true for me and for the teams I’ve worked on, and I suspect they’ll be true for you too.  Ultimately, it’s up to you to try to fit them to your experiences as a developer and see if they work for you.

All that said, here are the 5 behaviors that I’ve seen consistently contribute to bad estimates:

1) Allowing non-technical staffers to give estimates.

You think I’m about to launch into a typical software developer’s tirade about how talent-less the people on the “business side” of the house are.  I’m not a typical software developer, though.  I value the business side of the house as much as I do the engineering side.  That said, a non-technical employee estimating a software project makes no sense.  You wouldn’t allow a software engineer to commit the company to a marketing plan of his own design, would you?  Of course not. Despite this, non-technical staffers giving technical estimates happens all the time.

To be clear – NOBODY should be estimating a software project except for the person who is actually going to perform the work.

Specialize or Die

Remember Adam Smith? He wrote an little book entitled The Wealth of Nations, maybe you’ve heard of it. In this book, he argued for the specialization of labor, using a pin factory of the day as an example:

…where each of a dozen workers engaged in only one part of the process of manufacture, so that together they produced far more pins than if each worker produced whole pins; the price of pins then fell, and more pins could be used by more people.

When businesses violate the principle of specialization of labor with regard to creating their product, trouble is soon to follow. It is far better to allow the specialists to do work that falls within their specialty than it is to placate a client by giving a totally fictional estimate.  Estimating a software project is specialized work, and should be treated that way.

Be Graceful Under Pressure

Because of the Iceberg Effect, a salesperson out in the field (assuming you work for an org large enough to have salespeople out in the field), who is under great pressure to close deals, is likely to think “Well, that’s just a couple of screens and buttons, it shouldn’t take very long“.  So the salesperson gives the client a number, and the number may as well be 1 hour or 1 million hours, because it cannot possibly have any connection to reality unless it comes from the person who has to build the thing being estimated.

Let your salespeople sell, your marketers market, your executives execute, and your developers develop…estimates, that is.  If you happen to be a small shop where people wear multiple hats, that’s just fine so long as the person who has to build it is also the person providing the estimate.

2) Being afraid to look in the mirror.

Most development shops I’ve interacted with do not do any “post-mortem” reviews at the end of an over-budget, past-due project (or even a successful project, for that matter). Therefore, they never learn what went wrong, never disseminate information that can other staffers avoid what happened, and thus promptly repeat the exact same mistakes. This causes the next project to be over-budget and past-due, and that project doesn’t get reviewed either, so the same mistakes are made on the project after that, and so on. Even seasoned developers can fall into this trap.

Don’t be afraid to take a look in the mirror and ask “what did I do wrong?” – this applies to everyday life as much as it does to software development. Always analyze your projects for both mistakes to correct and best practices to carry forward. Failure to do so is the equivalent of flying a 747 without visibility or instrumentation through the Himalayas; way too much risk for most client’s tastes (and checkbook). And again, if you’re a small shop without much in the way of formal review processes, take notes as you go; all you have to do is document the things that went poorly, and the reasons why.  When estimating a software project, having this kind of info at your disposal will help you create a better, more accurate estimate of the work to be done.

3) Underestimating design time and debugging time.

Many software developers are not in tune with The Business, they are in tune with The Thing – that is, they focus tightly on the act of construction and sometimes miss the other, equally vital, things that go into a successful project. In my experience, design is one of the most commonly underestimated things.  Yes, I just said that only the person who builds the thing can estimate the thing, and that counts for design work, too.  This is why it’s important for design and dev to work together when estimating a software project, rather than being silo’d away from each other or, even worse, being actively at odds with one another.  I’ve seen it happen in some dysfunctional orgs, and it is as ugly as it is counter-productive.

Figuring out how to build something takes more time than it took to figure out what to build. On the other end of things, debugging and refining and polishing up the code takes more time than anyone ever anticipates – in fact, in all my years in this business, I have never seen an accurate debugging estimate when estimating a software project. Never. Not once – not even my own!

Budgeting 50% of total development time for debugging is absolutely reasonable, if not necessary. Any developer who fails to accept this is still in the Age of Unlimited Wisdom (more on that later).

4) Inadequate/unclear requirements.

Before estimating a software project, you have to do some requirements-gathering.  There are many ways to do this, but gathering requirements at all is difficult. Gathering requirements well is rare, and gathering requirements in the correct quantity and level of detail before asking a developer to start work is just this side of miraculous. I would estimate that 90% of my pre-consultancy projects suffered from inadequate requirements.

Developer vs Analyst

Every developer has war stories about dealing with unbelievably poorly-written specs.  Every developer has war stories about requirements with more holes in it than Swiss Cheese.  Most developers like to blame the Business Analyst for this.  To be fair, most Business Analysts have war stories about OCD-affected developers.  Stories abound about devs who suffer from analysis paralysis without impossibly perfect specs.  That’s just the nature of the beast sometimes.

It is tempting to rush the requirements gathering process. It is tempting to just assume the answer to questions that are not addressed in the requirements. Mapping a client’s business process is hard, and very few people want to do it – those that actually relish the task are of a rare and strange breed. Uncovering and documenting every relevant hidden nuance of how a company operates is difficult.  This is why estimating a software project is difficult – it encompasses other things that are difficult.

Satisfying the Stakeholders

It’s downright hard to ensure that the high-level details are an accurate representation of what needs to be built. Inaccuracies will creep in if you let them.  This is doubly true if you are in a rush.

By slowing down – just a little bit – and making sure that the requirements gathering is done right (as in, not too detailed and not too vague) before construction begins, everyone will end up happier and the project is infinitely more likely to be a success.

5) Taking too large a bite from the apple at once.

I cannot count the number of times I’ve watched in horror as a Project Manager approached a junior programmer, asking “How long will it take to do X?”, only to hear “Not very long – maybe Y hours” in response from the young know-nothing.  My horror, you’ll note, stems not from the fact that the junior developer was a know-nothing (we all start someplace), but rather from the fact that the Project Manager should know better than to put a junior dev on the spot for something like that.  It’s bad for estimating a software project, it’s bad for whatever downstream politics the project is likely to run afoul of, and it’s exploitative of the junior developer.

Finding the Right Side of the Line

Regardless of what feature X might be, there’s only one correct answer to “how long will it take?”.  That answer is, “Let me see the requirements”. If you don’t have requirements, you need to get some, even if they’re super-lightweight. Even then, you can’t commit to anything better than a “plus or minus 50%” estimate until everyone has agreed that the requirements are on the right side of the 80/20 rules in terms of accuracy. Even then you cannot start estimating a software project until you break down those requirements down into bite-sized chunks.

Making Your Project Chunky

That, my friends is the secret weapon of estimating a software project – the more atomic you can make the requirements, the more accurate your resulting estimate can be.  This is why I love user stories – they’re super atomic (maybe too atomic for estimation purposes, but we can argue about that another day).  That said, the truth is that most people are lazy. Analyzing requirements is almost as difficult as gathering them, and again – very few people want to do it. Those that do will consistently deliver more successful projects than those who do not.

I’m not saying anything here that people in the industry don’t already know. But I am saying a lot of things that people in the industry don’t do. I wish that were not the case, but I can only control my own projects.


Photo Credit: Luis Fernández García (license)