undefined | Better HN

0 pointsarendtio1y ago0 comments

While I agree with the first two, the third is a problem. Yes, you can always extend your program, but should you? The more code and functionality you include, the harder it becomes to maintain.

Finding the point where your software is so round or complete that you can call it done is somewhat of an art. You can undoubtedly add stuff beyond that point, but I won't improve the software in the long term.

0 comments

kmoser1y ago

The third one isn't meant to imply that you should keep adding needlessly, or that you should necessarily add more functionality (yes, this is how feature creep starts). It's meant to indicate that software is never truly finished: there is always something to fix or improve upon (e.g. refactor).

It's perfectly fine if you make the conscious choice to not make those fixes or improvements, usually for time/budget reasons, but the point is that you should be aware of those possibilities, and that those are the points to revisit if and when you have the resources to do so.

robinsonb51y ago

Quite the opposite - a design (in general, not just software) isn't done until you can't take anything else away from it.

I've coined the term Bonsai Software here before, but I do like the sanding analogy. In the last week I've spent way more leisure time than could be considered sensible writing some user-interface code for the Amiga, in order to make defining the UI in future projects as simple and elegant as possible!

arendtioOP1y ago

While I agree with you on the design term, there is this fundamental conflict: unlike other design forms, software is an additive process. With wood or stone, you can work subtractively until there is nothing left to take away, but with software, you typically start with nothing and add stuff until you have enough.

There is a high chance of overshooting the optimal design, and then you have to reverse direction.

j / k navigate · click thread line to collapse