Hacker News Reader

Comment by 1337shadow | Hacker News Reader

Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations.

Add an estimate that you multiply by three in front of each, ie. if the dev thinks 1 hour then they should put 3. From my experiments: no multiplying factor turned to nightly and weekend work, multiplying by 2 turned to long (10 hours) work days, multiplying by 3 turned into comfortable work hours and quality work.

I've had success delivering quality code and respecting deadlines since 2012 or so with this system, but YMMV

Only problem: the customer might not like what he gets, even if it works exactly as planned.

View on HN

> "complete" means every single item the customer wants to see in the product,

Ah, but the customer does not know everything they want, due to the fractal nature of reality. The closer you get to the end product, the more detail is resolved, and more work is added.

Oh man, thank you for the fractal nature of reality. That is the perfect term to describe what I saw about ever-changing requirements. No matter how closely you define something, things will always keep changing on all levels when closer to actually "delivering" / launching. Adding time, costs, confusion, frustration. Fractal, yes, that's it :)

> No matter how closely you define something, things will always keep changing on all levels when closer to actually "delivering" / launching

Xeno's paradox [0] doesn't apply here. Some projects do actually finish.

[0] https://en.wikipedia.org/wiki/Zeno%27s_paradoxes#Achilles_an...

Although this sounds flippant, the design process is where unknowns should be uncovered. It is easier to change design before a line of code is written. Design is precisely what is needed in order for the dev team to break down the projects into tiny chunks where nothing is unknown.

Your time estimates should always include time for research and design. The customer can sign off on what you're about to write at the end of that (whereas beforehand you give them a wild ballpark figure made by senior devs - not management!)

Yeah but too many customers change their mind even after they've signed off. Then you're left with strictly enforcing a contract or making adaptations.

You're right, design is very very necessary and should be given plenty of time. But it's not a magic bullet.

In terms of contract, I have found this works best (recommended by my lawyer (a former ASF lawyer)): 30% upfront, 50% at first delivery, then they have 2 months to find bugs, final delivery is when the bugs are fixed that's when you take the last 20%. This way, you're certain to always get 80%.

If they want the liberty to "change their mind on the fly" then they should buy man-days which is a completely other thing. Or, they can buy supplementary mandays for whatever they want at the daily rate without changing the contract, or, they can just wait to finish this contract and start another one.

Another way of looking at this is that (unless there is a complete disaster) as you get closer to the end the uncertainty in the estimate decreases. When you get to the end, you know precisely how long it took.

it's pretty a well known saying that the last 10% of any project takes 90% of the time.

ReRe's Law of Repetition and Redundancy [4] somehow does not apply to you:

  A programmer can accurately estimate the schedule for only the repeated and the redundant. Yet,
  A programmer's job is to automate the repeated and the redundant. Thus,
  A programmer delivering to an estimated or predictable schedule is...
  Not doing their job (or is redundant).

[4] https://news.ycombinator.com/item?id=25797519

I think the explanation was made in another comment where they say "don't forget to estimate time for research & design", which explains why the *3 multiplier works for me. And yes, I feel that most of the work is redundant, there's always like network services of some sort or web pages, databases, linux servers, a humain interface, other services depending on the project like a message queue or a caching server or both, background workers and scheduled code execution... things I had been doing for ~10 years back in 2012. Data structures, workflows, they change between gigs, and each gig has its own particularity, but 90% is the redundant from a gig to another: HTML/CSS/JS/Python/SQL/Networking/Storage/Linux stuff

I've done backlogs before; both very high-level and very detailed; with and without mockups (even final graphic designs) and detailed description in the form of multi-page spec or user stories (depending on the fashion of the decade I was doing it in :).

I don't think having the detailed requirements made estimates much more accurate. However it made creating those estimates take an order of magnitude longer - developers needed much much more time to absorb all the details.

At that point I decided I only ever want to work with senior developers who have good imagination and can give reasonable triplets (solution, # of devs to do it, approximate time) for requested pair (idea, quality level).

Software development is the process of writing a complete specification, including every single button and label. If you have a formalised complete design, you could write a compiler to do the work for you.

I forgot to add this to my other comment. Yes, a multiplier works wonders. (I typically added 30% to my own estimates, which covers all the little incidentals that trip you up, and coffee breaks). I've not been forced to work longer than an 8hr day since the 90's.

I thought your comment stating that time should be added for both research & design was actually a reasonable explanation for why I need the *3 multiplier!

Back when I was a product manager, there was an engineering manager who would drive me crazy. He had this idea of a 90% schedule, by which he meant a 90% chance of hitting if everything went as planned. Everything never went as planned.

He probably read Goldratt's follow-on to The Goal, Critical Chain. Critical Chain Project Management is the specific term. Goldratt tried to sell software to companies that would help them make schedules like that, but a large component (often ignored) was collecting historic data, and running models. Most companies might do one of those, but rarely both, and of course models with only speculative numbers are absolute garbage. In my experience, places that tried to apply CCPM never actually grokked it, and it was some manager's obsession because they were buzzword crazed (like many big-A Agile offices).

I think this was a little before that (mid-90s) but maybe something related.

Reply on news.ycombinator.com