'My Washing Machine Refreshed My Thinking on Software Effort Estimation' (cosive.com) 55
What Chris Horsley expected to be a 10-minute washing machine installation stretched to four hours and required five trips to the hardware store. The CTO of security consultancy firm documented how unexpected obstacles -- drilling through shelves, replacing incompatible hoses, and removing hidden caps -- derailed his timeline.
Horsley draws a direct parallel to software development, where estimation regularly fails despite experience. "While 90% of the project will be the same, there's going to be one critical difference between the last 5 projects and this project that seemed trivial at the time of estimation but will throw off our whole schedule," he writes in a blog.
These disruptions often appear as unmaintained frameworks, obsolete development tools, or incompatible infrastructure components that weren't visible during planning. The software development environment changes rapidly, creating what Horsley describes as "unknown unknowns." Despite thorough requirements gathering, developers inevitably encounter unanticipated blockers, transforming familiar-looking tasks into complex challenges.
Horsley draws a direct parallel to software development, where estimation regularly fails despite experience. "While 90% of the project will be the same, there's going to be one critical difference between the last 5 projects and this project that seemed trivial at the time of estimation but will throw off our whole schedule," he writes in a blog.
These disruptions often appear as unmaintained frameworks, obsolete development tools, or incompatible infrastructure components that weren't visible during planning. The software development environment changes rapidly, creating what Horsley describes as "unknown unknowns." Despite thorough requirements gathering, developers inevitably encounter unanticipated blockers, transforming familiar-looking tasks into complex challenges.
Three trips (Score:2)
Re: (Score:2)
Re: (Score:3)
Kinda proud that, after 30 years of amateur water heater installs, I was able to install my latest water heater with only one trip (purchasing water heater + various connective bits + tools).
Re: Three trips (Score:1)
Re: (Score:2)
only two, and they can be pipelined for multiple projects...
1) Buy a few of every single damn pipe fitting
2) return what you didn;t use
"unknown unknowns" (Score:2)
I just refer to those as "ambushes" or "traps"
If it's just an issue you hadn't anticipated but that can be easily adjusted for once discovered, it's a trap.
If it's something you didn't anticipate AND is going to require significant accommodations in time and/or money (or possibly a refactor of the entire process), that's an ambush.
Re:"unknown unknowns" (Score:4, Interesting)
I ran into this formula 30 years ago, and it still works
"Take your developers best estimate, add 40% to it, then double it"
The 40% represents test cases that the developer did not consider and doubling it handles the need to rework the entire assembly
Some would call it sandbagging, but it has helped me many times over the past 3 decades
Re: (Score:2)
Of course, if you don't end up needing all that time then you become a superhero for a moment. Win-win.
Re: (Score:2)
Of course, if you don't end up needing all that time then you become a superhero for a moment. Win-win.
In my experience, if you significantly underrun schedule and budget you become a either a dumbass for not being able to estimate properly, or an idiot for not spending all the money in your budget.
Re: (Score:2)
Of course, if you don't end up needing all that time then you become a superhero for a moment. Win-win.
In my experience, if you significantly underrun schedule and budget you become a either a dumbass for not being able to estimate properly, or an idiot for not spending all the money in your budget.
I think you need new bosses. :-) The scenario you describe is why DOGE has a footing....
Re: (Score:2)
When I was designing circuits boards for a living, I had a rock solid estimation algorithm for a board from concept to deliverable product.
6 months. Regardless of the size and complexity of the board.
This takes into account that most of the time will be spent waiting on manufacturing for prototype turnaround.
You can do it quicker if you don't have a customer or certifications or need a production quality product, but we were a consulting design house.
Re: (Score:3)
I think the real problem is that humans will waste as much time as you give them and then some more on top of that. I've learned that anything that I can't break down into something I or someone else can accomplish in a day is just asking for trouble. You can't realistically predict how long they will actually take. The only thing you can do is try ta
Re: (Score:1)
Re: "unknown unknowns" (Score:2)
Re: (Score:2)
My version is to take the initial estimate, double it, and shift the units by one. E.g., one hour becomes two days, three days becomes six weeks, etc. Ultimately, it might be an overestimate, but not by much, and especially when you factor in other ongoing time demands.
Re: (Score:2)
Double number, next highest unit of time (Score:3, Insightful)
A wise early-career mentor said time estimates should be double then use the next-highest unit of time.
1 hour becomes 2 days.
1 day becomes 2 weeks.
10 minutes becomes 20 hours.
And so on.
Sometimes you get lucky - 10 minutes becomes only 4 hours.
Re: (Score:2)
As a developer I frequently fall into the trap of wanting to give an optimistic estimate, but in the long run it is frequently necessary to take a pessimistic view
Re: (Score:3)
So one of the problems is our non-metric time system.
Re: (Score:3)
If it was good enough for Hammurabi
nope (Score:2)
Sorry, estimating the time to install a washer, *by professionals*, is nothing like estimating the time for a software project by professionals. Why? Because software is orders of magnitude more complicated, for only one of many reasons. Any project will have complications. Accounting for them is a whole world different between a washer install and writing say a new browser.
Re: (Score:2)
'writing a new browser' isnt like most software projects though. That is more like putting in a whole new residential development. Which I would suggest to you if you take the entire process as a while from buying the land and acquiring the permits all the way thru selling finished individual units to buyers is plenty complicated with lots of room for surprises and delays, even mundane sorts of delays like unseasonable weather.
Most software development is a lot more like that washer installed. It is bolt
Re: (Score:2)
Most software development is a lot more like that washer installed. It is bolt some UI widgets and activities to these web UIs, you know basic plumbing. At least it seems like it should be, until you hit that bug and find out users in Latvia can't login because of some bug with code page conversion and path mutation in apache's url rewriting that won't let them reach the JWT signing micro-service...
No its not, even if you take your analogy and you are combining things together that are not necessarily tested together. It would be more like installing a production line of washing machine, then a feeder to put them into the dryer, then something that folds them and puts them away. And that particular job you have never done before, otherwise you would just reuse the code.
You can take a look at a washing machine and pretty much see all the major components and how the interact at once, I have never seen
Re: (Score:2)
I agree but the reason its harder is developing software is always something new, if not why are you developing it.
It would be equivalent to installing the same piece of software on a different computer, sure something on the system may break, just like installing a washing machine but after your first 20 installs most of the time its going to be as expected.
Re: (Score:2)
...the reason its harder is developing software is always something new....
Yep. When my clients ask how long it is going to take to create their new software, and how much it's going to cost, my stock response includes: "There's no way to know. Writing your software has never been done before." If they object, I ask them if they know 100% of everything they need, down to the most minute detail. When they have to admit that they don't know, they acknowledge that I have no way of accurately quoting a price.
Next time I need some software written (Score:2)
Re: (Score:2)
That will work, since the Internet is really a Series of tubes [wikipedia.org]
Re: Next time I need some software written (Score:2)
Accounting for all variables is a lost cause (Score:2)
This is an old problem in software engineering. There are so many things that developers forget about when they provide an estimate. Things as mundane as testing, bug fixes, and deployment, to unusual issues like unexpected complexity of an old module nobody has touched in years.
Rather than trying to account for every task and mini-task, a better approach is, ironically, choosing to *stop* trying to account for every little one-off task. Instead, stick with the first best guess, develop a multiplication fac
CTO ?? How?? (Score:3, Informative)
Based solely on the article he wrote, I question his ability to fulfill the role of CTO.
I don't know a lot about plumbing myself, but at least I know that I don't know a lot about plumbing and don't blindly assume 'it must be easy'.
Seems like the same kind of mentality would be needed to fulfill the role of CTO at any company, let alone a security one.
Re: (Score:3)
This finding is nothing new to anyone that has worked on code (or frankly, done any kind of "development" project whether using computers or in meatspace). But oh no Mr. CTO over there discovered that, as a non-plumber who didn't understand the landscape of his project (his house, his tools, and his washing machine), his time estimates suck, and now understands that there are
Work Rule #1 (Score:3)
When estimating the time it will take to do some task multiply by four and you'll be much closer to the actual time the task will take. My wife constantly underestimates the time something will take so I came up with this multiply by four rule years ago to keep her expectations grounded and my sanity in check.
Hofstadter's Law (Score:2)
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. https://en.wikipedia.org/wiki/... [wikipedia.org].
Which reminds me that I must be about due to re-read Gödel, Escher Bach.
Re: (Score:2)
Didn't Gödel, Escher, and Bach open for Emerson, Lake, and Palmer in '78
Estimates are estimates (Score:2)
NOT guaranteed predictions about the future
Engineers understand this
Managers seem to believe that they are ironclad guarantees and resort to threats and anger if they are not met
At best, estimates are informed guesses
I Used to Know... (Score:3)
Add on top of that... (Score:1)
How about the never ending changes and updates to Jira & Confluence. Or maybe some new security policy where you need to dink around with tokens everywhere, or a billion new firewall rules that stuff up traffic that nobody can figure out, or being forced to use Codeium that hangs and crashes your IDE, or new training policy telling you it's actually NOT OK to go touch someone's curly hair. Or the mandatory compliance training that takes 2 days, or the billion other things surrounding the job of softwar
The first 90 percent is easy... (Score:2)
It's the second 90% that's hard.
This is why any time I give an estimate: double it an add 50%.
By example, if I want to automate some task and I figure 2 days to put the script together; it will take 5 days before it's production ready including documentation, monitoring and alerting. Those 5 days effort will take 3 calendar weeks since I'll get busy with incidents and other projects.
A brand new house this screwed up? (Score:3)
After reading the article all I can say is I would have gotten the builder on the line and had them come back to do things right. Not drilling a hole in the wall? Not having the receptacle in the correct spot? And so on.
I can somewhat give a teeny bit of sympathy to guy not knowing what exact equipment he needed, but at the same time it does not appear, based solely on his description, he took a complete survey of everything involved and tried to figure things out before going to the store, He blindly went piece by piece rather than looking at the entire process.
Not a good thing to do when designing software.
Re: (Score:2)
I have found construction analogies to be an effective way to communicate software changes to 'customers'
Most people can understand the impact of moving the location of the bathroom in a house under construction, but few understand the impact of large requirement changes DURING software development
Re: (Score:2)
Re: (Score:2)
It's not even just post-covid. Even prior builders were pumping out slop. You can go back to YT and find videos from the 2010s where this is happening.
Re: (Score:2)
In fact this washing machine scenario should be a test given to prospective engineers - if they can't manage to plan the whole thing out before jumping in they shouldn't be qualified to be an engineer and encouraged to learn another line of work.
After years of experience (Score:2)
He then asked his 4yo son for a comment... (Score:2)
And the kid said something profound that perfectly aligned with his story that he is about to post to LinkedIn.
Poor planning (Score:2)
I read the article, and while I give him kudos for doing all the work himself, he loses points on overall performance which affects the way his diatribe should be understood. He gives a detailed narrative of how he did the whole project. He spent four hours and many trips to the store because he did not plan ahead or take time to read up, analyze, figure out the detailed specs and operations in advance. He seems to have had a knee-jerk response to fix each incidental issue as it arose - make a trip, buy
Re: (Score:2)
It's not just that he's unprepared. He doesn't know his environment, he doesn't know his tools, and he doesn't try things before he scurries to the hardware store. He doesn't try to take all the steps that he can take before he gets discouraged and runs for help, so he runs for help more often than he needs to. He doesn't even watch any youtube videos. This is a guy who would call ten meetings where two would do, because he wouldn't do any research, and he wouldn't check on all the various things he had to
Re: (Score:2)
I read the article, and while I give him kudos for doing all the work himself, he loses points on overall performance which affects the way his diatribe should be understood. He gives a detailed narrative of how he did the whole project. He spent four hours and many trips to the store because he did not plan ahead or take time to read up, analyze, figure out the detailed specs and operations in advance. He seems to have had a knee-jerk response to fix each incidental issue as it arose - make a trip, buy a part, install it - only to discover another downstream dilemma, without first figuring out the entire problem, infrastructure, parts list, workflow.
Having done a fair bit of electrical and plumbing work on my house recently, you are 100% on the ball. Education, preparation, and surveying makes things go smoothly. Doing things incrementally is taking a half-assed approach to any project. Like others here, it makes me question the qualifications this fellow has to be CTO.
FIVE TRIPS! (Score:2)
How is that a parallel to software engineering unless you're completely unqualified and have no idea what you're doing and no ability to plan out how to program? Now back in the real world, any plumber will have the parts they need on hand in their truck, combined with the knowhow of the different fittings to expect on the job.
Re: (Score:2)
Chris Horsley is incompetent at plumbing AND software development, that's my takeaway.
so close (Score:2)
"These disruptions often appear as unmaintained frameworks, obsolete development tools, or incompatible infrastructure components that weren't visible during planning."
Then perhaps question the planning, planning predicated on "unmaintained frameworks, obsolete development tools, or incompatible infrastructure components". Those certainly are visible to the planner that looks for it.
"The software development environment changes rapidly, creating what Horsley describes as "unknown unknowns." Despite thoroug
Five trips only proves you didn't make a plan. (Score:2)
Unlike programming, just jumping in without a full plan is actually a great way to waste time in the real world; or maybe it is actually just like programming judging from the quality of software we now have.