Hacker News Reader

Sorry, teams can't be only devs. That's IT or something, and implies that tech isn't the business.

Team has to include 'the business', as in, voice of customer, features lens, in those tradeoff prioritizations along with what do we engineer, and what's the truth of where we are on the field, for delivering what satisfies the customer and our constraints. // Hat tip Rands in Repose.

As for "Ultimately it's not about trust, it's about accountability and predictability" that's precisely the characterization I reject. Accountability means you earn your keep by being effective. Predictability, well, milestones come and go, the software gets used forever. That's the predictability needed, which goes right back to effectiveness. You won't magic either of those in a Jira.

The team I work in has a product manager, a designer, a cloud infrastructure automation engineer, as well as seven software engineers. Together we collectively advocate for our users and help with those tradeoffs.

> As for "Ultimately it's not about trust, it's about

> accountability and predictability" that's precisely

> the characterization I reject.

How do you know if you're effective? Perhaps it's a difference from one company to another but I don't think it's unfair that my manager (and others dependent on my team's output) want to scrutinse my decisions, and the outcomes of the team.

Likewise, I can scrutinise the choices of engineers with weekly sprints, to ensure the goal is hit i.e. a timely release with flexible features, or a feature complete product that might overrun.

JIRA doesn't magic effectiveness, agreed. It can help show the truth of the decisions taken toward a goal and how work is progressing. I'm not advocating waterfall (any estimate of "this fully specced feature should be finished in two months" is pure fiction) but JIRA or other similar products can work to let managers know ahead of time, "We're not going to finish this by our initial estimated delivery date." That's a useful tool.

I’m starting to be fairly confident that the ‘budget’ lever for a project might as well be disconnected from the feature and timeliness ones. Spending more money doesn’t make things go any faster. Especially adding more people makes things fo slower.

Completely agree on the not going any faster point. The Mythical Man Month demonstrates this exact concept perfectly.

The budget lever is still available in limited forms e.g. do you devote two engineers from the team to project A or three? The point here is that the engineers have to be already up to speed on the codebase and already know how to work with their colleagues; and adding more on project A leaves fewer for project B, C, and D etc.

Also there is monetary budget. Can I solve an engineering inefficiency by throwing larger servers, or buying a licence for a relevant software service?

> "do you devote two engineers"

Maybe one could say that in the beginning of the project, one can use that budget lever, but not in the end (mythical man month)

It is connected... until the project start, eg. in the broad general planning phase, when you press "start" it gets disconnected and stays that way until you ship a usable (±new) version.

Once the wheels are in motion you can only accelerate by breaking off sub-projects/teams... but if you're at a point where this can accelerate you, it means you were already slow-as-hell :|

> Second, how well can you predict what you can achieve as a developer in one day vs one hundred days? The estimate for the former is more reliable.

I’m not so sure that’s true. I mean, it’s probably not worse but often I find that my gut feel of “it’ll take for weeks” is more accurate than trying to break the feature down beforehand and add up the parts. I’ve always said that the estimation process rests on the hope that if you break a big wild-ass guess into a lot of smaller wild-ass guesses, the errors will cancel out. I don’t think that’s always the case.

> every project has three levers: budget, timeliness, features. Choose two

You forgot about quality. It can blow the other 3 out of the water.

That's non-negotiable to me. You can make a short-term decision e.g. this implementation will only scale for the next month, but automated testing, clean code, other standards must be maintained.

I think I have to agree. I understand the impulse to say that it's implicit, and certainly the desire to build a quality product usually is. But in reality, to actually verify quality before you ship often requires a lot of costly infrastructure and time-consuming work. So in practice, it really is a lever that often gets sacrificed---usually at the alter of the timeline. You could argue that a feature that is broken isn't a feature, but there are many subtle degrees of broken-ness. A bug that happens 1 in 1000 times might be acceptable, or it might not.

...if you consider quality a lever, you're not the kind of person anyone should want to work with!

You agree on quality standards before you begin, and you deliver the quality level that you agreed beforehand, not more, not less (you deliver sooner if it goes better than expected giving the product-owner ability to add features or redirect effort actually using your "superpowers" if any to give the business a real advantage), at a profit or at a loss. Otherwise you're not a professional, you're either an amateur or maliciously dishonest/exploitative!

You could just as easily say that you agree on the feature set beforehand, and you deliver that feature set, not more, not less (you deliver sooner if you finish the features early).

"The quality level you agreed beforehand" is meaningless without some infrastructure and processes in place to verify it. And in practice, those infrastructure and processes are compromised at least as often as the feature set, the budget, or the timeline.

Quality is implied within the feature/scope grouping. Its always a three leg stool trade off for balance. Changing your quality output is just reducing or adding to scope requirements.

Budget = Resuorces / Time = Time / Scope = Quality

Quality could be grouped with features as "usefulness" of the software. Low quality software is unusable, or more expensive to use.

Timeliness has an equally direct impact on software value, but in this planning context it makes sense to distinguish what is delivered and when it is delivered.