In this episode I continue to look at professionalism in software development. I take a look at the eighth oath from the Programmer's Oath by Uncle Bob Martin, introduced in episode #51, to explore further: "I Promise that, to the best of my ability and judgement: I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty."
Or listen at:
Published: Wed, 07 Oct 2020 15:52:16 GMT
Links
Transcript
[00:00:35] Hello and welcome. In the last few episodes, I've been looking at Professionalism within Software Development. And I've been talking about it through the lens of the Programmer's Oath by Uncle Bob Martin, which I introduced in Episode 51.
[00:00:50] In this episode. I want to look at the eighth oath:.
"I Promise that, to the best of my ability and judgement: I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty."
[00:01:14] So let's start with what is an estimate now?
[00:01:17] This is a subject I'm quite passionate about. I've written a number of articles about this previously, and I'll put the links to those articles into the show notes. However, for me:
"an estimate is an approximate calculation or judgment of the value, no quantity or extent of something."
[00:01:41] Ultimately, an estimate is a guess that get will be based on what we know at the time.
[00:01:51] Now, it might be based on what we know of what we're being asked to do, based on what we know of the problem, based on what we know of the technology, based on what we know of the systems we also have to interact with.
[00:02:08] It's very much a guess because there are so many variables involved.
[00:02:15] And no matter how scientific or how much time you want to spend on trying to establish that estimate, that guess it's never going to be 100 percent correct. It will never be spot on. The question then becomes how much time and effort do you want to invest in trying to get something that is going to be wrong in terms of the value you actually get from having that estimate in the first place?
[00:02:43] But the important thing I want to put across here is no matter how much time and effort you put into it, it is still a guess.
[00:02:54] Now, where this can really go wrong is, unfortunately, people take that estimate and hear the word commitment. They believe that you've told them exactly how long it's going to take you to do the work.
[00:03:10] But I've just told you, you're never going to be 100 percent accurate in your estimate - because it's a guess. So how then does it become a commitment?
[00:03:23] And I can understand why that would happen, people want to have certainty. I've talked about this in the episode on predictability. They want to know exactly how long it's going to take. They want to have that level of confidence. They want an absolute. They want a promise out of you ideally - that it will take this long.
[00:03:45] And why? Because it reduces risk. If they know how long it's going to take, they can look at how much they expect to gain from it again, which is a guess, and then try and establish whether it's the right thing to do based on risk.
[00:04:05] It's much more difficult to be able to do that risk based calculation if you turn around and say "I'm giving you a guess".
[00:04:13] But it doesn't change the fact that the estimate is still a guess. And unfortunately, it continues to go wrong as it's populated through the management structure as being a commitment, a promise. So much so that when the work takes longer than the estimate, it's the failure on the developer that gave the estimate for not having delivered based on their estimate in the first place, even though it was purely a guest based on what they knew at the time.
[00:04:47] So this brings us to what is an honest estimate now?
[00:04:52] Interesting, Uncle Bob's first response is "I don't know".
[00:04:58] Now, think about that for a second. I actually completely agree with that. I actually believe that the most honest estimate you could possibly provide to any task is "I don't know". Within in software development there are so many variables. It's almost impossible to get to a point where you can have a very high level of confidence in just how long it will take. You're always going to be guessing, as I've said, roughly how long it will take and even then knowing it's not going to be 100 percent accurate.
[00:05:35] Now, unfortunately, just turning around and saying "I don't know" is not necessarily the most useful thing. People want to understand how this maps up against the expected benefit so they can do that risk analysis. Now, Uncle Bob actually suggests providing a range to help manage that risk.
[00:05:57] By being able to give a level of "well, at best, I think it's this", "on average, I think it may be that", "at worst I think it might be something else". So you might be turning around and saying, "well, if everything goes well, I'm 25 percent certain that it be done in three days". Right the way through to well, "at worst, this could take two months".
[00:06:22] Now, you need to try and be as accurate as you can and try and provide a level of confidence in that, and it is a dialogue. But again, you can only be as professional and as accurate as possible based on the knowledge you have.
[00:06:38] It then becomes the manager's job to manage that risk. That's why they're there. It might not be an easy conversation, but it's up to them to carry that for us.
[00:06:52] In keeping with the honest estimate, what you then have to do is provide further estimates as you go. Once you start looking at the work, you might go "oh no, this is much bigger than I expected. My lower end estimate is wildly out. And it's actually now looking more like this"
[00:07:10] And as you work through it, as a developer, as a team, you become much more attuned to exactly what the work is. Plus, of course, you will have done some of it. As such, you can have much more greater confidence in that range, ideally bringing it into a much narrower scope with a high level of confidence that it can be achieved.
[00:07:34] So what's the downside of promises and commitments?
[00:07:37] Now, I can understand that they're desirable, that we want to know exactly how long it's going to take and when it will be done by. But if we're not careful, we create artificial certainty over the uncertainty. We manufacture a date based on guesses, based on estimates, and suddenly that becomes a certainty, it becomes a commitment, a promise at which point we're artificially creating that certainty.
[00:08:08] The wider executive, for example, now have an impression. There is no doubt. There is no risk. There is no question. There is no guessing. They've been given a date for them. Now it's a certainty. Which leads to false expectations. They are expecting something to be delivered by a certain date because they've been told that.
[00:08:33] And unfortunately, without managing that message correctly. That then produces a number of dysfunctions within the business and the operation to make sure they can then achieve that time.
[00:08:49] Rather than disappoint, we find people actively working to hit those deadlines that they've effectively been imposed upon. Even though that isn't necessarily the best thing for the system or the long term ROI.
[00:09:08] We find people cutting corners. We find people changing what it is it's actually intended to be delivered. We very quickly head into technical debt where we're incurring problems for the longer term. We're cutting corners and we're producing poor ROI.
[00:09:34] And unfortunately, it's the perception of failure that causes us the problems. What started off originally as a well-meaning guess, based on what we knew, got turned into a commitment and then into a promise. And we are then held to those promises, even though we probably should never have made them. This is why we must always be very careful when we are producing estimates.
[00:10:04] We must be always honest in terms of making sure that we are clear in what we believe the magnitude and the precision of our estimate is. But it also must be careful to avoid making promises unless we have certainty. And certainty can be a very difficult thing to achieve in software development.
[00:10:29] In the next episode, I want to look at the last oath:
"I Promise that, to the best of my ability and judgement: I will never stop learning and improving my craft."
[00:10:44] Thank you for listening and I look forward to speaking to you again next week.