When does it become overkill?

Question

First off, I apologize cause I don't know how to make a community thread; so someone help me out please.

As a developer, across many platforms, technologies and even on an infrastructure level; I always find myself asking, when am I doing TOO much?!?

It's been a never ending learning process, since I started. One (1) thing I learned is that requirements are barely valid for an extended period of time, and as such a little foresight may go a long way.

But where is the balance, and how do you know when you're losing time, not gaining it?!

Answer 1

When the processes overtake the results.

Too many times have we seen that if the developers are focusing more on the process rather than the results (as in quality, making the deadline, etc.) bad things commence.

This is why it should be never forgotten that the purpose of code reviews, design patterns, etc. is to make the code better, but they are not the target themselves.

Answer 2

You are doing too much when the average developer can't understand what you did by reading your code.

• Do frequent code reviews with your team.
• Discuss with the architectures, technologies or patterns you plan to use. (in daily stand-up meetings if you have them)

I fight all CV driven "architects" I encounter. I wish the dome existed! ;)

I believe the world is wasting a huge pile of money that we could use for improving our (programmer's) life instead.

Answer 3

For me I like the approach Kent Beck puts forward in XP (not sure if it's "his" idea or someone else's but that's where I first heard it):

It's hard enough to solve today's problems without trying to work out what tomorrow's problems are and solve them too.

Developers can spend a lot of time on solutions for requirements that don't exist, edge cases which will never occur or even genuine problems where the impact of the problem is significantly less than the cost of preventing it.

This is time that could be put into things users will really want and use, things which will give them benefits that will massively outweigh even the inconvenience that will be caused in the unlikely event that one of these things actually happens.

Beyond even this non-optimal outcome for the user, the impact on the developer of over engineering in this way tends to be over complex code that is harder to support and harder to enhance.

So for me if you know, or can be fairly certain, that something is a requirement or is going to cause a problem then address it, if not then don't.

You may have to come back and rework it when it turns out that there was a wider requirement than you originally implemented, but generally the total effort you put in across the project will still be lower because in most cases that won't happen.

Answer 4

Your question is quite open-ended, so I'll interpret it as "doing too much on one part of the project":

For me, it's easy to spend too much time on something which doesn't really provide much gain for the customer. Often, it is the tiny things such as "Well, it works, but not entirely like I want it too" where the customer probably wouldn't care if it worked this way or another.

When that happens, I should stop it and spent time on things which are more important. It's better that the product works as a whole than not but you have these smaller parts which work perfectly.

Writing tracer code (from Code Complete) is probably a good idea of avoiding this: You start your project by writing code which connects the whole code - from the GUI (or near to it) all the way to the backend and then back. That way you always have something that works and you don't spent time perfecting the little things until the whole thing runs.

But still, it is a matter of discipline and prioritizing.

Answer 5

When I answer no to "am I going to be mad I didn't do this later and it bites me..

IRL Resource and time constraints usually get me before I have to ask this question much though. At that point you just focus on the most important/achievable bits and hope for the best.

Answer 6

a never ending learning process indeed! ...and i think it stays that way! The balance is when things are efficient enough and you have the time to do something else apart from programming as well. I 'll agree with gablin " a matter of discipline and prioritizing" and jim hopkins on that it becomes instinct after a while. I know that perfecting the small parts is what makes us happy but in the end it's all about what makes the end user happy. so i 'd say the balance (or maybe the compromise) is make the end user / customer / client happy first (which should be plan A) and then if there's time work on perfecting - making more efficient your "small parts" and/or everything else you please. At some point you have to say "enough" though :) otherwise yes, it will become an overkill!

the worst case scenario of course is when the end user / customer / client is you! :)