Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to avoid over-engineering software design for future use cases?

news.ycombinator.com

Post reply on HN
Print view View original

221–230 of 258 posts

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#221

Post by ngneer »

whytheplatypus wrote: post #172
kqr wrote: post #134

Something I've recently realised after having listened to Kevlin Henney talk about software engineering is how much of the existing knowledge we ignore. The early software engineers in the '60s and '70s were discovering pattern after pattern of useful design activities to make software more reliable and modular. Some of this work is really rigorous and well-reasoned. This is knowledge most engineers I've met complete…

Couldn't agree with this more. A current favorite of mine is "The Emperor's old cloths", the Turing award lecture given by C.A.R Hoare. In particular his line "The price of reliability is the pursuit of the utmost simplicity", it applies equally to maintainability and extensibility (I think these are part of what it means for a system to be reliable). An idea I try to keep in mind while working is not to plan or buil…

And security!

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#222

Post by zhoujianfu »

Just another vote that the right answer is do NOT add any code/plans/schema for “future” functionality.

It’s actually not that hard to refactor things when you do need a new feature... and who doesn’t love refactoring? It’s fun!

It’s also easier to refactor when your code is smaller and simpler because it’s only been coded to do the things you actually wanted it to do now.

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#223

Post by N1H1L »

flak48 wrote: post #68
mabbo wrote: post #18

> engineers go extreme in designing things/code for future cases which are not yet known They're afraid. Fear: If I don't plan for all these use cases, they will be impossible! I will look foolish for not anticipating them. So let's give into that fear and over-architect just to be safe. A bit of the 'condom' argument applies: better to have it and not need it than to need it and not have it. But the reality is that…

>> engineers go extreme in designing things/code for future cases which are not yet known >They're afraid. In many companies (think FAANG), engineers, especially senior engineers are incentivized/forced to show fancy design docs as part of the annual appraisal process. The more complicated the design, the more 'foresight', the better. If it sounds kind of ridiculous (TPS reports from Office Space anyone?) it is. But…

Fetishization of objectivity

It's a great concept, and is often what irritates people. I work at a national lab, and senior management is absolutely obsessed with metrics, often to the detriment of the purpose of the organization itself.

There needs to be some humility too - especially in our modern data driven world. All that is important, you may not be able to measure, and all that is measurable may not be important.

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#224

Post by cheez »

chooseaname wrote: post #215

It really depends on what you're doing. If you're writing code for a device that's going to hang out in the forest for 10 years with no updates, write just enough code to solve the problem and make it easy to test. Then test the fsck out of it. If you're writing code for a CRUD web service that you know will get rewritten in 10 months, write just enough code to solve the problem and make it easy to test. Then, test t…

I see what you did here.

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#225

Post by dukoid »

By being aware of the true costs: It's not the cost of making the code more generic (typically relatively cheap) -- but refactoring costs when it turns out that the code actually needs to be more generic, but in a different way. It's easy to refactor something simple into something more complex/generic, but it's hard to refactor something complex into something that's still complex, but in a different way.

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#226

Post by jl2718 »

Always complete each use case from scratch in the simplest and most efficient non-abstract form. Then try to merge use cases into an abstract framework.

Accept the abstractions if: - the stack trace depth is never greater than double - the total code size is decreased - performance/memory hit is less than 10%

Thank you for bringing this up.

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#227

Post by alharith »

owenmarshall wrote: post #182
alharith wrote: post #146

Earlier quoted context omitted.

Unironically, this is one of the simpler setups for a multi-node WP setup I have seen, and I have set up prod WP many times. Anyone with associate level knowledge of AWS can do this. There is a reason there are entire companies (pantheon) dedicated to hosting Wordpress for you: doing it with speed, resiliency and redundancy is hard.

Meta: I've vouched for this comment. You appear to be shadowbanned.

They don't like conservative opinions here, so I am not surprised.

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#228

Post by aantix »

chooseaname wrote: post #215

It really depends on what you're doing. If you're writing code for a device that's going to hang out in the forest for 10 years with no updates, write just enough code to solve the problem and make it easy to test. Then test the fsck out of it. If you're writing code for a CRUD web service that you know will get rewritten in 10 months, write just enough code to solve the problem and make it easy to test. Then, test t…

What are your thoughts on the habit of wrapping virtually every recurring piece of code in its own method? In case the implementation has to be overridden?

E.g.:

def current_time

  Time.now
end

vs. just repeating Time.now inline within all of the calling methods?

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#229

Post by wry_discontent »

chooseaname wrote: post #215

It really depends on what you're doing. If you're writing code for a device that's going to hang out in the forest for 10 years with no updates, write just enough code to solve the problem and make it easy to test. Then test the fsck out of it. If you're writing code for a CRUD web service that you know will get rewritten in 10 months, write just enough code to solve the problem and make it easy to test. Then, test t…

I don't really want to disagree with anything in here, this all looks good.

But I think it's silly to imagine that there's nothing you can do to anticipate changes and make your code more amenable to change.

Re: Ask HN: How to avoid over-engineering software design for future use cases?

#230

Post by sobellian »

dragonwriter wrote: post #210
sobellian wrote: post #206

This tendency has been noted since at least the Manhattan Project, described by none other than Richard Feynman. The prescription for oneself is pretty simple - just say no! It is relatively easy to catch yourself whenever you think about some improvement that's irrelevant to delivering so long as you have convinced yourself that you need to wholeheartedly focus on delivering. It is more difficult to persuade others…

> The prescription for oneself is pretty simple - just say no! It is relatively easy to catch yourself whenever you think about some improvement that's irrelevant to delivering so long as you have convinced yourself that you need to wholeheartedly focus on delivering. That's fairly true if you intend a monomaniacal focus on delivery and you are dealing with improvements that are truly irrelevant. If other concerns li…

Two points here. First, I think the primary trap is that developers think they can judge what code is hygienic. This is the evil twin of the notion that developers can judge what part of a system is slow without profiling.

Developers regularly hold religious wars on basic matters of code style. While you may profit from 'hygiene' there be dragons - developers often consider as hygienically critical such tasks as refactoring React class components into functional components with hooks. The industry is not full of Edsger Djikstras. In practice the sub-optimal greedy algorithm gets the job done since it encourages a straightforward approach to the problem at hand.

The secondary trap is that developers think they can amortize up-front development costs over a long period of time. Projects get the axe if they do not deliver. The longer you spend writing a feature, the longer you wait to test your hypothesis that it is valuable. In many cases the odds that the feature is valuable run below 50%. You may be laying a solid foundation when all that was asked of you in the first place was a shantytown.

Everyone thinks they are the reasonable person with discerning taste who only refactors code as necessary to optimize total cost. In practice that person is as mythical as a unicorn. It is very difficult to convince developers this is true, but true it remains.

Post reply on HN