What are some techniques that you can use to prevent over-engineering among the Software Developers? Meaning, how do you keep them focused on creating solutions of only the current requirements? Without trying to anticipate all future changes.

closed as too broad by amon, Basile Starynkevitch, Robbie Dee, gnat, Doc Brown Jun 1 '17 at 15:54

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    "how to convey that simpler code is better code, easier to maintain over the long run, and even faster to create and test." Because its not. If you do it wrong, simple code is as difficult to maintain as complex code. Sometimes a bit of complexity means the code is much easier to maintain and extend in the future. For example, you could hard-code certain things (which is simpler) or you could use the open-closed principle (more coplex to set up), while the latter means you can easily extend this piece of your software later. The art is figuring out where to invest in the future and where not – Polygnome Jun 1 '17 at 14:21
  • 2
    Define "over-engineering"... – Robbie Dee Jun 1 '17 at 14:52
  • Wabi-sabi principles. Accept that Software (especially in Agile development) is imperfect, impermanent, and incomplete. – Robbie Dee Jun 1 '17 at 15:04
  • 1
    This is surely a "too broad" question, since there are full books written about it. The canonical book is IMHO The Pragmatic Programmer, so get a copy for the team and teach them. – Doc Brown Jun 1 '17 at 15:54
  • 3
    @Nicolay: Your phrasing seem to indicate you think you are doing exactly the appropriate level of engineering but your colleagues are over-engineering. But nobody is over-engineering on purpose, and given we know nothing about the substance of your disagreements, it might just as well be you who are not thinking the design through. You and your colleagues need to have a conversation and you must be prepared to learn, since your colleagues may have a reason for their approach to design, just as you have. – JacquesB Jun 1 '17 at 17:09

Simple. Peer review.

Think you can code better then me? Bring it! Show me your simple style. Wow me with how easy it is to adapt as requirements change. I'll marvel at how easy it is to understand. And I'll learn. I'll imitate your style.

Or you may learn that what you think is the best way actually isn't. You might be ignoring concerns that are valid. You might need to reconsider your style.

How do you know which is right? By approaching every review willing to learn and willing to teach. If all you care about is winning you're going to be avoided because even if you are right, you're not helping.

Ready for the next level?

Encourage others to feel the same way. Notice something cool that you didn't know? Praise it! Make a fuss. Reward people who teach you things. Be the coder you wish they were.

When correcting don't make it personal. Don't shame. It's not even about how bad the code is. It's about how much better it could be. Don't dictate. Ask if it looks better like this.

Reviews are important but they are hard for us. Us code monkeys didn't go into this field because we're good with people. Keep it about the code and use as much tact and diplomacy as you can muster. Help others do the same.

That still not enough?

Is someone at the table trying to say something they can't quiet get across? Remember, we're not English majors or public speakers. We communicate best with code.

Some ideas just don't communicate well in meetings. If you run into one invite the other party to pair program with you for a bit. Huddle around one keyboard and show each other what you really mean. This is why I always have a guest chair and desk toys.

  • I like this approach as well. However, I worry about not looking like I'm boasting or competing with my teammates. I don't want to seem like I'm trying to be superior. Which is not the case at all. I simply want to point to the use of certain ideas like YAGNI or DRY to help write better code. But sometimes one individual gets defensive. – Nikolay Advolodkin Jun 1 '17 at 14:48
  • 2
    This is superb. Trying to convince someone that something is better is a fools errand - prove that it is and the argument is self-evident... – Robbie Dee Jun 1 '17 at 15:02
  • @NikolayAdvolodkin please note edit – candied_orange Jun 1 '17 at 15:13
  • I was thinking of doing an exercise that compares 2 solutions to the same problem to see which we believe is better. The solutions will be coded live by 2 Engineers and then analyzed afterwards to see how they turned out the way they did. Hoping to show the disadvantages of over-engineering and how one solution can quickly degrade as a result. What are your thoughts on this? – Nikolay Advolodkin Jun 1 '17 at 15:38
  • 2
    @Graham that's why when testing code for flexibility I don't even guess how things will change. I ask someone else to maliciously imagine the worst requirements changes that could be asked of this code. That way I'm not chasing what might be fun. I'm defending against what might be miserable. – candied_orange Jun 1 '17 at 17:19

It won't be easy,

But the best way is to send your developers to business-school. That way they learn to understand the "value" of their work in totally different ways.

I would actually say that's the biggest reason why I'm a more effective programmer then some of my coworkers: I went to business-school in addition to getting a programming education and it tought me the needs of the business more.

And one of the biggest needs is the ability to sell things......yesterday.

With over engineering you will delay the ability to sell a product indefinitely, because there will always be something that could have been done better.

  • "... the best way is to send your developers to business school". I'm not saying this adds nothing but this could equally apply to any other tangential discipline such as math, physics, UI design, manufacturing, engineering etc etc ad nauseam... – Robbie Dee Jun 1 '17 at 14:57
  • Hey I won't argue with this. Send me to business school. That in the budget right? ;) – candied_orange Jun 1 '17 at 15:33

Remind them that every line of code they write should contribute to a business goal. Praise them for writing as little code as possible.

However, you should also keep in mind, ease of maintenance contributes to business goals too.

Well architectured code actually reduces the overall lines of code in the long term, not the other way around.

Well-Architectured > Very-Simple > Poorly-Architectured


Hehe. I just got in and did not see the initial version of the question, just the edited one that has only one line left. Still I can read between the lines: "I am so frustrated with these developers who will not stick to just making it work while I don't care about anything else!".

I am afraid you came to the wrong place. Or not, if you are serious. You seem to have a communication issue on your hands. Either you do not understand that what the developers do is necessary or your developers do not understand that they will never have to address that code again so there is no point in making it maintainable.

Talk to them instead of people on the internet and see where you can meet.

Not the answer you're looking for? Browse other questions tagged or ask your own question.