7 ms·
I think you are not reasoning correctly here Adding features to a code means it was incomplete. Misunderstanding input/output usually means it is poorly docume
by petermcneeley 2y ago
I think you are not reasoning correctly here
Adding features to a code means it was incomplete. Misunderstanding input/output usually means it is poorly documented or lacked a good API. A good API works at the surface (in/out) and not in the volume.
Really good code solves a problem completely. I have worked with such code and yes almost nobody ever goes into this code (and makes changes).
- x0x0 2y ago> Adding features to a code means it was incomplete. That definitely implies code can't be good if needs change, which makes no sense to me.
- CuriousCosmic 2y agoAdding features means it was incomplete. Good code can essentially always be built upon instead of modified.
- exe34 2y agois "building upon" different from "adding features", in this new terminology?
- phito 2y ago[dead]
- x0x0 2y agoBut code can be complete and then become so-called incomplete because, again, needs change. eg someone releases a new file format. You believe ffmpeg is bad code?
- mewpmewp2 2y agoIn that case you could argue that you would be just writing new code to write a handle for that file format. In ffmpeg case I assume this is how it would be.
- oblio 2y agoLaws change, business requirements change, network protocols/external APIs change, ... Your approach is I guess valid for self contained algorithmic code, i.e. 0.000001% of code out there.
- tanseydavid 2y agoMissing feature implies an error at the Requirements level. This does not impact readability or the idea of "good code" in my opinion. You could have an application that is missing features which still contains examples of "good code". Learning about "good code" by reading the source code of this application won't really give any direct hints of missing features...the granularity is different.
- philosopher1234 2y agoWhy does it imply an error? The world changes, is that an error? You built around one reality, and reality changed. No one can predict the future.
- mewpmewp2 2y agoWhat about changing features? E.g. a feature has to change 2 years down the line because certain laws are passed and this changes how the business logic should behave.
- wavemode 2y ago> Adding features to a code means it was incomplete In practice this isn't true. The code may have been perfect and complete according to the business requirements of 1 month ago. But the business requirements of 1 month ago and today are often completely different.
- petermcneeley 2y agoThis falls outside of my experience. I am systems or "backend".
- xboxnolifes 2y agoI'm not familiar with many systems or backend software that are still actively used, multiple decades old, and not still receiving updates. If it's not even a decade old, it's not old enough to say requirements won't change.
- phito 2y agoHow does being a backend engineer makes you safe from business requirements changes? It doesn't add up to me.
- aaronbrethorst 2y agoLet me guess, you work on game engines?
- petermcneeley 2y agoI have but I dont currently. I am guessing the implication is that game engines have good code while other subsectors do not.
- frapaconi 2y ago[flagged]
- petermcneeley 2y agohttps://biblehub.com/mark/10-18.htm https://biblehub.com/mark/10-18.htm
- cjblomqvist 2y agoI thought you extended, not edit, really good code to achieve that
- nsinreal 2y agoWell, what's wrong with code being incomplete at some point of time? Is it not waterfall enough? Is it too much learning from customers? Is it too small PRs of duration less than 1-6 months? Is it not enough premature optimization?