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

191–200 of 258 posts

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

#191

Post by tristor »

muzani wrote: post #63
daniel-levin wrote: post #45

32 comments so far and no mention of the word budget. There's a great analogy between software engineering and construction. Does your organization build skyscrapers and gorge-spanning bridges? Or does it build driveways and swimming pools? Commercially developed software consumes capital to get something in return. Are the people spending capital budgeting for a driveway or for a skyscraper? Must it be done this mon…

Very often projects are overbudgeted though. Not just cost and time, but quality of hires, salaries, promises to investors, and a competitor's feature list. The scope of the project then expands to fill the budget.

Promises to investors and a competitor's feature list define your scope, not your budget. Salaries and quality of hires are correlated (but not causal), and are directly tied to cost as a component of it, along with time. Feature cost estimation can be as simplistic as:

Running Costs + (Weekly cost of Engineers * Weeks Slated) + (Hourly Cost of Managers * Hours in Meetings/Discussions) = Projected cost / required budget.

Increasing scope causes an increase in time spent both in meetings arguing about it and engineers working to build it, which increases the time side. Increasing salaries / quality of hires increases the cost side. Promises to investors or contractual obligations to partners/customers are non-negotiable increases in scope, so directly drive how much time something takes.

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

#193

Post by saalweachter »

Nursie wrote: post #48
daniel-levin wrote: post #45

32 comments so far and no mention of the word budget. There's a great analogy between software engineering and construction. Does your organization build skyscrapers and gorge-spanning bridges? Or does it build driveways and swimming pools? Commercially developed software consumes capital to get something in return. Are the people spending capital budgeting for a driveway or for a skyscraper? Must it be done this mon…

> My dopamine levels [0] skyrocket when I visualize making some component generic, or future proof. I think I've successfully rewired that impulse in myself now, at least partially. I do get that feeling from imagining great systems, but I also get that dopamine hit from deleting old stuff and simplifying things as much as possible. We can ditch compatibility for API v8? Awesome, I just made my code smaller and we ca…

Honestly I think this may be a component: besides code shame (my code is bad and I don't want other people to see it) a lot of programmers also feel protective of their code. They want it to last forever, a paean to their skills. Writing simple code to throw away and refactor feels like a failure -- it should be perfect and eternal.

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

#194

Post by collyw »

Aeolun wrote: post #174
ex_amazon_sde wrote: post #151

Earlier quoted context omitted.

I did, across different roles in two well known teams. As I said, there are exceptions, and the hiring bar has been dropping a lot in the recent years.

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

Lets face it hiring is just a shambles in this industry. 20 years in the industry I know how to write a reliable system that is easy to maintain. Getting kind of crap at the tests they give in interviews.

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

#196

Post by zzzeek »

If you ask an ice skater how not to fall, they may likely tell you that they have falling tens of thousands of times and continue to fall all the time. But they will know, they know how not to fall because they are intimately aware of what it feels like to fall and know how to avoid it as a result.

I don't know that there is any readable wisdom that will teach you how not to overengineer or underengineer, such that with that knowledge, you automatically know how to achieve the right balance. It is likely a necessary part of the process to build out software projects that are in fact overengineered or underengineered and to intimately learn from that process as well as the aftermath how to tune one's own process to strike an artful balance between the two extremes.

put another way, the MS and Google teams you worked with were screwing up, but screwing up in a way that is necessary for people to learn, if they do in fact learn (they might not learn).

all of that said, starting out by intentionally underengineering, if you know that you are one to start overbuilding, might be a good strategy. but you might have to do some really huge refactorings subsequent to that when you learn your architecture is insufficient.

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

#197

Post by aszen »

There's a fine balance between over-engineering and under-engineering, right now I'm working on an old piece of software that has been designed without any significant engineering process, while things remain easy to understand and fix, there's a deep sense among us that simple dump code repeating code has brought duplication, inconsistency and bugs that are easy to fix in one place but impossible to fix everywhere. I think most software outside of silicon valley may well be under engineered.

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

#198

Post by psahgal »

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.

Test-driven development is a useful tool, but it doesn't remove the need for manual testing completely, especially on frontend projects.

I've worked on mobile apps before with a small team, and inevitably, we'll find bugs that show up in the user interface when the user rotates their phone. It's hard to unit test for rotation changes, and it's also hard to code a rotation change into an end-to-end test on mobile. Animations are also something that's difficult to test in an automated fashion, and all the testing in the world won't be as good as showing the animation in front of a designer. So some level of manual testing is needed on mobile.

I've worked on web frontends where there would be bugs with scrolling jumping back and forth. An end-to-end test using Selenium may not catch the issue, but for a user, it can be painfully obvious. Similarly, animations are also hard to unit test on the web. So some level of manual testing is needed on the web.

The only place where I could see manual testing NOT being needed is for backend development, since the input and output to a backend system is much more controlled. You could write an end-to-end test for any scenario a user could throw at your system.

In summary, don't underestimate the value of manual QA!

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

#199

Post by spaetzleesser »

gwbas1c wrote: post #177

1: Simple code is easier to refactor than complicated code. Try to keep your design as simple as possible. 2: It's easier to refactor code with good automated tests, like unit tests, because you can push a button and know that it works. 3: Make sure that your startup order is well-defined. It's easier to debug a well-defined startup order than a startup order where everything is implicit. 4: Know the difference betwe…

"2: It's easier to refactor code with good automated tests, like unit tests, because you can push a button and know that it works. "

One thing too keep in mind is that the tests should also be kept relatively simple. I have seen codebases where there were so many and often complex tests that modifying the actual code was easy but changing the test would have been prohibitively expensive.

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

#200

Post by logicslave »

jjav wrote: post #60

The junior developer sees a pattern and thinks why not make this a bit more generic so it handles similar cases. Oh but these cases fit a larger pattern.. and eventually you'll have written yourself an entire framework. This is very valuable, for the experience. Not for the framework, which will never be used. But you should go through it. The mid-career developer knows this from experience and sticks to the minimum…

Most people never make it to your definition of senior engineer
Post reply on HN