Hacker News Reader

That's an excellent point. I try to do this always, I think that waiting time and thinking more about problems has huge benefits in the final solution. But... when there is a community waiting for new features sometimes this attitude is seen as losing time, and is very hard to explain, so it is important to keep people aware of the design process. Also because via communication it is possible to receive high quality feedbacks. Btw the "slow code" term is great :-)

> And always based on understanding the domain and the existing software you are building upon

This is good. My version of "slow code" is taking note of requests from users and storing in my long term memory to stew over.

1. User A says "It would be nice to have feature X"

2. I ask for more info, what problem are they trying to solve

3. Repeat steps 1 and 2 until user's stop saying "nice to have" and start saying "must have". The stew is now ready and development can begin now that I have thought about a solution that can address everyone's problems...just in time before users get angry :)

I like this kind of development also. But I don't think it is for everyone (the person has to keep thinking on the problem for long time).

A good talk about It, from the creator of clojure:

https://youtu.be/f84n5oFoZBc

I heard that ruby was developed like that. It had lot of `freeze & thaw cycles` of good years before finally it got released.

I feel very reflected in this "slow code" interpretation. Instinctively, I try to refrain my self to implement this new feature that looks important but not urgent. The positive outcome is not only that you have more time to think about the proper approach but also eventually, some times, the feature shows it self not needed any more.

Thought/discussion usually leads to quality. Time has nothing to do with it.

Of course it does: thought/discussion take time.

It seems people are confused. Of course everything takes physical time, but slowly thinking about something isn't any objective sign of better outcomes.

Everyone works differently, but for me thinking in a leisurely way does produce better outcomes. It's less that my actual thinking is somehow "slower", than that thinking about something and then letting it rest and come back to it, I have better conclusions than if I rushed to judgement.

I guess the phrase 'rush to judgement' is instructive. We're not just thinking, we're deciding of course.

If you can find out about a problem or issue or desire and very quickly come up with an architectural solution that will stand the test of time for years (at least without backwards-incompatibilities, which is what a redis requires), more power to you, but in my experience and observation most will not.

But I get it, you just don't agree with my basic suggestion, from your experience. That's fine. It's not really an argument about the speed of one's thinking. Nobody is "confused".

I think the salient point is that thinking takes more time than not thinking. At least in my experience, the policy is generally to push features, not to think (slowly or otherwise).

> This is how actual quality software that will stand the test of time gets designed and made ..

No not really. It's called waterfall and we had it for decades.

And it was largely abandoned in favour of agile development because despite architects spending months designing something there was always something that was left out. Or the scope changed during those months. Or millions of other things that change whilst your hidden away from your customers/end users instead of delivering them new value every week.

For me personally the truth is somewhere between agile and waterfall. Some upfront design but not the slow code you refer to.

I disagree, I think "waterfall" (at least in stereotype) would be more like coming up with the specifications in advance and then _sticking to them_ regardless of new information from the world or from the experience of developing the software. That's not the story the OP told.

I also agree with the person who responded that there is a difference between building products, and building tools for building products -- building shared libraries/code/tools may require different approaches. One of the things I've noticed about shared code, is it's _much harder_ to fix rethought decisions or change paths. "Backwards incompatibility" doesn't even exist as a thing in your local app really, at least you can always at least theoretically global search and replace when you change APIs.

I don't think we've figured out any magic bullet process for developing software. It's definitely not the stereotype of "waterfall", but I don't think the stereotype of "agile" is it either -- at _least_ when it comes to shared library/tools. And I'm absolutely convinced that those shared tools which do well were almost always designed carefully and intentionally with understanding of the domain, not just slapped together with stimulus-response.

I think you're being downvoted because trying to slap a brand like "waterfall" on the very idea of slow, careful design is kind of ridiculous. Bonus points for throwing "agile" in to the mix as well.

But waterfall or agile implies code is being written. My take on this (and experience) is that sometimes you just takes weeks, months, even years to just make notes in a notebook, ponder and think upon the problem, jot down more notes, look around at other peoples code, do research to see if anyone else has done work in this area, do more pondering and thinking and note taking, talk it over with other people, etc. At some point it all gels together (when that happens it is almost magical and such an amazing moment of clarity) and then you are ready to use some sort of development process to actually write the code. Though by that point writing the code is extremely easy since you have such clear insight into what needs to be written. I love when that happens.

You missed the part where the definition of the problem was being percolated during this process. Agile won't save you from not understanding the problem you are trying to solve.

There is a difference between building products and tools for building products.