Apropos, the author is currently looking for work: http://tef.computer/
Write code that is easy to delete, not easy to extend (2016)
81–90 of 113 posts
Re: Write code that is easy to delete, not easy to extend (2016)
#82I wholeheartedly agree with "don't immediately jump on the modularize and abstract everything right away". I think that "modularization and abstraction is always and uniformly good" is one of the big lies of our profession. It’s easy to see how it’s attractive : programming is intellectual work, and displaying capacity of abstraction is rewarding. I was extremely enthusiastic about that stuff when I was young, too. T…
This isn't a modularization thing; it's a JS/TS thing.
The real lesson is to never work in webdev.
Re: Write code that is easy to delete, not easy to extend (2016)
#83Earlier quoted context omitted.
That sounds like myriads of programmers have done it wrong for decades. Can you elaborate on this and maybe add a few sources?
The ultimate source is David Parnas' 1970s' articles On the Criteria to be Used in Decomposing Systems Into Modules , and Designing for Ease of Extension and Contraction by the same author. The 1960s' NATO conferences on software engineering also touch on this. These articles essentially introduced modularization, and they argue very well for why their approach is superior to the misunderstanding we frequently see to…
Thanks a lot for response and sources. Will look at them now.
Re: Write code that is easy to delete, not easy to extend (2016)
#84Fun read, but does anyone actually change their coding practices based on high-level essays like this? HN seems to be filled with a highly opinionated bunch, and I question the point of these musings.
Re: Write code that is easy to delete, not easy to extend (2016)
#85Fun read, but does anyone actually change their coding practices based on high-level essays like this? HN seems to be filled with a highly opinionated bunch, and I question the point of these musings.
I'll admit I haven't necessarily changed my coding practices directly based on posts like this, but they do help me formalize the things I've learned in my own experience.
Re: Write code that is easy to delete, not easy to extend (2016)
#86Earlier quoted context omitted.
That sounds like myriads of programmers have done it wrong for decades. Can you elaborate on this and maybe add a few sources?
If you have to change in 5 places to change one "thing", the code is probably not DRY.
DRY is not very useful as a concept. It doesn't define any rules how to identify bad repeated code, nor how to change it and doesn't define limitations of the concept or it's application.
I know this sounds wild and harsh but we have to overcome the habit of explaining non trivial or even unsolved problems with truisms.
Re: Write code that is easy to delete, not easy to extend (2016)
#87Earlier quoted context omitted.
I like your comment, but for the wrong reason: Explaining what a method DOES, goes against encapsulation principles. It creates coupling to implementation details, when what should be provided is just the interface. Any explanation can be exposed in business domain logic and documentation.
There are multiple pieces of documentation. Documenting what a method does is one of them, but primarily intended for maintainers of the system. Documenting its interface is meant for its users. Both have great value, but at different times and to different people.
Indeed, was thinking the same thing while posting.
In practice though, I've mostly encountered lack of comprehensive developer docs, or they became outdated years ago. Most devs will point to source itself for documentation, unless for critical or certified software. If not the latter, the internal logic is usually scattered and not cohesive. So need to check dozens of files for each hypothesis about the original intentions and context.
Re: Write code that is easy to delete, not easy to extend (2016)
#88Earlier quoted context omitted.
More like a variant of the Peter principle: all code tends to be refactored to its level of unrefactorability.
Having just completed a change that should have been small, but ended up spanning ~75 files, I can attest to this. It would have been small, up until the point where one of the excitable members of the team discovered Uncle Bob and got excited. Which, disclaimer, I generally like what Uncle Bob has to say. But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to impleme…
> But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to implement the cosmetic parts of the programming style he advocates while simultaneously achieving the diametric opposite of the fundamental goals that these techniques are supposed to achieve.
All of OOP is like this. The most enthusiastic OOP adherents create the biggest OOP messes. Maybe every style of programming suffers from this problem eventually? The style has a go-to form of abstraction and a characteristic kind of mess that results from overapplying that form of abstraction. Once people get comfortable dealing with that kind of mess, they realize, if I program zealously and dogmatically in this style, this is the only kind of mess I will ever have to deal with, and the comfort of always dealing with a familiar kind of mess they know they can slog through outweighs every other consideration.
Re: Write code that is easy to delete, not easy to extend (2016)
#89The unfortunate side effect of this (very good) advice is that all code that's easy to delete will eventually be replaced with code that's hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).
Actually, beside the facetious aspect of this, there is a subconscious value into having code-mass. Heavy means stable at times.
Funnily enough I usually experience the opposite. I've worked with very heavy systems and very light systems, and I always find more stability with the really light weight stuff. Obviously there are more bugs at first, but once you go through your first wave of code fixes I'm usually sitting pretty for awhile until I change more stuff.
Re: Write code that is easy to delete, not easy to extend (2016)
#90Earlier quoted context omitted.
Having just completed a change that should have been small, but ended up spanning ~75 files, I can attest to this. It would have been small, up until the point where one of the excitable members of the team discovered Uncle Bob and got excited. Which, disclaimer, I generally like what Uncle Bob has to say. But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to impleme…
> But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to implement the cosmetic parts of the programming style he advocates while simultaneously achieving the diametric opposite of the fundamental goals that these techniques are supposed to achieve. All of OOP is like this. The most enthusiastic OOP adherents create the biggest OOP messes. Maybe every style of program…
I once encountered a take on this that rang quite true to me, though I can't for the life of me find where I read it.
The observation was that good object-oriented design is inherently unstable. With even slight perturbations, they can quickly spiral away into a mess. And those perturbations tend to happen almost constantly in real life, because writing SOLID code requires vastly more skill, knowledge and effort than not writing SOLID code. So keeping the code clean requires a constant, almost aggressive effort by some (probably self-) designated caretaker who understands and can defend the design. The social factors there are terrible, though, because now you've got a person on the team whose very job is more-or-less to nitpick and have arguments with the rest of the team. Frankly, it might be better to let the code be messy than it is to risk creating that kind of work environment.