My favorite principle for code quality • Hacker News Board

Re: My favorite principle for code quality

#31

Post by tabtab » Tue, May 22, 2018, 8:45 PM UTC

vorpalhex wrote: post #16

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

I have to agree. There are OTHER errors that can be introduced by having too many wrapper classes/methods. Clutter (code volume) also adds to causes of mistakes.

I don't know what particular mistakes could come about in this case, but more code == more errors in general. Wrapping stuff into mini abstractions is not always an improvement.

As a rule of thumb, if some code pattern repeats 5 or more times, an abstraction wrapper is probably justified. Between 2 and 4 is a situational judgement, but lean toward skipping the wrapper. KISS.

Re: My favorite principle for code quality

#32

Post by pfarrell » Tue, May 22, 2018, 8:45 PM UTC

vorpalhex wrote: post #16

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

Thought the exact same thing. Abstract early is not good in practice. You can't understand what problem you are solving until, as the last architect I worked with would say, n is 3. When you have three consumers of a feature, then you start to have an understanding of what the needs are.

To put it in another anecdote. I dealt with a SOAP api for a successful company that was purposefully designed to have no versioning. This meant that every decision that went into the API had to live forever and be backwards compatible with every decision that had ever come before.

This leads to the form of architecture I find to be the least useful. One where the architect tries to anticipate and solve all future problems. In my experience, this never leads to software that can grow or evolve. It's fine if you are solving a known problem and can set known boundaries around which your solution will never be applied. I, personally, have never encountered problems like that in the field.

Re: My favorite principle for code quality

#33

Post by [deleted] » Tue, May 22, 2018, 8:51 PM UTC

[deleted]

Re: My favorite principle for code quality

#34

Post by dnc » Tue, May 22, 2018, 8:52 PM UTC

vorpalhex wrote: post #16

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

Thank you for saying it, cannot agree more. Premature derivation of abstractions so often leads to code that is later difficult to modify and understand and leads to a vicious circle of adding more abstraction and complexity.

Re: My favorite principle for code quality

#35

Post by antirez » Tue, May 22, 2018, 8:56 PM UTC

I can't disagree more with this post. One should always aim at trivial code, but as things get more complex, it is there the the sensibility should fire in and make you say, ok I need more abstraction now, and refactor accordingly. But even then it is important to just add the minimum amount of abstraction to generalize the problem at hand, without thinking like "but why if in the future we change things..." Unless it's very clearly going to happen soon.

Re: My favorite principle for code quality

#36

Post by some_account » Tue, May 22, 2018, 8:58 PM UTC

vorpalhex wrote: post #16

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

I agree. Developers should never build anything more complicated than it has to be at the moment.

Simplicity is key to happiness and productivity.

Re: My favorite principle for code quality

#37

Post by trias » Tue, May 22, 2018, 9:02 PM UTC

jpochtar wrote: post #23

I believe the code presented would have benefited from a lambda-based API approach instead of an object-oriented one. In Javascript: // global, since the cached values were apparently global in the original let cache = {}; let lastCachedTime = 0; // Utility for fetching potentially cached values, or computing them // if there's no valid cache entry. let cached = (id, recompute) => { // I don't love this policy, but t…

I agree. Using the class approach usually leads to complex class hierarchies and a lot of made up concepts for simple things which would be better solved if you could pass functions around easily (lambdas) and had generic data types (like javascript objects). But java does not have these easily available.

I think the OPs problems are mainly coming from the culture/design of Java.

Re: My favorite principle for code quality

#38

Post by Jach » Tue, May 22, 2018, 9:02 PM UTC

vorpalhex wrote: post #16

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

Fully agree, let's not go back to instinctively applying all of the patterns from GoF. I'd also like to quibble with just this:

> When reading software design advice, always imagine the examples given are 10x longer.

How about: if you're peddling software design advice, take some time to make (or find) a realistic example so I don't have to imagine so hard. Even if it's in a toy-problem type of scenario the code can be realistic. Working Effectively With Legacy Code has spoiled me by setting such a higher standard than most peddlers, since it actually presents real code (sometimes 3 pages of it at once) in real languages (Java and C++) using styles and highlighting problems I actually see in legacy codebases with those languages, and how to address them.

Re: My favorite principle for code quality

#39

Post by sametmax » Tue, May 22, 2018, 9:03 PM UTC

vorpalhex wrote: post #16

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

And the sad thing is, it's the opposite of what they teach you in school.

And only by practice, and making the mistake enough, did I reached the same conclusion as you.

Although there is a balance, as sometime you know your future requirements, and making an abstraction right away may save you some time. It's hard to teach experience and the ability to evaluate something vaguely.

Re: My favorite principle for code quality

#40

Post by Chyzwar » Tue, May 22, 2018, 9:08 PM UTC

pfarrell wrote: post #32

vorpalhex wrote: post #16

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

Thought the exact same thing. Abstract early is not good in practice. You can't understand what problem you are solving until, as the last architect I worked with would say, n is 3. When you have three consumers of a feature, then you start to have an understanding of what the needs are. To put it in another anecdote. I dealt with a SOAP api for a successful company that was purposefully designed to have no versionin…

I agree. Good architecture is something that can naturally emerge. You start with a simple and less abstract solution and gradually evolve when requirements are better understood. Upfront design mostly does not work.