Is the JEE really important

Tech blog

Please find the english version on medium.com

A positive response to 'JEE': an anti-overengineering checklist

Wikipedia defines over-engineering as

the design of a product to be more robust or complicated than necessary for its application.

Over-engineering violates two proven principles: KISS and YAGNI. The authors of the Agile Manifesto also have a clear stance on this:

Simplicity - the art of maximizing the amount of work not done - is essential.

Over-engineering can have many causes, and most of the time it is the result of good intentions: As software engineers, we want systems correct to build. We want our code to be generic, extensible and scalable, robust and well documented. We want to use all of the pretty patterns we learned from reading Gang of Four. But are these qualities and characteristics really prerequisites for good code?

No.

Good code is code that works and that you can work with. It is readable, tested and expandable. In other words, good code is maintainable code.

Tunnel vision in your own microcosm

Let's be honest: you quickly develop a kind of tunnel vision in your own microcosm. And in doing so, you lose sight of the real question: Do you really need this piece of code? Or maybe it solves a problem that doesn't even exist? Is there a compromise?

Sometimes we think we know better than the user of our application. An instance of this hubris happened to us in a brainstorming session about a new feature in the software we are building. During the discussion we developed the idea of ‚Äč‚Äčautomating a process. It would relieve the user of work - for just ten developer days.

The answer from our customer was not only interesting, it was an eye opener: "We will use this function approximately once a year. Automation does not pay off." Was our idea interesting from a technical point of view? Yes! Was our idea worth our customer's money? Definitely not!

The takeway: Don't write code that solves a problem that doesn't exist.

The following list is the result of a cross-project discussion on this topic - without claiming to be exhaustive. Perhaps it will help you further when you are faced with a design decision.

Considerations for a Design Decision

  • YAGNI: Do we really need it? Do we need it now? The perspective of the specialist department is particularly important: Code and features only pay off if they are actually used. And: unused code also causes maintenance costs.
  • KISS: Is the complexity of the solution appropriate? Is there an easier solution?
  • Can the benefits be explained to someone who does not have a developer background? Behind this is the question: Who needs it? And what for?
  • Are the non-functional requirements defined? Or are we possibly dealing with a case of "hasty optimization"? According to Donald Knuth, premature optimization is the root of almost every evil in software development.
  • Does the architecture decision have to be made now? Is it the "last responsible moment"?
  • Does the time and effort of a solution correspond to what the customer needs? Could I represent the solution in front of the customer? Would the customer pay for it if I asked them explicitly? Or in short: is the solution worth the money?
  • Refactorings: Could the code be improved in smaller steps? Baby steps should be taken instead of big bang refactorings.
  • Not-invented-here syndrome: Does a product already exist that will solve my problem?
  • "Shiny new framework": Sure, it's sexy and new and hip. But is it mature enough for use in a business environment? Is the new addiction worth it? Or does it cost more work to integrate than it saves?

So much for the checklist from our project: What will help you to avoid over-engineering?

Tweet Share Share on LinkedIn