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

101–110 of 258 posts

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

#101

Post by hamandcheese »

There’s a lot of folks in here shouting “don’t develop until people ask for it!”

But there is a certain joy that comes when people ask “but what about XYZ” and you can respond “Yup, we thought of that!”

Granted, I work mostly on developer facing tools and services, which makes it much easier to anticipate the needs of my customer since I too am a developer.

And even with that caveat it’s not always a slam dunk... but it certainly is possible to anticipate requirements in a useful way.

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

#102

Post by antris »

1337shadow wrote: post #99
antris wrote: post #67

Earlier quoted context omitted.

I would argue that having a robust type system and some (not too many) end-to-end tests for your software makes unit testing almost completely useless overhead.

This means you test your code manually ? I can't imagine not doing TDD, except during extremely early prototyping before knowing if a code will be useful at all.

TDD and unit tests aren't exactly the same thing. Also, not doing TDD doesn't mean that there's no automated testing. I prefer to write my code and then do a few end-to-end automated tests for the most important parts of the code to serve as a backup in case some change in the code causes massive failures. But TDD is overall tedious for (usually) little benefit when compared to a few well selected end-to-end tests. And unit testing is even less benefit for even more work, unless you are doing something very very specific.

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

#103

Post by watwut »

When you have good refactoring tools, a lot of this is significantly less issue. So, design for easy refactorabilitym lack of repetition and readability.

I dont like "used the simplest solution possible" advice, because people who I claimed doing that in real life tended to do unmaintainable spaghetti mess. It was "simple" in the sense of not having abstractions or nested function calls, but hard to read and understand big picture. Sometimes generic is a way to untangle such previous spaghetti mess. As in, it is second step on the road that requires 2 steps till it is really good.

Understand politics. A lot of those "future cases" are things that analysis or management requires initially or indirectly. They are also often result of trying to hit vague requirements - you dont know what customer really needs in enough detail, so you do it configurable in the hope of hitting the right place too. They are also situations in which people burned out in the past or special cases of special cases.

Otherwise said, the complicated thing is often requirement, initially. Someone had reason to ask for it or thought to have reason. It gets forgotten and ignored after a while in which case it is ok to cut it off.

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

#104

Post by picometer »

Remember that design is about making choices that actually limit the possibilities in design space, rather than extending them.

Building something “generic” to anticipate “future use cases” is not design; it’s the postponement of design.

If you anticipate some unpredictable future feature, then either you do not understand the design space yet, or you are following the directive of a business which does not understand it.

Startups (prior to product/market fit) have a legit reason for not understanding their design space; they’re still exploring it. That makes design pretty hard. Instead of creating The One Generic System To Rule Them All, I’d recommend small, less-generic, low-risk prototypes, that can be easily replaced or refactored. Keep them uncoupled. Meanwhile, use those prototypes to build up your understanding, so that you will be able to make informed design choices at a more mature stage.

I’m speaking in broad strokes; reality may apply.

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

#105

Post by cynusx »

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…

This is actually one of the lessons I had to learn the hard way. Solving for the future makes things unnecessarily complicated and even if that future arrives it will have been code debt and not/poorly maintained because literally nobody cares if it works or not.

Don't do this and solve only for the problems you have now or are about to start in the next 2 sprints.

edit: and make refactoring acceptable and part of your engineering culture so you do it often

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

#106

Post by Cthulhu_ »

antris wrote: post #67
mcv wrote: post #32

Earlier quoted context omitted.

Unit tests are absolutely fantastic during refactoring. I once had to rewrite a piece of code where nobody really knew what it did or what it had to do, and the original author just made some guesses about the intention. I started out by writing unit tests for everything, which became my handhold and documentation for what the system originally did. Then I started reorganising the code into a more structured and more…

I would argue that having a robust type system and some (not too many) end-to-end tests for your software makes unit testing almost completely useless overhead.

The problem is that you want to have tests for your edge cases (e.g. a text field whose contents get stored to the database with specific validation will have a lot of different cases to test for), an end-to-end test will take a LOT longer than a unit test. Unit tests are for rapid feedback on a small section of your application.

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

#107

Post by marcus_holmes »

yonl wrote: post #75
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…

What I have realized over past few years, organising code for future is a function of a characteristic of an engineer. I have noticed people who are extra organized in real life, who keeps every single file in a right directories after download tend to have inclination for prematured code refactoring for future use. If these guys become code architect then i end up doing so many unnecessary things. The fundamental as…

I've seen this tendency in other areas. There are travellers who plan everything, afraid of encountering a situation that they haven't planned for. And there are travellers who trust in their ability to cope with any situation.

As the GP says, this is about fear. Fear that if you don't plan for it now, you won't be able to deal with it if it happens. Or in architecture terms, fear that your system will be faced with a requirement that it can't cover.

Trying to plan for every eventuality is usually wasted effort. Better to build robustly, and trust in your ability to adapt.

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

#108

Post by MaxBarraclough »

1337shadow wrote: post #100
mcv wrote: post #32

Earlier quoted context omitted.

Unit tests are absolutely fantastic during refactoring. I once had to rewrite a piece of code where nobody really knew what it did or what it had to do, and the original author just made some guesses about the intention. I started out by writing unit tests for everything, which became my handhold and documentation for what the system originally did. Then I started reorganising the code into a more structured and more…

"Fantastic" or "The only way" ? has anyone seen a case of refactoring without test end well ? I haven't. Seems like that "refactoring untested code" would be a well established recipe for disaster.

> "Fantastic" or "The only way"?

Not sure if it counts as a 'way', but a static type system helps too.

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

#109

Post by golemiprague »

I think you need to think more about the domain and less about the technology and see patterns that return a lot in the specific domains. Those patterns will be so obvious that you will not even think twice about it. For example almost every crud app for a business will require role based user/permission management at some stage. So you can assume it and implement it straight from the beginning.

Pure technological decisions though depends a lot on usage patterns, tech advances, your personal knowledge and new requirements, so it doesn't matter what you choose in the beginning, assume you will have to rewrite it or at least fine tune it a bit after the app usage patterns are a bit more evident.

Post reply on HN