In this final installment, we cover estimates. As developers we’re often asked to estimate tasks, user stories, features or even entire new projects. So, how do you do it? How can you make sure your team and management are on the same page with you? Read on to find out.
Chapter 3: Estimates
What are estimates?
Developers like to view estimates as guesses. Businesses like to view estimates as commitments. The difference is profound. An estimate is a guess. No commitment is implied.
No promise is made. Missing an estimate is not in any way dishonorable. The reason we make estimates is because we don’t know how long something will take.
You will be late. It happens to the best of us. It happens to the most dedicated of us. Here are some tips that can help you along the way:
- Break up a large task into many smaller tasks and estimate them independently. The sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task. Do not incorporate hope into your estimates!
- Regularly measure your progress against your goal.
- The worst case scenario occurs when you continue to tell everyone, up to the very end, that you will be on time — and then let them all down.
Business professionals want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision that simply cannot be achieved.
The problem is that things appear differently on paper than they do in a working system. There’s a kind of observer effect, or uncertainty principle, in play.
- When the business actually sees what they specified running in a system, they realize that it wasn’t what they wanted at all.
- Once they see the requirement actually running, they have a better idea of what they really want — and it’s usually not what they are seeing.
When you demonstrate a feature to the business, it gives them more information than they had before, and that new information impacts how they see the whole system.
The word “try” has many definitions. In The Clean Coder: A Code of Conduct for Professional Programmers, the author, Robert Martin defines “try” as “to apply extra effort.”
“We’ll try” is a commitment to apply that extra effort to achieve the goal…
- By promising to try you are committing to succeed
- Professionals know their limits. They know how much overtime they can effectively apply, and they know what the cost will be.
- If you don’t have a new plan, you are lying, and you are probably doing it to save face and to avoid a confrontation.
If you commit to getting something done by a certain date, then you simply have to get it done by that date.
Courage to say “NO”
This article is about software professionals and they always speak truth to power. Professionals have the courage to say “no” to their managers. Professionals are expected to say “no.”
You must be determined to give your managers the best information you can, and oftentimes, this means saying “no.”
Professional programmers are careful to make sure that their communication with other members of the team, and the client, are accurate and healthy. Communicate to avoid creating surprises:
- Let your team and your superiors know when you are in trouble.
- Tell them your best plans for getting out of trouble.
- Ask them for their input and guidance.
Nothing makes people more angry and less rational than surprises. Surprises multiply the pressure by ten.
Commitment is about certainty. Other people are going to accept your commitments and make plans based upon them. The cost of missing those commitments, to them, and to your reputation, is enormous. Missing a commitment is an act of dishonesty only slightly less onerous than an overt lie.
There are three parts to making a commitment.
- You say you’ll do it. 2. You mean it. 3. You actually do it.
If you can’t make your commitment, the most important thing is to raise a red flag as soon as possible to whoever you committed to. If you don’t tell anyone about the potential problem as soon as possible, you’re not giving anyone a chance to help you follow through on your commitment.
Professionals draw a clear distinction between estimates and commitments. Professionals are very careful to set reasonable expectations despite the pressure to try to go fast.
The professional developer is calm and decisive under pressure. As the pressure grows he or she adheres to their training and disciplines, knowing that they are the best way to meet the deadlines and commitments that are pressing on them.
- The best way to stay calm under pressure is to avoid the situations that cause pressure.
- Avoid committing to deadlines that you aren’t sure you can meet.
- Accepting unrealistic commitments does a disservice to both the business and to ourselves.
- We can avoid pressure by keeping our systems, our code, and our design as clean as possible.
Overtime can work, and sometimes it is necessary. Sometimes you can make an otherwise impossible date by putting in some ten-hour days, and a Saturday or two. But this is very risky.
You should not agree to work overtime unless:
- You can personally afford it
- It is short term, two weeks or less
- Your boss has a fallback plan in case the overtime effort fails
Of all the unprofessional behaviors that a programmer can indulge in, perhaps the worst of all is saying you are done when you know you aren’t.
When a team falls into this trap, managers hear that everything is going fine. All status reports show that everyone is on time. It’s like blind men having a picnic on the railroad tracks. Nobody sees the freight train of unfinished work bearing down on them until it is too late.
At our Web Community “Share Knowledge” meetings people often request more soft skills topics, leading this series of presentations to be highly welcomed.
After each presentation I received very good feedback from my colleagues, often starting long conversations and debates about topics and advice given in the book.
Becoming a Professional Programmer takes a lot of patience and work – from yourself, from your team and with the processes you’re working on.
We learn. We share. We’re better together.