←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 1 comments | 17 Nov 24 16:34 UTC | HN request time: 0.214s | source
Show context
zombiwoof ◴[17 Nov 24 19:08 UTC] No.42166201[source]▶
Seems like the definition here of software is always “maintenance” of something as is, like replacing the boards on Theseus

Sometimes software is hard and 10x engineers just need to rewrite the whole thing or replace large systems

To subscribe to some world where we have to do that in “small changes” limits us

We shouldn’t make process to the weakest engineers

replies(6): >>42166367 #>>42166537 #>>42167411 #>>42167508 #>>42167881 #>>42174018 #
1. perrygeo ◴[18 Nov 24 16:32 UTC] No.42174018[source]▶
I don't think it's a matter of making process for the weakest engineers. It's more likely that we're trying to apply one monolithic process to highly variable work.

You hit on something super important that I don't see discussed often enough: Different phases in the software lifecycle require different approaches. Trying to apply "maintenance mode" to a greenfield project (or vice-versa) can be a disaster for the reason you mentioned - sometimes you just can't break the job into small changes until you have something concrete to change! There is time for principled slow change, and there is a time for rapid prototyping. But most teams use a single process for both.