Hacker News Reader

Comment by hnbad | Hacker News Reader

I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars.

I understand the numbers are given as an example but I think the problem is that the scale of the task hardly justifies the complexity of the planning and using "teams" and "weeks" as sizes instead of "developers" and "hours/days".

View on HN

The thing with software is that it takes two weeks to get to 90% finished, then two years to get from 90% to something 100% production ready. Having worked over 5 years with ecommerce software I could write a fully working e-commerce site in two weeks, but then the marketing teem want to have it all integrated with 50 different tracking systems, and support 10 different payment systems in 30 countries, and have the correct VAT handling as well comply to local laws, integrated shipping systems, and of course 30 different versions of the site in all languages. And integrated with business software. And every moth the marketing team want to start a new compaign, buy 3 and get 20% off, buy only milk and get 30% off, buy a red shirt and get 25% off, discount codes, discount codes that includes shipping, etc. Did you know that different products have different VAT in different countries and within the same country as well? And shipping should use the average VAT from the products ordered - depending on country...

This has been the case for almost every project I've worked on. It starts out as super simple, and then the edge cases roll in, and then the feature creep, and then the bugs start piling up, and now it's been years on a "just a couple months" estimation.

Sure but the article was about a linear process with the final product being understood to be an MVP, so the remaining 10% (which really feel more like Zeno's arrow, i.e. the sooner you get to 100% the closer the time necessary to complete the remaining work approaches infinity) won't be part of the calculation and the 90% solution is the first "definition of done".

The article clearly points out discount codes as an example for a feature that could be moved out of the initial spec. And the spec itself is clearly missing various features necessary for the app to be even remotely usable.

> I popped a monocle

This is why I don't bother with estimates any more - not because I think it's impossible, or even necessarily too hard, but because I've observed (consistently over a 30 year career) that it's pointless. Even if you could estimate with perfect precision exactly how long a software task was going to take, they would just push back, say, "that's too long" and argue with you until you told them what they wanted to hear.

Early in my career I had this. I was given a task and a deadline, and told to prepare a plan. I estimated the plan, and it came out to longer than the deadline. I presented this, only to be told "but that's longer than the deadline! go fix it!". So I shortened all the estimates and it fit the deadline. When I presented this I was shouted at for shortening all the estimates, and told to go back and do it properly.

Around this point the penny finally dropped that software estimation is a political process, not a technical process.

That's really tough, and I'm sorry you had to deal with it.

I was lucky in that I was dealing (in both cases where I've run similar flows to this) with above-board exec teams who wanted the best quality information I could give them - even assuming that estimates are just assumptions - even if it meant having some tough conversations about scope or headcount.

Like I said, it was early in my career. I now know how to handle this - ask more questions and work out what the real objective is. Also refuse to let people shout at me ;)

Unfortunate; most of us have had experienced such situations separately, it sucks when they come together in a "rock and hard place" situation.

Good managers / business leads/ execs / champions CAN be reasoned with, as long as you find common language, think and understand their priorities, provide alternatives that meet their underlying goals (all of which frequently falls on the presenters). E.g. in your situation, it may be that unspoken expectation was to cut scope or increase resource contour or find another way to meet deadline rather than just changing estimates; or something completely different.

Occasionally though, you're as you say stuck between other people's indecipherable politics. I find in such situations, I'm most comfortable speaking the most honest truth and working hard, openly and explicitly, to understand/ask/bring to surface everybody's actual critical goals.

> understand/ask/bring to surface everybody's actual critical goals

This, exactly. Now I'd be working out what the actual objective is and how I can achieve that.

> CAN be reasoned with

Sort of. What you really end up doing is making enemies and burning bridges to defend a software estimate that ends up being completely unrealistic anyway. Sure you can "win" an argument with a "stakeholder" if you fight hard enough, but you'll pay for it later. They want to hear what they want to hear.

I've seen some managers who like to turn your estimates into a stick they can beat you with. They can never be satisfied.

Instead, we as an industry prefer to adopt magical thinking where we pretend that software projects aren't hard and lengthy and risky (even when the domain and tech are well understood), then we act surprised when the project "overruns".

I'm not saying that this isn't a good estimate for "doing it properly". I'm just saying that no client will let me bill half a million dollars and spend the better part of a year to build them a bare bones ecommerce website from scratch that doesn't even have invoicing or an admin interface.

I'm mostly just saying if the author is able to sell what amounts to half a broken Woocommerce installation for half a million dollars (assuming it's at least a team of two billed at $20/hr), I must be in the wrong market.

This is extremely difficult to convey to non-developers though because they often look at software as a house and think "there's tons of houses (ecommerce sites) built every day and it's down to a science - how hard can a house (ecommerce site) really be", but miss out on the fact that all houses have pretty much the same structure of a foundation, framing, wiring and plumbing, and a covering of paint and a roof - this is largely kept consistent and we'll implemented by building codes.

I can only speak from my own experience, but every single web application I've worked on has had a wildly different structure than the others and the only consistent thing between them has been endpoint routing mechanisms.

Then this is, IMO, a problem with the software developers (in the broadest sense, not just programmers). Most e-commerce in fact, DO share the same framing, wiring and plumbing as all the others. This is why you can buy an e-commerce package off-the-shelf and customize it.

If the business is a relatively generic e-commerce store, it should usually not be building bespoke e-commerce software. Unless, of course, there is some technology feature that will be your competitive advantage/differentiator. But let's be honest, that's pretty damn rare in the space of e-commerce stores.

I think I would have popped a monocle too, had that been the real example and estimate from a team!

I tried to think up an accessible example that didn't require too much context on the part of the reader, so obviously, as you correctly point out, all the numbers are made up, and I'm trying to use it solely to demonstrate the workflow :)

> all the numbers are made up

Well... have you actually applied this process successfully? If so, wouldn't you have some actual numbers to point to from a past project? Names and details changed a bit to protect the innocent, of course.

I have, yes - or I'd feel a bit like a charlatan writing about it!

The problem with the real world examples is the business domain, which was hyper complex and the specific "pieces" of work I described wouldn't have been easy to grasp for most not familiar with the esoteric side of fintech that the project took place in.

So I went with a simpler, albeit contrived and more accessible example.

Were they monocle-popping results?

Reply on news.ycombinator.com