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

It’s time to embrace slow productivity (2022)

newyorker.com

Post reply on HN
Print view View original

141–150 of 202 posts

Re: It’s time to embrace slow productivity (2022)

#141

Post by benji-york »

hinkley wrote: post #88
Chris_Newton wrote: post #46

I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…

MVP works when everyone on the team is seasoned. All of the members of the Agile Manifesto were seasoned. As were many of the people they tended to work with. For the rest of us “slow is smooth” means you should work on something that is analogous to the most important functionality first, to build your ability to do that work. Then as you gain skill, tackle harder and harder problems. Sometimes the rule of three let…

Might I suggest that instead of working on "the most important functionality first" you consider identifying the riskiest aspects of the project and working on those first?

Some times those are the same, but often the part of a project that sinks it isn't the core functionality but some prerequisite that turns out to be much harder than anticipated.

Re: It’s time to embrace slow productivity (2022)

#142

Post by gerbilly »

I myself never liked agile or this idea of "iterating" towards a better solution.

Every time I've designed a software system that ended staying in production for years, it was a system that I'd thought about a lot up front before implementing it.

I think we could benefit a _lot_ from doing a bit more design up front. Nowadays it's almost as if people think it's impossible to get it right the first try.

It's not. Professionals can do it if you let them.

Re: It’s time to embrace slow productivity (2022)

#143

Post by Chris_Newton »

kqr wrote: post #118
Chris_Newton wrote: post #77

Earlier quoted context omitted.

Isn't changing requirements one of the key principles of the Agile manifesto? If so, why do we want to dive so much into requirements that are likely to change anyways? Who says all the requirements are likely to change anyway? That’s a whopping great hypothetical on which the entire premise rests, but YAGNI applies to development processes as much as to code! Yes, requirements often evolve and we often start with so…

The tricky bit, in my experience, is that when you straight up ask the customer for requirements you get a list full of details around specific functionality -- basically all the stuff that's going to change in a month. It takes skill and effort to abstract from these detailed wishlists into generalised primitives which remain somewhat constant. This work is similar to the fuzzy logic social scientists work with, and…

It takes skill and effort to abstract from these detailed wishlists into generalised primitives which remain somewhat constant.

100% agreed. It’s well worth doing it if you have the chance, though. Understanding how your customer sees their world and what problems they’re really trying to solve is valuable both for building a useful product and for keeping that customer happy!

Re: It’s time to embrace slow productivity (2022)

#144

Post by datavirtue »

Chris_Newton wrote: post #46

I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…

The typical waterfall assumptions are very overblown. We are doing ourselves a great disservice by throwing it away. Hardly anyone developing today has ever used waterfall much less agile.

The waterfall:bad, agile:good trope is really tiring. Like listening to a teenager that knows jack shit explain how the world works.

Re: It’s time to embrace slow productivity (2022)

#145

Post by datavirtue »

talideon wrote: post #130
fzeindl wrote: post #82

Earlier quoted context omitted.

> ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Usually the individuals doing the work do understand that, but it is really hard to properly divide work and describe requirements. Why people try do divide it in even smaller tasks which increases this kind of complicated creative-writing work is beyond me. > We realised that w…

People keep saying Royce invented Waterfall, but he didn't. At most, he used it as a straw man. What Royce actually advocated was an iterative model. You're right that his approach recommended at least two iterations, but not that his approach was the Waterfall model.

Waterfall also uses an iterative model. Inescapable when building software. The myth needs to die so we can progress. Waterfall, as a typical corporate tech fad, WILL emerge eventually.

Re: It’s time to embrace slow productivity (2022)

#146

Post by Chris_Newton »

com2kid wrote: post #93
m3kw9 wrote: post #57

Earlier quoted context omitted.

Sometimes software engineers forget coding should be the final step, and not the main step. Defining as much as you can,80/20 before starting will save you time. Certainly there are cases where you have an idea and you dive right in and it will work out but usually that won’t work out well from my experience

On the flip side, a lot of exploratory coding is often necessary to learn exactly what needs to be done. "Oh this API sometimes returns garbled garbage results, guess we need to write a sanitizer for its output" isn't something that is going to be known until at least some code is written.

Definitely, exploratory coding can be very useful. It’s essentially writing code to help identify the requirements or design instead of to help implement them. As long as management understands that you might be writing different code for each case and you can’t necessarily turn one into the other…

Re: It’s time to embrace slow productivity (2022)

#147

Post by uoaei »

namaria wrote: post #104
fzeindl wrote: post #82

Earlier quoted context omitted.

> ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Usually the individuals doing the work do understand that, but it is really hard to properly divide work and describe requirements. Why people try do divide it in even smaller tasks which increases this kind of complicated creative-writing work is beyond me. > We realised that w…

>What we should have realized by now is that we never did waterfall right because it's inventor Winston Royce required it to be done TWICE for each project. Two iterations. Reading the original waterfall paper was eye opening for me. I saw that we're falling into patterns that are decades old. Someone insightful tries to explain that learning and building are two sides of the same coin, and companies read it as "ok,…

A somewhat related tangent is the idea that "writing is rewriting". Hardly, if ever, is a first draft suitable for publication, not just because it's rough-hewn or unrefined but also because requirements for some chapters change once others are written. The feedback loops between dependent parts of a written piece are dynamic, not static.

(Yet another reason why LLMs are so limited: they take their earlier writing as sacred and unchanging as a direct consequence of their autoregressive structure.)

Re: It’s time to embrace slow productivity (2022)

#148

Post by adestefan »

gffrd wrote: post #3

This glosses over the fact that jobs are a central piece—if not _the_ central piece—of many people's identities in the States. We've lost religion and communities as things that define and provide structure and purpose, leaving us clinging to jobs. Is this good? No! It's terrible! We should fix this! However, I'm not convinced that workplace stress is a matter of hours … it may be a symptom of lack of life beyond wor…

28 years ago was the original Bowling Alone article. That was expanded into the book by the sane title rehearsed in 2000.

It’s probably time to give it a read again.

Re: It’s time to embrace slow productivity (2022)

#150

Post by knodi »

Mizoguchi wrote: post #60
Chris_Newton wrote: post #46

I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…

Isn't changing requirements one of the key principles of the Agile manifesto? If so, why do we want to dive so much into requirements that are likely to change anyways? Not saying we should jump into design without understanding the requirements, but sometimes requirements are incomplete or not clearly defined and we cannot sit and wait until a new revision is out or someone becomes available to answer our questions.…

The changing requirements part is mystifying part of Agile. How do you build the a proper foundation without knowing the base requirements it needs to support day one and plan for day 30/60/90/365 days needs. Its almost like its written by the PO/PM without really understanding anything else but their slice of work and how they can make it easier for them.

Money and time (for us humans) are finite, big things at lease have to be targeted precise efforts, a good plan and architecture that maps back and supports the requirements.

Post reply on HN