Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principles for product velocity

ssoready.com

Post reply on HN
Print view View original

91–100 of 138 posts

Re: Principles for product velocity

#91

Post by therealmulder »

alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

I didn't take the article as a "lack of organization" is best. I took the overall theme as that most methodologies are a distraction to what is most important, building things.

Re: Principles for product velocity

#92

Post by K0balt »

alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

The fundamental issue, I think, is that there is a strong tendency for management to value process (measurable) over progress (often seems like nothing for weeks or months and then bam out of “nowhere” revolutionary new features.

Agile, scrum, etc al are supposed to be guidelines for engineering teams to maintain coherence on progress, but they describe a process, so inevitably management either interjects in the process, tries to use it as a handle to control the process, or pulls engineers out of the project to “manage” the process… all at the expense of progress.

Management can’t see progress, but they can see process. So naturally, they become focused on what they can see, and conflate the process for progress.

Re: Principles for product velocity

#93

Post by zug_zug »

Animats wrote: post #7

These guys do security software. You don't find out if security software is badly broken until you're attacked.

That's a good point. I imagine this advice would be actively bad advice for building more complicated things (e.g. an IDE, perhaps a game, a turbotax alternative).

Part of the skill of engineering is knowing when you need to do upfront engineering and when you can just throw some code at the wall.

Re: Principles for product velocity

#94

Post by zimzam »

the_af wrote: post #52
jdsalaro wrote: post #25

Earlier quoted context omitted.

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place. At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand. Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to appl…

> At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand. I think most commenters on HN understand this. But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades t…

Capital-A Agile is for companies that want the benefits of agile (higher velocity) but don’t want to trust their employees or make any meaningful changes in how the management team operates (micromanagement, committing to rigid feature scopes on rigid schedules).

Obviously this doesn’t increase work but companies get to say they are “agile” and the management team gets to keep doing all the counterproductive management they were doing before. No hard conversations about changing how management operates or unpredictable things like giving engineers autonomy.

Re: Principles for product velocity

#95

Post by baq »

robertlagrant wrote: post #60
baq wrote: post #28

Earlier quoted context omitted.

management is very creative, they just sometimes don't realize that agile is not a management process, it's an engineering process. it's an easy mistake to make because they want to measure engineering output somehow and introduce measurements which cause decoherence of the engineering process state if I may use a quantum analogy instead of a car one. IOW they're trying to do their jobs (manage employees) but enginee…

> agile is not a management process, it's an engineering process That's interesting - I've always thought of it slightly more broadly as a team-running process. You don't have to be doing engineering to do it; you might be building a website in Wix. You just need to iterate and inspect. What do you think?

yeah I completely agree, well put; I also like the sibling's 'process of making/doing things'.

Re: Principles for product velocity

#96

Post by calderwoodra »

alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

If your team has high alignment on what needs to be done and how to do it, then yeah, no processes are needed.

But if you ever want to hire more than a handful of engineers, you need to processes to train them up and build alignment.

Re: Principles for product velocity

#97

Post by luismedel »

Everybody uses methodology and processes, being it explicit or implicit, cool or not, written or tribal-transmited.

We tend to go to the other side of the pendulum when something disgusts us but there's no single company without it's own methodology. Even the most "we're code punks" expect their team to work in some specific way.

"Extremes are bullshit". And some articles nonsense.

Re: Principles for product velocity

#98

Post by mooreds »

alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

I think there's some truth that process slows down development. (Full disclosure, I work for a company in the same space as these folks.)

I love a provocative essay as much as the next person.

But the authors are in a relatively new, smaller company focusing on devtools[0]. This has a couple of ramifications related to process need:

- they are the customer to a great extent, so they don't need to involve external customers to discover what is needed.

- they are fast followers (an OSS WorkOS competitor[1]), so can rely on product need discovery from other competitors. That's not a bad thing (I've done the same!), but it isn't sustainable forever.

- they have a small team, which means everyone has autonomy and knowledge.

- at the size of 2, they don't have other departments with schedules and deadlines and goals. Process is critical to getting input and coordinating across departments to achieve company goals.

All of these factors mean process is an impediment without any benefit.

Not every company is like this company. Not every dev team is like this dev team. My opinion is that this company in three years won't be like this company is now.

I'd wager that in 3 years, if ssoready is successful, there'll be process. It'll be an impediment but a necessary one, as the attributes they currently have won't be enough to keep delivering.

Happy to bet on that if either Ned or Ulysse is reading :)

0: According to https://www.ycombinator.com/companies/ssoready they were founded in 2023 and have 2 employees.

1: https://news.ycombinator.com/item?id=41111136

Re: Principles for product velocity

#99

Post by sirwhinesalot »

PaulRobinson wrote: post #82

> Given a standard of quality, what can we ship in 60 days? Others have said it, this is a methodology, and quite an aggressive one that causes a lot of questions to be asked, and if you don't, you'll end up in a mess. It requires planning, discussion, size estimation, design, maybe even prioritization (if you have two things that each take 45 days, one needs cutting and a 15 day one needs picking up, or you need to…

But most software out there is built with heavy processes? SAFe and all that nonsense, and everyone agrees the output is complete garbage. The software that is lauded and praised tends to be made by small teams of highly skilled engineers, stuff like EmberGen.

To me what this says is that software is not, at all, like other engineering disciplines. Software developers aren't like masons, we're not just mixing cement, there's more to it than that. You can add more masons to a construction work and it will most likely go faster. Add more devs to a project and most likely it'll go slower.

Post reply on HN