[0xbadcafebee]

  > For most of my friends and colleagues at mature software companies,
    (randos at a company with a lot of money)
  
  > there are usually three ways for an item of work to get put on the board
    (we assume that everyone should always do work in the same basic ways and there's no reason to change the way you work other than personal preference)
  
  > Thats not to say that every company is a disorganized mess or a bureaucratic hell scape but
    (no, no, they all are)
  
  > and then at times get blindsided every now and then from a new business priority or an incident
    (your executive team is disorganized and your operations are unstable; again, normal)
  
  > we felt that reigniting the agile vs. waterfall armistice needed to be torn up

Wait... what? This article isn't trading on clickbait tropes about a black-and-white world for HN points? Ok, I'm listening.

  > We implemented them faithfully, we all read the John Doer book

So you read the 2018 book that was written after a Silicon Valley process used by mega-unicorns... but not the 1983 book that process was based on? Foreshadowing? I'm going to call it and say "they should've read Deming".

As a (lengthy) aside: planning is bad most places because most people don't have multiple perspectives. Anyone can have multiple perspectives, but it requires both an interest in other perspectives, and a means of communicating (and receiving) those perspectives. Those are rare commodities.

Sales and executives set deadlines for objectives without talking to the people who do the work. They don't have an accurate perspective of the engineering (or other) departments. If they knew there is no time, and they're crushing the morale of other teams (and why that's very important to avoid), they wouldn't commit to things when they don't know if it's feasible. Similarly, when engineering gets word they have to throw out their current work and rush to finish something else, and they had the executive/sales perspective, this demoralizing slog might not feel as bad.

Even within engineering, at every job I've had, splitting up teams creates dysfunction. Engineers stop understanding the entire system's architecture. They stop designing with the other pieces in mind. Their perspective becomes a laser beam shot at their own navels. This contributes to difficulty planning between teams, and invents new problems that have to be planned around. If they fully understood each other's perspectives, they wouldn't have those issues.

Today nearly all online products are developed with a 2010s-era "this is the only way you can make software" mentality. Your product is never finished, is constantly changing, re-architected, etc. It's cargo cult. You don't have to develop this way. You can make online products like physical products. But because people today are incapable of thinking outside this framework, planning is stuck in this bizarre world of only considering a few quarters at a time. This wastes time and money and creates more problems. Software architects, product owners, and executives, force themselves into working in crappy ways, and then struggle to find their footing.

This article is an example of people struggling to find footing. Rather than deal with the fact that the way they're working is causing them problems, they're instead focusing on how they can plan for the work that's causing them problems. It's like having a bum ankle while playing soccer, and rather than stop running on the ankle, you're trying to figure out how you can continue running on the ankle. Stop doing the thing that's causing you problems.

[YZF]

This. I would also add that people are not motivated/incentivized to have those different perspectives.

All of this is very much related to: https://en.wikipedia.org/wiki/Conway%27s_law

Your software product is never finished is partly a reflection of how you structured your organization. That is often the root cause of your problem.

[apsurd]

Isn't software never being finished a unique trait of software and therefore intentionally used as a value?

I get that never-done software tends to justify shitty products.

But how would you suggest taking advantage of software's features vs do you really recommend building it like a bridge?

[jason_oster]

> You just cobble something together to sell. It need not be any good. As long as you can fool people into buying it, you can always try to make better versions later.

> So then you get these version numbers, even with decimals: version 2.6 or 2.7. That nonsense. While version 1 should have been the finished product.

E.W. Dijkstra

Translated from the original Dutch [1] [2].

Dijkstra was convinced that programming was a formal application of mathematics. If the program has a bug, the math is wrong. If the program is missing a feature, the math is incomplete.

Personally, I feel that building software like a bridge is the better path. You don't want the bridge patched with new supports and "stability improvements" every time another fatal design flaw is discovered any more than you want to update your OS and system libraries every time a new CVE is announced. These scenarios are both disruptive and costly. But somehow, we have been collectively tricked into accepting it as an unchangeable fact of software.

The advantage of software is that I can "replace the whole bridge" with a completely different design if I wish. Not merely patching an existing bridge in place, with whatever poor aesthetics and integrity problems that leaves behind.

[1] https://www.cs.utexas.edu/~EWD/video-audio/NoorderlichtVideo...

[2] https://youtu.be/-Uae9_pgZzE?si=twwh7k7cPKRB2gvJ&t=50

[0xbadcafebee]

You could keep whittling on a chair leg forever, but I don't think that's a value.

I think software is a material, like steel. And like steel, there are properties of software you can take advantage of to build in different ways. For example, its ability to be turing-incomplete, or stateless/immutable, formally verified, interpreted vs compiled, composeable vs fully integrated, distributed vs isolated, etc. You can use the material many different ways, thus building a very different product.

It's also a material like a gas, in that it fills any container it's stored in. Or perhaps a flame, as it consumes all resources you give it? Or a clay, as it's easy to work, but needs to be specially treated for it to be stable long-term... Anyway, these properties of the material need to be better understood, so builders can understand the right ways to use it. If you are building a bridge, I sure as heck hope you're using the right methods.

[shib71]

Real world example of:

    Patient: Doc, it hurts when I do this.
    Doctor: Then stop doing that.