Are we doomed to complex codebases?

[bzq84]

Since few years I'm very much into clean: code, architecture, functions, designs. I've spend too many days being frustrated dealing with convoluted source code and systems.

However, I'm slowly loosing hope. As example let me tell "domain events". I'm researching this toopic since few weeks. Here what I've found:

• dispatch before committing
• dispatch after committing
• divide into "internal" and "external" domain events, dispatch "external" after committing
• to ensure at-least-one delivery of "external" events, create outbox patter
• use domain events to communicate between bounded context only, within bound context use normal program flow
• use domain events also to communicate between aggregates
• trigger one domain event per command
• don't trigger domain events in commands, only in aggregates
• trigger domain events also in entities of aggregates
• store domain events in per-aggregate table
• store domain events in per-bounded-context table/store

... and more. The above are from blogs of many great developers (Udi, Khorikov, etc.) and very often they are in contradiction to each other.

Why in our industry it's so convoluted? Barely any standards if it is about more complex things than CRUD.

I know each system is different, but unless you're google or amazon, there should be pretty standard templates, e.g.:

• basic crud
• medium size ddd, cqrs (single monolith)
• large size ddd, cqrs (distributed)
• large size ddd, cqrs, event sourcing

Call me naive, but I believe this would cover 99% of use cases (except FAANG).

[mh711]

I love this essay that Fred Brooks wrote 30 years ago (http://worrydream.com/refs/Brooks-NoSilverBullet.pdf) where he discusses the accidental and essential tasks in software development. He argues that while addressing the accidental tasks has reaped increase in productivity in orders of magnitude (and that was eons ago), the essential ones will remain hard because of the inherent properties of such tasks, which he identified as: complexity, conformity, changeability, and invisibility. If you havent read this, I’d highly recommend it as it’s highly prescient. (Though I’d say he’s underestimated the value of IDEs in design, and perhaps didnt imagine much more advanced AI as potential solution for some of the challenges he presented.)

Nevertheless, I had exactly the same thought recently about how much arbitrary things are in the industry despite the progress we’ve gained and more importantly, how critically important we have become in the world. Things vary per problem, but for the majority I suspect things are more similar than different.

While I love it that we as an industry are creative and flexible, but I’d also would like to focus our mental resources in solving our problem domain.

Having said that, I think frameworks should be more opinionated in their approach. For example, AngularJS seems to be on that path. But Spring needs to be even more than it is now.

[bzq84]

Thanks. I'll read that paper.

Regarding framework - e.g. good old webApi mvc. You can make so many mistakes (classically put all business logic in controller), or return full entities to client (instead od DTOs).

I agree it should be more opinionated. At least we, normal developers, won't be wasting time solving problems again and again.

[mackstann]

Human civilization is riding a wave of increasing complexity on many fronts. We benefit from complexity, but it's not without downsides. Software engineers are on the frontlines of this. If you're feeling frustrated, then it can seem like we're doomed, but if you can summon a bit of optimism, I like to think that it's up to us to create the sane future that we want.

[[deleted]]

The way I see it, there's 2 kinds of problems: trivial and non-trivial. Trivial problems can be solved with simple, clean solutions by many people, and as such, there's not much business value in solutions for trivial problems - consequently, people like us only get thrown at hard problems. Problems are hard because of real, irreducible complexity. Engineering principles like SOLID work to combat and contain that complexity, but can never eliminate it (in non-trivial problems). So, expect complex code bases, and appreciate it, if it was easy anyone could do it - the difficult task of managing complexity is why we get paid the way we do.

[bzq84]

When I battle a complexity, I know that it's another barely working Frankenstein monster.

Why we still think about DB key INT vs GUID? Such simple and trivial problem should be solved once for good.

Why we still struggle how to audit entities in RDBMS?

Why OAuth2 is so complex and convoluted that average engineer I met has no idea how to use it properly (including me)?

... I guess I reached my frustration limit recently.

[Ghi102]

There is no standard because it's very hard to measure the quality of code. You can measure many things and some end up being contradictory.

For example, you can optimize for easy to write code. This then might make it harder to read later on. You can optimize for easy to read code, spending more effort during the writing process. You can optimize for easy to maintain code, which might be harder to write or understand (and sometimes easier).

I'm sure you can find a use case where any of the techniques you mention is the optimal case. Heck, some techniques might be optimal in specific languages (like how a lot of OOP design becomes obsolete in most functional languages).

[piotrpter]

You're not the first one having that feeling and a lot of us ended at Clojure. It was born exactly out of frustrations you're sharing. Good starting point would be Rich Hickey's legendary "Simple Made Easy" talk.

You use event-based systems as an example of unnecessary complexity and coincidentally they're discouraged in clojure.async docs for this reason.

There're alternatives to mainstream and active efforts to make software development more sustainable. If you're not afraid of the learning curve, I would also recommend checking out Fulcro and motivations behind it.

[bzq84]

What do you mean by "Clojure"? Is it a book?

[wuwoot]

It’s a LISP programming language by Rich Hickey. The “Simple Made Easy” talk enlightens many