I’m closing out, for now, my series on questions at the heart of development with an analysis of when we need more abstraction. For example, taking @germsvel’s advice about architecting more accurate models can reduce future bugs.
Thanks for sharing. I’ve added your site to my RSS reader 
Personally I’m not really convinced estimates in software are possible at all. I think we might need to simply take everyone along for the ride so they can see first-hand how the design is unfolding.
6 Likes
Same, and that’s proven by mine and many others’ professional practices. I had calls, on multiple occasions in the past, with colleagues about why weren’t some 2-3 problematic items inside a PR surfaced earlier during a tech planning stage. Mine, and many others’, answers were stereotypical: “Because even if we sat on a call for two hours and discussed a task breakdown, we still wouldn’t guess X and Y will become a problem. The only way for this to surface would be if we started coding it together during a screen share session, and even that does not guarantee we’d have spotted it earlier than we have in this PR”.
I get the need to want to reduce chaos but this is similar to trying to observe molecules and atoms – the deeper you go, the blurrier it gets. You have to stop while the clarity is at a satisfactory (== not ideal) level and not pursue further because you’ll hit the “last 20% of the task take 80% of the energy” part of the Pareto principle head-first, and it’s going to hurt.
3 Likes
I once worked in an environment where estimates worked. There were various factors involved that I would say contributed to this, some which many people would dismiss or just not want to work that way. Heavy sandbagging was also a factor. But they were successful in that my team has a solid understanding of what we were able to get done, communicate that to leadership, and we’d always hit our goals or deliver early and everyone was happy. So long as the org understands that estimates are, in fact, just estimates and the goal isn’t speed but meeting expectations, they actually can work very well. But again, I’ve only had this experience in once.
1 Like
I think, and please correct me if I am wrong, that you are both saying that perfect estimates are impossible. I agree.
However, are estimates supposed to be perfect? My dictionary is using words like “roughly calculate” and “an approximate” in the definitions. I don’t think perfect is the goal.
I believe estimates are a valuable tool in what we do. I can’t imagine trying to run a business without knowing roughly how much money, time, or employees our work was going to take.
I also believe we can find ways to get better at estimating, even though it is really challenging. We’ve built mostly reliable computer networks for machines we can’t even trust to correctly tell us what time it is. Just one of the techniques we use to get around that is to be explicit about where the error bars are. “I think it’s this time but I could be off by as much as…” Could we not try to do things like that for our estimates?
1 Like
…this of course completely redefines what the word “estimate” means, which I think is the real problem with them, because even when people say that understand what the “estimate” means, I they still think it means “the time it will take give or take an hour or two.” I catch myself in this thinking as well.
2 Likes
My experience is that most people ask for estimates because they are trying to line up when work can be started on the next feature or phase of the project, or when they can announce a release date. But that is not how software works. We’re not building bridges, we’re building dynamic ever-changing systems. Even an experienced developer who may have been working on the project since day one doesn’t have the information required to come up with a number that will be suitable for planning when the job will be finished. The best we can do is try something and see what we get, then reassess.
I’m thinking that instead people need to have the concept of investing in a software project in stages. We’re exploring it together. It might turn out that we decide to stop the project and you have to write off the costs so far given the information learned, or adjust the priority or scope of this or other features. Sort of like hiring someone to come up with a blueprint, except the blueprint is also a functioning system. The system can be refined/expanded from there. That’s better than pretending the job will be complete in a certain time period but then running into all the problems when it is not.
2 Likes
Problem with many business people is that they don’t hear “he estimated the deadline”. They hear “he committed to the deadline”.
8 Likes
This is one of points I’ve experienced some people to be dismissive of. Really your whole second paragraph. For me there was a lot of prototyping, and actually throwing the pototype away. Not “wink-wink-nudge-nudge we’ll just re-work it a bit”, but throwing the whole thing away, building estimates on what we learned (this is after watching customers play with the prototypes), and starting completely from scratch. From there (and this still isn’t the whole picture) it’s not as difficult to build decent estimates.
Pro tip: if you call every variable, function, module, class, etc foo, foo2, foo3 and so on, and (if you are a frequent committer) every commit message is WIP, it makes it much easier to let go of prototypes 
Ya, leadership has to understand this or it doesn’t work. But also, that’s why sandbagging is key
1 Like
You need to know your audience. If your peer ask for an estimate, you give the mean. If your manager asks for an estimate, you give mean plus 1 sigma. If your customer/sales asks, you give 3 sigma out.
1 Like
I think one reason so much time is spent wrestling with these questions even though at this point we all have a pretty good grasp on the situation is it’s hard for technical people to admit that not everything is a technical problem (or more fairly perhaps, keep it constantly in mind). Estimates are not hard because software is “complex.” Building bridges is a complex process as well with plenty of unknowns. We are all experts at breaking down complex problems. It is hard because of power dynamics. Managers, clients, etc don’t “misunderstand” estimates because they are non technical but because they have a different set of vested interests. This is why most effective strategies for dealing with these problems are social/psychological and not technical. Does anyone here really doubt the core ethos of agile? Or is it rather that any technical process can just be turned into a tool of manipulation/control in toxic organizations, i.e. organizations with unstable (unjust?) power dynamics? In my experience it is quite clearly the latter.
2 Likes
I assume we all agree that we could estimate some requests with a high degree of confidence. For example, correcting a spelling error in an event notification message.
This is why I’ve taken to viewing my estimates as a process. I may start with a very rough guess, be sure to state how many unknowns are involved and how much padding I applied because of it, and offer some short time expenditures to reduce those unknowns and padding. Then they can choose to work with my rough guess or spend a little time to refine it, which does benefit the work if we end up doing it. I think that sounds pretty similar to the suggestion of viewing time spent on work as an investment that you may choose to abandon.
1 Like
Has anyone looked into A Case Against Estimates?
I have not… I’m assuming this question comes with a recommendation? 
I am also a big fan of not estimating at all. Whatever works. What I am not a fan of is: “We must estimate because Agile” which is the situation most people are likely in.
3 Likes
This comment is a testament in itself to the fact that, no matter how good of a process you have, it will be twisted into its opposite in bad (read: nearly all) organizational conditions. If I had to distill agile to a single point it would be “ship features in order of priority as they are ready.”
2 Likes
Sorta? There is pivoting involved, otherwise this on its own doesn’t stick out as a particularly negative thing.
And ya, I understand it mostly works out negatively, especially since Agile became synonymous with scrum.
1 Like
Not following you here, I didn’t mean it as negative thing. Pivoting would be something that follows more or less naturally from shipping features continuously, rather than in long cycles. Ultimately my point is just that if you see orgs doing silly stuff in the name of agile, it’s not because agile is silly, or even that agile is hard. There are just a lot of vested interests to not do it, regardless of anything else.
My favorite is when agile methodology becomes part of the sales pitch to clients who only know it as a buzzword and who then turn around and put pressure on the process to not be agile once they learn that they can’t just email a wishlist and get a quote and a launch date. Dealing with those situations is what is hard, and lots of orgs retain agile in their sales pitch and abandon it in their process. Or worse, retain only worst implementations: daily standups that last way too long, “planning poker” for point values that are never used for anything other than punishing devs that don’t push lots of LOC, etc etc
3 Likes
It was me who was misunderstanding you and assuming you were making a general dig at Agile since this is what most people do (and I don’t blame them due to what you describe).
And yes, using it as a sales pitch is ridiculous. Equally ridiculous as using “object oriented codebase” as a sale pitch.
Ya, you’re nerd sniping me here and I don’t want to make this thread all about Agile since there is a lot more to James’ post. But yes: story points and even Jira’s metrics become a positive thing once you have the experience of them being private to your team. When they aren’t being weaponized to keep tabs on and evaluate you, they are actually pretty useful tools for internal planning and understanding what you are capable of delivering. I’ve actually never had the full on negative experience where it was super toxic, but heard many stories.
2 Likes
I do think there is something unique to software that is different to pure engineering disciplines and it’s not completely down to power dynamics, which exist everywhere. I suspect it’s that software is really a design process rather than a pure engineering one, with input and creativity needed at every step - it’s a process of discovery, not just execution of a task.
Even in trivial cases, it may appear something is a one-word change / five minute job so you say it’ll be done today. But somebody just asked you to attend a meeting this afternoon that has just filled out your schedule for the day, and you have to conduct an interview tomorrow that’ll drain your energy for the rest of the day, so you’ll have start it next week. Or maybe you’ll try to squeeze it in now (and drop the context of what you were already doing to the detriment of that task) because it should a be quick fix.
But once you start to do it, you notice that this needs to go through the localisation system. That’s not going to fit the UI anymore in Indonesian, we’ll need to modify the UI component too… It also breaks an old integration test snapshot, how do you update those again? Looks like nobody’s touched that for a year… etc. etc.
The specifics are not important but I’m trying to demonstrate that for complex systems, even a simple change is difficult to predict with so many unknowns.
Maybe it does only take 5 minutes, that great. But if there is more to it than expected, I think discovering that and identifying that this involves tech debt then adjusting workload accordingly is best. I don’t think that initially planning that the task is going to take 5 minutes (or an hour, or half a day) is any better than simply stating the task exists among others, then checking on the status later. Assigning time slots feels like it’s a distraction that gives the illusion of predictability and encourages unrealistic planning.
1 Like
Ironically, I feel like this is a huge part of what my blog series actually about. It’s much less about estimation.
I agree that estimation is hard. However, I do believe it’s a thing that we can practice and improve at. I also believe it can be a useful tool to have in your belt.
2 Likes
