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.
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.
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.
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.