Comment by commandlinefan | Hacker News Reader

Comment by commandlinefan | Hacker News Reader

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting "the date" is the only thing that's tracked (but it also never happens). It's even justified through vague analogies like Joel Spolsky's admonition that "you wouldn't buy a pair of jeans without knowing how much they cost" without ever doing a slightly deeper dive into how developing software is different than selling a pair of jeans.

All of the collaboration artifice that the author is referring to seems to me to always be a futile attempt to meet "the date". That software development might itself be _inherently_ unpredictable is never even considered, even though there are a lot of reasons to suggest that it is: by definition, the software you're developing has never been developed before, or else you could just use the thing that already exists.

I had a glimmer of hope in the late 90's when the agile manifesto was published - everything about it seemed to me to read "software development activities can't be coordinated like a wedding banquet can, but you can at least make sure that everything is tracking toward a shared understanding". I guess I shouldn't have been surprised when "Agile" became "tell me exactly what you're going to do and how long each step will take" almost the instant of its inception.

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget.

They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money.

Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

The corollary is that it's only the budget that is tracked that anyone cares about.

Often your salary is not on that budget, so if it takes you twice as long but you don't have to buy/hire/use AWS, winner.

As someone who once spent two months reworking a system because a 4GB Oracle instance was okay, but 8GB was verboten, I agree.

Salary does not need to be on the budget because it is the same whether you work 40hrs per week or 80.

To me, the _real_ thing that matters isn't quite date or budget, but something that somehow acts as an umbrella to both of them: the promise. When you promise to deliver something by a day, or within a budget, it's very clear whether you met your promise or didn't. However, when it comes to functionalities, there is more of a grey area: you can start to argue that something _mostly_ works, that some bugs are always inherent, or that this functionality actually is not really needed because the problem can be fixed in an operational way, or that the requirements have changed, or that it was just a nice-to-have... but money/time don't have this grey areas.

I feel like everyone in this reply chain is looking at this from a different angle of Fast, Good, Cheap. Pick two.

That was literally the first thing I thought reading from OP comment down to your parent.

Then I thought: Sure but management made the devs promise these things. We don't do it of our own volition (exceptions prove the rule - some people are conditioned to do it of course).

Exactly. The old Iron Triangle. One of the three will always be most important depending on the constraints. Two of them will be possible.

That might be true in certain kinds of companies. I never worked in consulting, and I've always been so far down the totem pole that nobody has ever expected me to adhere to a monetary budget. I suppose I am extremely lucky, but at all places I've worked, I had no idea how much our software cost to build or how much revenue it brought in. If we needed a software license or development systems, or a specialized piece of hardware, we just requested it and it materialized. Often I didn't even know the per-customer unit price of the software. The only constraint that ever made it down through the huge tree of managers was the due date. Someone five managers above me was probably sweating the budget but to us low level developers, budget was never even a concept.

It varies on company culture and business model. Your situation sounds like R&D shops and how they often manage things.

R&D usually is budget constrained at the company or division level (% of revenue) and you can only ask for it once a year. Next year's budget time determines if you get more or less. Time constraints come indirectly (proof of progress for budget expansion or more importantly declining revenue from existing products),

But the only way management knows how to hold R&D accountable to ship is with dates as a forcing function, and those dates are often invented or organized around industry events (conferences, press events, etc).

There are other ways to manage progress, dates are the most common lever. That can work but can be abused by bad management. I've usually preferred shops that say "it ships when it's ready", but they require special circumstances to maintain funding and measure progress. In general if what you build is more important than when it ships, "it ships when it's ready" is better than hitting a date with a dud. So long as there's value for the budget and a way to measure it.

Hacker News discusses "deadlines" as one of many management strategies. How much depth is there really? Other industries use bonuses as a simple management strategy. The kinds of people writing blog posts like this do terribly boring work, which is the real problem.

As far as software development goes, money is almost perfectly correlated with time.

That's never been true. At minimum, as it's missing the most important variable: quantity of people. 1 person working for a year vs. 12 people working for a month could cost the same and have dramatically different results. And it ignores so many other aspects of effective use of productive capital in software dev (toolchains, cloud, AI, etc.)

You are right, I didn't think that through properly!

I program for 20 years now and I think that what many people do wrong about these estimates is that they give them too early. The truth is that for many project the only truthful answer you could give someone on the question hoe long it takes is: "That depends on many things some of which I don't know, some of which we both don't know and some of which potentially nobody knows." After that you should say: "In my experience it takes betwern x and y weeks, with a lot also depending on how responsive your side is."

Time estimates are always hard, not only in programming. And outside of programming one of the main insecurities is customers changing the plan or wanting adjustments. This is the side you can't really control, so it is best to get a feeling for the customer, their communication patterns and their expectations early on and factor it in. The other insecurity is tough problems you encounter during the programming phase. How well you can deal with those depends a lot on how experienced your programmers are and how much they were involved in the inital process.

The truth is that the latter insecurities make up a main part of the whole thing and it has to be okay to tell a customer you can't give them an estimate before you know some more details.

> the date is _always_ more important than the actual deliverable. Always.

Hah! You just gave me an idea for a new methodology. Date-bound delivery.

- The business tells you what they want, as they do

- The business tells you when they want it, as they do

- The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted.

- As the date nears, more edge features get trimmed

- As the date arrives, something is always ready to deliver, no matter how miniscule

Such a methodology would ensure delivery, but not necessarily the contents of that delivery. Post mortems would no longer discuss why something took so long, and instead would focus on why features were cut.

If, as you say, the date is always more important, wouldn't such a methodology be worth trying?

that's really what agile was supposed to be. at least in the places where I saw it was successful.

every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design.

every week, priorities can adjust, etc. and the cycle continues. hitting the actual 'release date' becomes much more knowable when you see the tangible date-driven progress on a regular cadence.

Yes, but expanded to the full deadline instead of only the short iterations.

The business does not care about week long deadlines. They need something on May 23 so they can achieve _______.

My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on making it happen. In other words, usually it doesn't happen.

But date-bound delivery is already our default mode of operation. We just don't like to admit it. We are going to deliver something on this date; we just don't know what, yet.

I completely am in favor of date-bound delivery.

However the point of the weekly cadence is that the business does care about adjusting scope and priority towards hitting that deadline on May 23, so that they know what they're going to get on May 23 and have the power to adjust it.

Especially if the goal of what is delivered on that date is not clearly defined. It almost never is.

Most projects can be summed as "give me $X, I'll come back in 6 months, and ask for more time and money". or "here you go"... "that's not what I wanted".

It's a key risk mitigation toward a hard date to know every week if you're still getting what you wanted.

Velocity is overblown as a metric. It's one metric among many that can signal a few things (e.g. quality problems because bug fixes are overtaking features) but isn't as much of a lever as some say.

Yep I agree. Iterations are still good, demos are still good, ever-evolving scope discussions are still good, regardless of the overarching methodology.

That pretty much describes shape up : https://basecamp.com/shapeup

I have a mixed relationship to it, but the scope cutting part of it works extremely well.

The focus it brings on focusing on the problem solved rather than on the concrete solution is also healthy I feel.

My technique was to always schedule the important (not difficult) things first.

That meant, that as the inevitable schedule crunch arrived, the things that were tossed in the skip were not important.

I call it "Front of the Box/Back of the Box." I basically got the idea from The Simplicity Shift[0].

[0] https://jenson.org/The-Simplicity-Shift.pdf

A startup I worked for twenty years ago used that approach: we shipped an update once a quarter, every quarter, no matter what. We'd begin with a week of planning, build as much of the plan as we could, then cut anything we hadn't finished and release whatever was left. Of course the trick was to build the high-priority items first.

I loved it and I think it was one of the more productive development methodologies I've ever seen. It made sense, it was honest, it required no heroics, and it improved our long-term design work by forcing us to break every grand plan down into a series of incremental deliverables.

> Such a methodology would ensure delivery, but not necessarily the contents of that delivery.

But sometimes/often it doesn't matter that you delivered 70% by the agreed date, since less than say 90% is useless.

We have an upcoming deadline. By a given date, some government system shuts off and another must be used. By then the customers must run functionality tests to prove their software handles the new system.

If all of those tests don't pass it doesn't matter that we got most of them by the shutdown date. Customers won't get access to new system and their production halts, not acceptable.

Scenarios like this is quite common for us.

As others have said, this methodology exists in various forms already.

It has a major practical problem:

> The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted.

If the team doesn't think they can deliver something that the business feels is non-negotiable, the two are at an impasse. The methodology gives no way to resolve this impasse.

And this problem is exacerbated because the business will frequently be wrong about what they want and when they want it by, and the team will frequently be wrong about what's achievable by the given date. And both parties know this, and it starts to affect how they interact with one another when discussing dates and deliverables.

And to make things even more confusing there's often some amount of unacknowledged deception. Sometimes when the date arrives everyone collectively just pretends that the thing has been delivered in full. Because it doesn't actually matter whether it has.

The natural extension to Spolsky’s quote is: Unless someone else is paying for the jeans.

I think the smaller the organization, the more likely that a software projects has real stakeholders. In bigger, more mature organizations, the experienced players have arranged their affairs so that their career progress doesn’t depend on delivery of software: Late, early, or ever. For instance I work on the “hardware” side of technology development, and I tailor my annual performance review goals so that a deliverable is satisfied when I can demo it with code that I’ve written myself.

I love that LLMs are already copying humans when it comes to estimates. When asked for estimate they provide a very padded estimate of weeks.

Then they proceed to implement the solution in 30”.

That's because LLMs don't actually think, they pattern-match. Since all the existing estimations out there are made assuming that a human is going to perform the task, the estimation that the LLM provides has the same inherent assumption. The LLM doesn't have a corpus of LLM-led estimations so it cannot take that into account.

Reply on news.ycombinator.com