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?!

  • 1
    Are we talking about things like scaling it for a million users from day one when you have no customers right now? Or more functional things like making the way tax calculations are carried out "configurable" when there is no suggestion they might ever change and even if they did no-one has any idea how they might work in this hypothetical new world? Commented Nov 24, 2010 at 14:08
  • 1
    Community Wiki is pretty much deprecated. It never really worked as planned. Don't worry about it. Commented Nov 24, 2010 at 18:57
  • When you're talking about a million users, overkill shouldn't be in your vocabulary. Commented Nov 25, 2010 at 7:32

6 Answers 6


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.

  • 5
    "I fight all CV driven "architects" I encounter" :)
    – Gratzy
    Commented Nov 24, 2010 at 14:58
  • 2
    I don't necessarily agree on this (practically), given an unequal level of developers. Amany times do I refactor similar projects to use a common library, and its not always as readable as before. Commented Nov 24, 2010 at 16:02
  • 1
    I guess it's pretty critical to have every team member understand well enough the source code they are working on. For the wealth of your project and also to avoid the architect to be the slave of his own implementations. So if there is too much difference in knowledge, fix that first.
    – user2567
    Commented Nov 24, 2010 at 16:07
  • 1
    I like your first sentence; clarity of code is important. But frequent code reviews? Architectural discussions in daily meetings...Really? And what exactly does "CV driven architects" mean? Commented Nov 24, 2010 at 16:25
  • 1
    Frequent code reviews means they must be automatic. You write a feature, one of your coleague review it and must understand it to validate it. If he questions you, you work together to make the code better. You mention your architectual problems during the stand-up, but discussion occurs after. Read Who Needs An Architect (martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf). CV driven means you will pick a technology because you want it on your CV
    – user2567
    Commented Nov 24, 2010 at 16:46

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.


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.

  • How about modularizing everything, and then just replace modules as you scale? or is that overkill as well!? Commented Nov 24, 2010 at 16:03
  • 1
    @Theofanis Patelides - Well structured code is obviously always a good idea but as with most things you can certainly take it too far. I think with many of these things it becomes instinct over time - you know what you've done previously that worked out and what was a waste of time. Commented Nov 24, 2010 at 16:13

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.

  • I agree, but I have also found myself many times spending hours of functionality and then passing it along to a non-technical enduser, and turning it down, because of the small things! Commented Nov 24, 2010 at 16:07

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.

  • 1
    For me there's nothing more irritating than deviating from Plan A Commented Nov 25, 2010 at 7:34

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! :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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