[BlargMcLarg]

That's a binary take if I've ever heard one. The quadruple speed also means products hit the test groups sooner and one can iterate on it faster. Nothing in the story implies the 'star developer' is done once the code hits production, but that's the assumption made. Meanwhile, the 'part of the team that actually cares' may as well be paralyzing themselves through overanalyzing what-ifs without gathering enough information, with the most extreme cases bike-shedding weeks worth of development time.

Surely a group of people who deem themselves 'intelligent' can broaden their perspectives a little?

[kayodelycaon]

When it takes 3-6 months to unfuck someone’s caffeine-fueled, no-sleep weekend bender that got squeezed in under the radar, the value that person is adding to the team and the company is quite questionable.

And no, I am not exaggerating the time needed to fix. The weekend bender, maybe. Average case is started on a weekend and in production two weeks later. The code did not improve over those two weeks.

I’ve dealt with this half a dozen times (maybe more) in my career. Enough that I want to struggle the next “rockstar” that shows up in Slack. They generate problems and support issues faster than a room full of monkeys on typewriters.

I get even more cranky when they decide to use the opportunity to learn Go or Haskell, a programming language no one else on the team knows. And of course they fuck it up because they haven’t used a statically-compiled, strongly-typed (or functional) language before.

I’m generally a careful programmer, but I can definitely write fast and cut corners if necessary. The difference is I know what corners to cut and how to document them.

It might take me 3 weeks instead of 2, but the reduced support cost is far worth the extra week of development.

[BlargMcLarg]

Read my other comment, as your story is a far-too-often-used extreme used by the other extreme party to justify bizarre situations. For every one of those anecdotes is another anecdote of a team of seniors/architects pissing away half the development time only to come with an inadequate solution at the end of it. Guess what, it leads to the same 3-6 months of 'unfucking' with said feature now having to be juggled in prod, where it could have taken half a day of user-testing in a safe environment. When both extremes lead to the same problem, the anecdotes of 'how going fast destroyed my mental sanity' are not an excuse to endlessly bash the other extreme.

The key problem is always the same. The business wants to move as fast as possible, and developers are extremely concentrated in either the overly defensive "let us discuss ad nauseam" camp or the willing/passive "let's develop something and deliver it" camp. I don't agree with either, but frankly, I've had far more trouble convincing the former of their problem (analysis paralysis and wasting time) than the latter of theirs, and the former group is extremely convinced they have the high ground over the latter.

>I’ve dealt with this half a dozen times (maybe more) in my career.

And I've dealt with 'seniors' willingly sitting in meetings not achieving anything and pushing silly refactors more than half a dozen times only to run into performance issues, bugs and terrible deployments. User complaints don't lie, the grass ain't greener on the other side.

[mewpmewp2]

All successful start ups have tech debt. Because the ones without tech debt, didn't make it.

[ranting-moth]

> hit the test groups sooner and one can iterate on it faster.

No, as far as the star dev goes, he's done with the project and has moved onto the next one. He's far to valuable to the company to be fixing bugs. The buggy code is already in production because he promised it was done. The fact that others have to fix the problems implies that the star dev is done.

I wrote about a specific problem, not a generalization that all fast phased development is bad. Also, nothing in my story implies that I'm justifying overanalysing.

I've seen cases that if code is not ready by Monday then the company goes bust. The code is shipped riddled with bugs. Totally justified in that case.

[k__]

"Hitting the test groups sooner" always sounds nice in theory.

But more often than not "people are done after their code hits production".

[BlargMcLarg]

That's not an excuse when the same thing happens the other way around:

"Let's have discussions until 2 weeks before the deadline for something that needs 2 weeks of development time!"

"..wait, why are we having performance issues? Why did we not think of this one case that's occurring every 5 seconds?"

People are very eager to take article's example and use it to slam individuals they have a vendetta against, while looking away from the other extreme which has the exact same problem. Going too fast is a problem. So is going too slow and LARPing as a clairvoyant, getting close to a deadline and then business forces you to get disciplined and deliver something not battle-tested.

[k__]

Guess that's an experience problem.

The more right on the curve you are, the higher the chances that you met people that decided too fast than too slow.

But yeah, your probably right.

[mewpmewp2]

The more experience I have had the more it seems like people won't know ahead of time what has to be done. So if there's a lot of planning involved without getting the thing to customers, there's whole a lot of speculation where 90% of the planning gets completely turned on its head anyway, when finally actual customers are able to use the thing.

And then slow builds and decisions would have to be rewritten anyway. Usually with many assumptions baked in.

So I highly prefer fast iteration where you get at least something out for the customers to use as soon as possible.