How do deal with developers that over complicate projects

Question

Hey,

So I think every team has one of those developers that is always "cutting edge" or wants to over complicate something that can be kept simple. My preference is why build a rocket when you only need a bike?

So how do you deal with those team members? What if they have the mentality that since you are telling them its to complicated they then think that you aren't nearly as bright as they are? If you try to tell them any differently then they ALWAYS have an argument for why they are right.

Thoughts? Suggestions?

Answer 1

Prove them wrong. If they don't want to change once they've been proven wrong, they aren't worth your time.

If you can't prove them wrong, be more like them. :)

Answer 2

Have them write test cases for everything they do. If it truly is over-complicating the solution, then it should either a) take a lot more testing or b) fail a lot more testing. Also make it clear what time the schedule allows for the unit of work. If they believe that they can have a completed and fully tested solution in the amount of time, then maybe you should just let them go for it.

If they fail, then hopefully it will help them learn to do the simplest thing that works well.

Answer 3

LOL, since I sometimes fall into this category all I can say is have them PROVE that there way is better. Have them create a sample app showcasing the change with real figures / data to back it up. It's all well and good to want to roll over and use new tech but sometimes you just got to do what's right.

As to the overcomplicating things. I'm a firm believer in KISS. Depending on the complication level and the task that's trying to be solved I'd offer different suggestions. For example, I am actually currently replacing the life blood of an application that has some performance issues. Now my way is more complicated to a degree however it's much more scalable. I was able to prove using unit tests, diagrams, and code samples that the change isn't so much cutting edge or even overkill but that it was what should have been done in the beginning. But again, I had to prove it.

So when it's all said and done it's all in the PROOF.

Answer 4

This reminds of an article i read on Joel On Software.

Don't Let Architecture Astronauts Scare You

Answer 5

I was in your situation before. There's no hard and fast way to deal with such tricky situation.

You may think:
"why build a rocket when you only need a bike?"
They might think:
"why build a bike when I can build a rocket in a shorter time? Future-proof as well!"

To me, it relates to a bunch of complex issues:

• Business context
• Project requirements
• Timeline (internal/external)
• Clients' expectation (internal/external)
• Company product roadmap (if applicable)
• and much more...

If you are at a good position to explain/justify based on the above points, they might just give in. If they can counter you, you might want to consider building a rocket :)

Answer 6

A lot of the time, the task seems simplistic and everyone runs off to throw some code together to make it work. Then they find out it really wasn't as simple as it first appeared, usually after spending a lot of time coding and hyping it to the customers.

Along with some of the great suggestions already posted (make use-cases, have them prove it), it might be just as well to ask yourself if it is that the over-complicator just has more experience than you do. There are a lot of things that developers forget about when making a system (usability of the UI, can it be deployed easily, can it be supported remotely, etc) that experienced people will see right away. Then everyone thinks it is being over complicated when all that is really happening is that someone is trying to make it fit into the big picture.

But try the use-cases one for yourself. I've found that many times just stepping through how it would be used opens up a lot of other use scenarios that no one considered. It is a fairly quick way to justify to yourself if the other developer is really over complicating it or they are simply trying to make life easier for you post delivery.

Answer 7

The root problem with such developers is that they don't value simplicity. This is what you have to address. Otherwise, just as you say, every argument you make for simplicity will be viewed as you just not being able to handle the cool new stuff. It can take some time to try to get through to Mr. Sophisticated. Here are some things that might help:

• Make sure you read this really good article if you haven't already. In it Jeff Atwood discusses how to lead by example and respect, building upon another great article by Dennis Forbes.
• Whenever you discuss a solution with Mr. Sophisticated, always use the word simple interchangeably with the words great, elegant and professional. Similarly complicated with amateur and cutesy.
• Whenever he explains an overly-complicated plan, ask them how their scheme makes the overall solution simpler.
• Point them to some good information, like This article, This one, and Another one here.
• If he actively scorns simplicity, consider being blunt: tell them that beginners are happy to make things work, intermediates try to do cool stuff, and experts keep it simple. Tell him you think he has the potential to be a good developer, but that he's unfortunately stuck at intermediate.

You may have to keep at him for weeks or months to get through to him. Make sure that at the same time you show respect for his abilities, or nothing you do will work. When he makes baby-steps towards simplicity, ooh and ah and look impressed. Get excited when he names a class or method well, etc. Getting other developers' respect is what will motivate Mr. Sophisticated, so give him respect when he deserves it (or even just half-deserves it).

And even though this is all about trying to get Mr. Sophisticated to love the simple, keep in mind that there is sometimes value in his complicated plans; give him credit for it.

Answer 8

Occam's razor. Check wiki pedia.

Answer 9

Any fool can do complex. Doing simple takes a genius.

(can't remember who said that)

Answer 10

Sometimes it's not clear what "overcomplicate" means.

Boss: We need a Web server. Write one.

Developer: Why not use Apache? It's free.

Boss: No, that's too complicated. It's got all those configuration files you have to deal with. All we need is something that sends back static HTML pages. How hard can that be? You always overcomplicate things.

Developer: I suppose I could write one in Java.

Boss: There you go again. You're always talking about Java. Have you seen the size of the reference manual? Why can't you keep things simple and write it in C?

Answer 11

I worked with a person once who always seemed to make the simple complicated. Part of it stemmed, I think, from a sense of inadequacy. He had a drive to demonstrate that he was a better programmer than people thought he was. Unfortunately, the complexity often overwhelmed him (and the project). Projects ended up taking longer than they should, features would be left out, a lot of it wasn't tested as well as it should be, and there were subtle, and not so subtle, bugs. Often, I'd end up taking over the project and fixing/refactoring it into something reasonably stable and usable. Often that meant stripping a fair amount of code out and replacing it. I've got one that, in order to add any new features to, I'm simply going to have to do a rewrite because it's not scalable.

I wish I could say that the story had a happy ending. I tried working with him using TDD and other agile techniques to identify the critical stories and develop them incrementally, but he tended to view this as a rejection of him rather than an attempt to help him gain the confidence not to "over develop." Eventually, he was encouraged to find another position though a series of management actions.

In the end I think you need to figure out why the drive to complication exists. Each situation is probably different, but understanding the motivation is key to knowing how to help. Ultimately, the person has to be teachable for you to have any impact. As long as there is improvement and it doesn't affect the team or your projects, keep working at it. Once the progress stops or you find that you've reached an impasse, it may be necessary for both party's sakes to encourage him to find a place that's a better fit.

Answer 12

You have to know when a rocket is the right solution, and when a bike is the right solution.

You also have to have a sense of the long-term use of the project.

You also have to have a sense of the real requirements here; real requirements are almost never technological, but business.

In part, the answer I have is that it's the lead developers and managers job to communicate the real requirements and have the experience to know when a one-off is OK, and when a fully engineered solution is appropriate.

And as a final commentary, complexity happens.

Answer 13

I will play the contrarian voice. Simple code is great, and using known tools or techniques is great too, but this leads to inertia in teams, where people repeat themselves over and over again, without learning anything. Jumping systematically on the latest buzzword-compliant framework, and using poorly understood techniques haphazardly in a project are great ways to fail, but never trying anything new is also a sure way to fail, just in a different time frame.
The first time I wrote a unit test, it wasn't easy. When I began using Mocks, it was complicated. When I looked into WPF, it was "cutting edge". So resisting change is good, but only if there is space for change and experimentation.
To accommodate this tension between wanting to do new things vs. wanting to minimize risks, with my former team, we would keep a list of ideas/technologies we wanted to try out, and on each project, we would try to incorporate one, only one at a time, to see if this was worth adopting. That way, there was a team trade-off: we would have a very clear coding standard for what was "our base", but we would also have some playground for the hot-heads, with clear boundaries.

Answer 14

So, this is interesting. On the one hand, adding additional complexity is clearly a waste of time.

On the other hand, I do test driven development, though many of my coworkers do not. I have been told that adding interface seams between a UI page, the logic associated with it, and the underlying domain objects is adding "unnecessary complexity." Similarly with the idea of wrapping external dependencies behind interfaces that match the actual operations our code wants to use.

So, I'm a bit torn on this one. Adding unnecessary complexity is evil (which is why I don't build extra functionality into my code, I just try to keep it well-separated). On the other hand, "adding unnecessary complexity" can in some cases be code for "just do it the hacky way."