5 Replies - 1537 Views - Last Post: 21 July 2015 - 08:25 PM

#1 macosxnerd101  Icon User is online

  • Games, Graphs, and Auctions
  • member icon




Reputation: 11315
  • View blog
  • Posts: 42,636
  • Joined: 27-December 08

Avoiding the Over-Engineering Trap

Post icon  Posted 07 July 2015 - 01:18 PM

I came across this article on the first indications of over-engineering your application. I'm working on a Java component at work for a larger application. It's a rewrite of a Python component, when we found out the third party library had serious problems. There are times I've found myself skirting around the over-engineering trap. My application parses JSON logs from Kafka and submits the metrics to Datadog. In the long term, Datadog will eventually be slated. So I'm trying to write my code in such a way that it won't cause too much work when Datadog is replaced. In doing so, I find myself trying to balance writing clean and modular code against writing simple and straight-forward code that solves the problem. The Python equivalent was fairly expeditious to write, while the Java counterpart is much bulkier. I feel like if I don't keep focus on the task at hand, it's easy to over-engineer this component in Java.

Do you all have any experience with the inclination to over-engineer? How do you balance this with writing simple, modular, clean, and effective code? Do you have any other thoughts or suggestions on the topic?

Quote

You start to use terms like "potentially", "in future", or "scalable".
You spend more time thinking of "encapsulation", "abstraction", and "decoupling", than the actual problem.
You believe that with the amount of frameworks, libraries, and languages (better polyglot projects), the quality of the software will improve.
You are able to replace every single concept, class and layer—but this feature actually cannot be derived from the client's requirements.
Just looking at the code—you do not understand what happens—you need additional tools, products, and consultants :-) to understand it.
You hate monolithic structures—so everything is configurable, replacable—of course, at runtime. If it becomes too complex, go to point 5.
You start to implement a generator to tackle the complexity.
Your configuration file is getting slightly bigger than your code.
Your interface is so fluent that only domain experts understand the code. :-)


Is This A Good Question/Topic? 1
  • +

Replies To: Avoiding the Over-Engineering Trap

#2 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 10484
  • View blog
  • Posts: 40,483
  • Joined: 12-June 08

Re: Avoiding the Over-Engineering Trap

Posted 07 July 2015 - 01:53 PM

When it becomes clear it will be a nightmare to maintain later down the path.. or that if any other team member needs to pitch in it would take them a silly amount of time to trace through the code to figure it out..

Another sign - when people start muttering "I wonder if I can do that with the minimal amount of lines". Low line count has a time and place, but to agonize hours over it to make the code no longer readable is bad.
Was This Post Helpful? 1
  • +
  • -

#3 macosxnerd101  Icon User is online

  • Games, Graphs, and Auctions
  • member icon




Reputation: 11315
  • View blog
  • Posts: 42,636
  • Joined: 27-December 08

Re: Avoiding the Over-Engineering Trap

Posted 07 July 2015 - 03:49 PM

Quote

or that if any other team member needs to pitch in it would take them a silly amount of time to trace through the code to figure it out..

I really like this point! This has been my observation with over-engineering. The solution becomes bloated, overly-complicated, and the code base gets really dense.

I've never been around the minimal lines of code folks, outside of intro to programming classes, though. That's an interesting way to look at it. Certainly if one platform will shorten development time substantially (and usually, this means significantly fewer lines of code), then I'm for it as long as things will work the same.
Was This Post Helpful? 0
  • +
  • -

#4 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3151
  • View blog
  • Posts: 19,194
  • Joined: 14-September 07

Re: Avoiding the Over-Engineering Trap

Posted 07 July 2015 - 06:45 PM

Don't let perfect be the enemy of good.

There is a guy I work with who feels the need to cover EVERY edge case. No Tim, a mouse will probably not sneak into the server room and nibble on a cable while you're processing incoming data.
Was This Post Helpful? 1
  • +
  • -

#5 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 10484
  • View blog
  • Posts: 40,483
  • Joined: 12-June 08

Re: Avoiding the Over-Engineering Trap

Posted 07 July 2015 - 06:56 PM

Give a mouse a browser cookie and he'll want a data packet. Give the mouse a datapacket and he'll want the entire pipe. Give the mouse the entire pipe and he'll want the server source. Give him your server and boom.. you have massive exception!
Was This Post Helpful? 1
  • +
  • -

#6 ghozt2015  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 19
  • Joined: 19-July 15

Re: Avoiding the Over-Engineering Trap

Posted 21 July 2015 - 08:25 PM

View PostKYA, on 07 July 2015 - 06:45 PM, said:

Don't let perfect be the enemy of good.

There is a guy I work with who feels the need to cover EVERY edge case. No Tim, a mouse will probably not sneak into the server room and nibble on a cable while you're processing incoming data.


You never know though! There is always a possibility...I would rather be safe then sorry, haha ;)
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1