'My Washing Machine Refreshed My Thinking on Software Effort Estimation' (cosive.com) 85
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)
It seems like in the US, unlike most other countries, dishwashers don't always use the standard 3/4'' fitting used by washing machines.
One has to wonder why this isn't mandated.
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
What professional plummers do (Score:2)
Part of why they charge so much is that they carry the hardware store with them in their truck.
Even then, they have to make a trip to the hardware or home-products store for something that was supposed to be on the truck but they ran out of.
The Law of Galvanized Pipe (Score:4, Interesting)
Any attempt to repair a leaking galvanized pipe fitting will end with fracturing the fitting.
The way this works is that galvanized pipe is vulnerable to corrosion in a way that copper pipe is not. If a section or fitting of galvanized pipe is leaking a a consequence of corrosion, it is a certainty that any attempt to apply enough torque to overcome the corrosion preventing a pipe to be unscrewed from a fitting will end up fracturing something that is weakened by corrosion.
Re: (Score:2)
I do most of the plumbing myself and it only requires me one trip most of the time. Unless the store does not have the part I need. Household plumbing is extremely simple comparing to software development. It usually takes me longer than it would take a plumber to do similar job. I usually do it better and don't have to come back to fix things as it happens with plumbers. That is because I care and want to do things right.
The only time I would hire a plumber is where I tried
Re: (Score:2)
Any building job, period. My father was a builder and had a workshop (and truck) full of hardware and still needed to make trips to hardware places and in extreme cases change the plans while working on a job because there was always some odd thing that you didn't realise you needed until you got to the point where it was required. An example being discovering, once all the dirt and cobwebs had been cleaned out, that what should have been a single bearer on the plans was actually two shorter ones joined w
Re: (Score:2)
"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:5, Insightful)
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:3)
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: "unknown unknowns" (Score:2)
Re: (Score:2)
I get it. Your prior employer is why DOGE has a footing. :-/
Re: (Score:2)
Re: (Score:2)
Or you lose the contract because your bid was too high. Whether the competitor's bid is realistic or not is often irrelevant to the decision makers.
Are you advocating for unrealistic bids so that you win, only to come back with costly change orders later?
Re: (Score:2)
Or the low bidder won because they forgot something.
In the construction business, they will go out of business if they repeat. Contracts are mostly fixed costs and the bidder will have to eat the overage if they make a mistake.
If you get a cost-plus contract, it's because you have proven yourself to the bid owner. If you've really proven yourself, there won't be a bid and you can do time & materials job contract.
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:5, 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
Re: (Score:2)
That is why I always make my estimates way higher to give myself extra time just in case. Of course, others don't like that. :(
nope (Score:3)
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:3)
...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:3)
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 factor to account for unknowns and risk, and adjust it as you see that it's too big or, more likely, too small.
Interestingly, this is precisely what story pointing does. By specifically choosing not to try to estimate time, but instead focusing on *relative* complexity--a concept that is usually easier to gauge than actual hours--story pointing provides a framework for making those mathematical adjustments over time. By tracking velocity, a team over time learns how long it takes, on average, to deliver 50 points, or 100 points, or whatever. There are still estimation misses, but they tend to come out in the wash. Further, measuring "velocity" provides a self-adjusting multiplication factor, simplifying the process of adjusting it up or down.
The only way to improve estimates, is to measure estimation accuracy and make adjustments. Story pointing and velocity measurements, provide a framework to do this automatically.
Re: (Score:2)
My approche is to quote only planning and setting up fees. Most project will reuse the same base and infrastructure as code stuff. I do my fix price for that, because I know precisely how long it will take me to setup. This will usually include a PoC of the required business logic, to serve as a conversation starter.
Everything else is by the hour. We can take as long or as little time as you want to get to your MVP, it's up to the customer.
CTO ?? How?? (Score:5, Insightful)
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
Re: (Score:2)
I don't see the relation. The installing a part in a washing machine is easy, if you have the skills. And to judge that, I'd read the instructions and see what tools, parts and other things were needed. Then I'd head to the hardware store if it seemed doable with my current skill level, pick up the necessary parts and then check out what those require.
The replacement part is well defined. It's designed so anyone with the requisite tools and skills can replace it, everything is well known and understood, and
Re: CTO ?? How?? (Score:2)
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:3)
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)
Scotty's advice to Geordi (Score:2)
How long did you tell them it would take?
An hour.
How long did you think it would take?
An hour.
Laddy, you've got a lot to learn if you want people to think of you as a miracle worker!
Add on top of that... (Score:2)
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.
Re: (Score:2)
Splitting effort from calendar day is always a good idea!
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:Poor planning (Score:4, Insightful)
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 do ahead of time.
By exactly the same token, his numbered list of potential development problems is mostly a series of excuses for poor planning skills.
1) failing to maintain their code (he says "our" which implies it's in house) which they planned to use. they planned to fail.
2) they failed to maintain their development tooling ecosystem, same
3) they failed to keep up with updates to the OS they were using, which are announced well in advance
4) this one is reasonable
5) this one is also reasonable but doesn't bear any resemblance to his problem, because he had the opportunity to survey the requirements before he began.
Also, "consumer grade drill" doesn't really mean anything here. I have a Ridgid compact brushless drill, and they don't warranty it for commercial use so it is by definition a consumer grade drill. It has a 1/2" chuck and can run any common hole saw. (It's also more than strong enough to hurt your wrist, especially if you select low gear.) But on top of that, he very likely could have gotten the same size hole saw with a smaller arbor that could run in a 3/8" chuck, that's not a very big hole saw. Or maybe he has a drill with a 1/4" chuck, which would be stupid as your only drill. Most drills have a 3/8" chuck. My lady owned a drill with a 3/8" chuck before we met!
Re: (Score:2)
Yes, exactly. My hole saw works just fine on my "consumer grade" drill. he was drilling drywall. A simple hand held drywall saw would have worked well too.
Re: (Score:2)
It would appear that his "What did I learn?" section is also missing a crucial item.
He bought a new house and didn't contact the builder to resolve the laundry issues? That's like buying a new server with missing parts and trying to fix it yourself.
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.
Re: (Score:2)
It seems Agile is not a good fit for construction projects haha
Re: (Score:2)
Prior Propper Planning Prevents Piss Poor Performance.
FIVE TRIPS! (Score:4, Insightful)
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:FIVE TRIPS! (Score:4, Funny)
Chris Horsley is incompetent at plumbing AND software development, that's my takeaway.
Re: FIVE TRIPS! (Score:2)
Yes, that's exactly how software engineering works, we know all the fittings, everything we need is back on the metaphorical truck and software estimates are spot on because we never ever underestimate unknown unknowns, professionals don't even know what blind spot means.
Just like plumbing, everything is always on the truck and never, I mean never, does a plumber have to say "How TF does that even work" because they're PROFESSIONALS, with every tool at their disposal and there is nothing they haven't seen b
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.
It's not over till it's over. (Score:2)
Unless you have it up and running in production, the product is a POC at best and may fail at any moment. In fact, many projects fail at the very last stage, when delusional managers and overburden developers realise that what the managers wanted is not actually possible.
Scrum Master Conjurer Level 100 (Score:2)
Software effort estimation is just one big divination exercise. The work is done when it's done. That's it. Until it's finished, there is no way to predict how long it will actually take. If you press your developers for an artificial effort estimate you will just end up with a broken feature created under time pressure and you will end up paying it back double in money and time further down the line.
Whose line is it anyway? (Score:2)
Welcome to Whose Line Is It Anyway? A show where everything's made up and points don't matter.
Very poor analysis (Score:2)
The author of this post is contrasting the efforts of a hobbyist failing against the efforts of the professional. A professional in their field would rarely fail an estimation exercise, and that applies to software as well as plumbing.
Once you achieve experience enough, estimates should be expected to be mostly accurate. Failures to estimate time properly in software development boil down to poor planning.
Ninety-ninety rule (Score:2)
Hidden caps (Score:2)
He doesn't seem to pay attention to details if he didn't inspect the tap enough to notice the cap.