[ldjkfkdsjnv]

I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a professional. Technical debt more commonly comes from under abstraction rather than too much complexity/abstraction.

[pdonis]

> Just design the software upfront for what you will need

That assumes that you know upfront what you will need and what software design will best meet the need. Sometimes that is the case, but many times it isn't. Different strategies are needed to deal with the latter case.

[jayd16]

If you need flexibility for unknowns, design for that. Specialize as the requirements become more clear.

[pdonis]

That assumes that you know the unknowns and how to design for the flexibility you will need. That won't always be the case. Sometimes you just have to accept the fact that you don't know enough up front to make a good design, so your initial efforts need to be focused at gaining the information you need, for example by prototyping to get user feedback knowing that you will probably throw some prototypes away, not making design decisions up front that you don't have the information to make.

[jayd16]

We agree. I just phrased it as design and plan for project flexibility, not design a bunch of knobs strictly for every case you happen to know about at some snapshot in time.

I say design and not just plan because you'll want to mock out or prototype something to show and that does take design work to keep your iteration cadence high.

In my mind flexible means easy to iterate on but maybe that is not clear.

[Too]

You have the terms essential vs accidental complexity for that.

Accidental complexity is something you should work hard to avoid. Trying to avoid essential complexity however is a fools errand and if you try, it will result in a deck of cards that only work under perfect conditions.

[Zanfa]

> Just design the software upfront for what you will need, like a professional.

This is impossible for anything more complex than the simplest of toy examples. Never have I seen a production system where all behaviors and use cases are known, well-defined and correctly documented ahead of (or even after the) implementation in enough detail. That’s just not how people operate.

It’s the equivalent of saying everybody should just come together and talk it out to achieve world peace.

[imachine1980_]

i work in legacy code over abstraction gives more headaches than having to check manually when you need to change the software and the person who write it isn't in the company in the last five years, because the software is full of constrains that you don't known, and when you need to change something basic the whole software collapse(because of the interdependence of the componentes).

[ldjkfkdsjnv]

Right but thats just bad programming. If they had used no abstraction it would also be a nightmare.

[teaearlgraycold]

Rememeber: Having no abstraction is better than the wrong abstraction.

[jahewson]

> Just design the software upfront

We call that waterfall :)

[ldjkfkdsjnv]

No its called software engineering

[hmeh]

No, we don’t.

[malfist]

There's a balance to strike, right? Some complexity is just for complexity's sake, or out of inexperience or incompetence. But yeah, a lot of it is that the real world is complicated. That's convoluted code is solving for a bug an engineer was woken up at night for.

And it can be really hard to tell the difference

[ldjkfkdsjnv]

People just get burned by bad programmers. So they make up all these rules to safe guard against them. Its not abstraction thats the problem, its low quality engineers.

[baby]

I think technical debt comes from not cleaning up/refactoring once you’re done. Also, doing this work requires to have a good understanding of the codebase as well as its style/cohesion.

I’m wondering if ML will get good enough to produce PR reviews that comment on style and refactoring opportunities to match the codebase’s spirit.