[michaelcampbell]

If history is any guide, commit to X, deliver X/5, then start Y. There's always time to fix stuff, never time to do it right.

A project manager inadvertently laid this out for me when I was new in my career; he didn't mean to put it like this, but this is what came out. (Note that I'm a software developer, and at the time the software I wrote was not "shelfware", but rather installed into big enterprises' data centers. Pre cloud)

NO ONE wants software done right the first time. Because, when you slam the happy paths out there for the customer as fast as you can:

* Sales wins because they can claim "Feature X" being sold and get their commission

* The customer wins because they get to complain about x or y being bad, incomplete, or whatever they want to whinge about and feel like they're part of the solution

* Customer Support/Sales Engineering/etc wins because they get to appear to be "responsive" to the customer by quickly reorganizing ongoing work to take care of the "urgent need"

* The Project Manager wins (2x!) because they can now a) do the same "response" dance for the C-levels, and b) berate the software development staff and show their authority and working under pressure skills

* Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.

[manmal]

I don’t mean to attack by going through these points, but would like to share a different perspective.

> Sales wins because they can claim "Feature X" being sold and get their commission

That’s true even if the product is high quality from the get-go, isn’t it?

> The customer wins because they get to complain about x or y being bad, incomplete, or whatever they want to whinge about and feel like they're part of the solution

I‘ve seen contractors, big and small, fired for providing complain-worthy software, multiple times. Some (most?) customers have enough on their plate and just want working software. Take Apple as an example. Their software quality seems to have worsened considerably in the last decade, but I don’t feel this has made myself more inclined towards buying their products. Infact, I‘m frustrated and have considered switching to other tech more than once.

> Customer Support/Sales Engineering/etc wins because they get to appear to be "responsive" to the customer by quickly reorganizing ongoing work to take care of the "urgent need"

I agree, support staff actually needs bugs to occur or else they will be scaled down. What’s the business case for having a huge support team though, if shipping high quality software is an option?

> The Project Manager wins (2x!) because they can now a) do the same "response" dance for the C-levels, and b) berate the software development staff and show their authority and working under pressure skills

Why not, instead of working on authority and under-pressure skills, let PMs grow as leaders insider their team who can inspire hard work when the rubber really needs to hit the road?

> Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.

As an engineer I‘ve found it more satisfying to deliver great code instead of having old hacks thrown back at me, maybe with added time pressure because there’s data loss involved.

[sokoloff]

> That’s true even if the product is high quality from the get-go, isn’t it?

I think the point was that claim can be staked at an earlier time if you shovel out some “mostly works for happy path” code than if you wait and ship high-quality code as the initial (but later) delivery.

> when you slam the happy paths out there for the customer as fast as you can…

[jrochkind1]

How depressing. This would seem to suggest that this is not a good industry if you like producing quality work, but is a good industry if you prioritize being able to blame other people for something over getting it right.

[laurent92]

z) Customers are gonna complain anyway and ask for more, so better make 80% of the feature and see what they focus on.

z’) If we deliver 20% of the wrong feature, the customers are going to say it and we can reorient before we make the other 50%. #Agile

I’m not very satisfied either but the history of programming is riddled with us building overengineered solution to the wrong problem.

[michaelcampbell]

My background (and experience) might be different than many here, but I've worked in dev orgs that specifically did the every-6-months big-bang release to a customer, with the BigDesignUpFront, waterfall, and all that. There were some wins here:

* Customers signed off on requirements; they may not have liked them, but they knew what was coming. And when.

* The dev org got to have the (IMO important) psychological journey of discovery, creation, testing, "oh shit", last minute fixing, last second covering up, and the final human release of... releasing. Big celebration. Yay, we did it. My last couple positions have been SAAS stuff where we "release" tiny little things multiple times a week; sometimes multiple times a day. Honestly, it's a grind. There's no "big win". It's akin to "death by 1000 cuts". You don't have the big wins or the big losses, but you get ground down by the never ending stream of small stuff. Writing an app is like putting yet another pat of snow on the snowball.

I get where agile is coming from, but a lot of times it fails to recognize that sometimes, people actually DO want to be surprised with big things, even if they're not 100% positive. And sometimes, customers DO want to have the vendor "Just deal with it and leave me alone - I can't be bothered multiple times a month (or week!) to look at your teeny little new thing. SHOW ME THE FEATURE WHEN IT'S DONE." They WANT that ability to gripe all at once in the end, and not be part of the "steering committee - what am I paying you for if I have to dictate everything?"

I'm being hyperbolic here of course, but I've seen versions of this play out numerous times.

[wereHamster]

Not celebrating is a cultural issue. Even if you ship a thousand new things a week, you can still take time to celebrate those. It's your (or your team's) choice not to.

One good example is Linear. The product improves day by day, but they also publish a regular (weekly) summary of the changes. And for me as a user it's a delight to read through them. https://linear.app/changelog

[gmfawcett]

I don't think a client-facing changelog tells us much at all about how the dev-team celebrates.

Calling it a cultural issue seems off. Perhaps in some cases it is. But if the process truly is a grind, then the only target left to celebrate might be a proxy metric that the devs don't relate to. (Congrats on staying within 0.5 sigma of our mean time to deliver this week, let's have a pizza.)

[maccard]

Celebrating doesn't have to be a reward, and assuming that celebrating a release involves a material reward is certainly cultural. To me, the important part of celebrating a release/milestone is pausing and reflecting on what has changed. That only needs to be a small nod.

[creakingstairs]

> There's no "big win".

Even though you are shipping piece by piece, don't you still have a "big win" that those small pieces make up to be to celebrate? For example, my old team had to deliver MFA. This was broken up and was "released" continuously. We celebrated when the whole feature was "done".