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

241–250 of 258 posts

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

#241

Post by qes »

Nursie wrote: post #14

When I was young and fresh, I wanted to cater for all sorts of future possibilities at every turn. But what if things change this way? What if things change that way? I came to realise that when things change, unless the design change is trivial (allow use of database Y as well as Z, etc) then you probably haven't anticipated the way in which it is going to change anyway. Better to have clean, straightforward code th…

> The API upgrade and schema change were happening at the same time

Atomically? What if your DDL times out?

What you describe is, in my experience, extremely standard process for rolling out breaking changes (you do of course remove the switch and old version support after everything is rolled out).

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

#242

Post by AnimalMuppet »

wry_discontent wrote: post #229
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.

The problem is the changes you anticipate often are not the changes that happen. Those anticipated-but-not-happening changes waste your time, and also clutter up your code, getting in the way of the changes that do need to be made.

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

#243

Post by kqr »

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…

> maintainability and extensibility (I think these are part of what it means for a system to be reliable).

Frequently forgotten is the duality of extensibility: subsettability, or contraction. Being able to remove or disable code without rewriting large parts of the application is just as important as being able to extend it!

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

#244

Post by kqr »

rosshemsley wrote: post #143

I think a common conflation is seeing "making something future proof" as "making it more generic". IMO, good future-proof design is about putting in place good components and system boundaries. Those components and boundaries can be highly specialised and have as few options as possible - it's much easier to make a system boundary more complex than to make it simpler. So start as simple as possible! Now, with those b…

David Parnas makes the distinction between general software and flexible software. General software runs without modification in a variety of environments. Flexible software can cheaply be modified to run in a variety of environments.

When you cannot predict the future, flexible is often more efficient than general.

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

#245

Post by kqr »

hackerman123469 wrote: post #186

Break the problem you're trying to solve up into simple steps. Each step should be nothing more than a single task. Ex. if you have a problem to solve that goes like: Must create store with products that are blue only. Then you'd break it up like: Create store Filter products (Blue only) Create products in store Then when you start coding you solve nothing more than what you put down as each task. Ex. you don't do an…

Though this "implement one box of the flowchart at a time" approach can lead to inflexible software due to insufficient modularization.

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

#247

Post by wiseleo »

Make code easy to read and extend without breaking it. By now, many of us are aware of the importance of writing tests. However, there is a problem in making them readable.

Here's one Kevlin Henney's lecture [1] that crystallizes it. It took me a long time to find it, so you are welcome.

Once you start naming things like this, adding future use cases becomes far less risky and thus you don't need to waste time on them.

https://www.youtube.com/watch?v=tWn8RA_DEic

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

#248

Post by Aeolun »

ex_amazon_sde wrote: post #204
Aeolun wrote: post #174

Earlier quoted context omitted.

Well, they haven’t hired me yet, so either I’m terrible, or the hiring bar is just completely arbitrary.

In all large companies the people involved in an interview are a tiny fraction of the whole workforce. Most of the time it's people from the team that is hiring and one or two "guests" from other teams (but usually working in the same building). Managers also have plenty of power to influence the decision, therefore keeping a very uniform hiring bar is really difficult. (But no, it's not "completely arbitrary") Also,…

Sorry, I was just trying to comment on how interviewing itself is an arbitrary crapshoot.

Say one slightly dubious thing and you torpedo your chances of the job. Write one slightly dubious thing on your CV, and it will be rejected without a second look.

While I’m confident that most of the people rejected for those reasons would be at least adequate at their job.

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

#249

Post by whytheplatypus »

kqr wrote: post #243
whytheplatypus wrote: post #172

Earlier quoted context omitted.

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…

> maintainability and extensibility (I think these are part of what it means for a system to be reliable). Frequently forgotten is the duality of extensibility: subsettability, or contraction. Being able to remove or disable code without rewriting large parts of the application is just as important as being able to extend it!

yes!

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

#250

Post by echlebek »

Understand and implement hexagonal architecture. https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa...

If you build systems with these principles in mind, you can create systems that are extensible, without creating technical debt and YAGNIs.

Post reply on HN