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

71–80 of 258 posts

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

#71

Post by antris »

mcv wrote: post #27

Don't design for future use cases unless they are known in detail (in which case they're not really future use cases anymore). Things you don't know, will change. Your extra effort may actually hurt you in the future. Better is to design for change. Keep everything modular. Keep your concerns separated. When something needs to change, you can just change that thing. When the whole basis of the system needs to change,…

Additionally, even if you know the use cases, often I find it more productive to form the code of the application one use case at a time. This allows greater focus on the task at hand. People cannot effectively multi-task so breaking focus into different use cases at the same time is slower and causes more mistakes than just coding one use case at a time.

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

#72

Post by imtringued »

The stupidest over engineering pattern I've seen is having an interface for every single class in a Java project. This may make sense if you are building an API within a framework or library that people other than you are allowed to implement but when the interface is only used within the project it was created in then it is absolutely meaningless to add the interface before you need it. You can always add a necessary interface later by editing the code. Doing a search for "ClassName" and replacing it by "InterfaceName" isn't exactly difficult.

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

#73

Post by smabie »

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.

Conventional type systems don't really help you when your code is pretty much just taking in vectors/matrices of floats and returning vectors/matrices of floats.

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

#74

Post by antris »

smabie wrote: post #73
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.

Conventional type systems don't really help you when your code is pretty much just taking in vectors/matrices of floats and returning vectors/matrices of floats.

You are correct, however that's a niche use case that would warrant using a non-conventional type system. Conventional type systems are mostly for just dumping a bunch of strings and integers to and from a database and formatting them neatly.

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

#75

Post by yonl »

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 assumption of the refactoring gets changed very fast and the code needs to be rewritten for the majority of the cases.

From a company level I find the instructions are clear, mostly holding the same contract between services as long as possible and less schema change.

Its the engineer with subjective idea of perfect code / supporting future work makes it even more complex

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

#76

Post by hakunin »

I wrote about this a few years ago.[0] The gist to avoiding premature over-architecting is to keep sticking with as static/hardcoded behavior as possible to meet the requirements. Just make sure it’s well organized and cleanly written in your language of choice. Then over time add configurability to that behavior as specs change. Architecture is easy to change not when it correctly predicts future change (almost impossible), but when it is straightforward enough to follow and reshape.

In my experience, keeping behavior static/hardcoded is the architectural equivalent of avoiding premature optimization.

[0]: https://max.engineer/cms-trap

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

#77

Post by smabie »

mrbonner wrote: post #54

My observation is that as I’m getting older as an SDE the number of classes I create in a project goes down! Like a lot of people in this thread point out: almost most of your code has to be changed anyway in a refactor no matter how clever and abstract the design is, what’s the point in over engineering and thinking too far ahead of success? I would rather focus on my data structures and their flows. I know if I scr…

Yeah, the organization of data (and the data itself) is really the only thing that matters. Code itself is cheap and disposable. Just write the minimum number of lines of code required to get the job done, but spend time on the data model. And because you're not anticipating any future use cases, your code is often so short it can just be thrown away in the future.

A larger codebase than solves the same problem as a shorter codebase is almost always worse, has more bugs, and is harder to maintain. Code is the enemy: the only good line of code is the line that doesn't exist.

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

#79

Post by dmoy »

Invest in very good refactoring tools.

Invest in very good testing, especially higher level integration / system testing.

Invest in a good dev/staging setup for your production environment, and also try to make rollouts and rollbacks automated and as painless as possible.

There will always be the need to change stuff, so get the pieces in place to make changes easier code, easier to test, easier to deploy, and easier to back the fuck up when you inevitably cause something to burn.

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

#80

Post by phendrenad2 »

Intelligence signaling. Programmers love to show off to their colleagues how smart they are, so they try to anticipate all possible upgrade paths. "What if the user doesn't have an email address, betcha didn't think of that. That's why you hired me, the tech master, with over 9000 confirmed code commits". This leads to code that is overly generic, but still a big ball of mud. What you want, instead, is for people to be humble and accept that future changes won't be something anyone can anticipate now, and instead adhere to principles that, in general, lead to modular codebases which can respond to changes flexibly.
Post reply on HN