12

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

Theofanis Pantelides
  • 223
  • 1
  • 7
  • 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? – Jon Hopkins Nov 24 '10 at 14:08
  • 1
    Community Wiki is pretty much deprecated. It never really worked as planned. Don't worry about it. – David Thornley Nov 24 '10 at 18:57
  • When you're talking about a million users, overkill shouldn't be in your vocabulary. – Theofanis Pantelides Nov 25 '10 at 07:32

6 Answers6

13

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.

terminus
  • 565
  • 2
  • 9
12

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.

Community
  • 1
  • 5
    "I fight all CV driven "architects" I encounter" :) – Gratzy Nov 24 '10 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. – Theofanis Pantelides Nov 24 '10 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. –  Nov 24 '10 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? – Robert Harvey Nov 24 '10 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 (http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf). CV driven means you will pick a technology because you want it on your CV –  Nov 24 '10 at 16:46
  • Just to clarify. I mean readability, I mean it needs a little more abstract thinking. I constantly find sequential coding vs OOP, and I can never leave it alone. – Theofanis Pantelides Nov 25 '10 at 07:22
  • But CV driven 'architects', yeah I agree. – Theofanis Pantelides Nov 25 '10 at 07:26
  • 1
    You have CV driven [*put any role*] also. They are all dangerous. –  Nov 25 '10 at 07:28
  • You also bring up 'average developer'. Given your experience, how could you define this? Because rethinking the concept, if you can define that, you can use your comment as a rule of thumb. Very interesting! – Theofanis Pantelides Nov 25 '10 at 09:20
  • 1
    I was referring to the "average" of the team in that particular case (with very low turnover). If the average is too low, do what to do to increase it. But if you have strong problems recruiting you can use that strategy with the average developer of your industry. If the average is too low, do what to do to increase it. Better salary, better tools, better work conditions? I think Joel has a pretty well defined theory on the subject. –  Nov 25 '10 at 09:38
  • +1 for CV driven. I wish all of them would put "one-way trip to mars" on their CV. – user281377 Nov 26 '10 at 10:01
  • AWESOME reply!!! Let's create a new engineering standard to carry computer science forwards: **Average Driven Engineering -- Computer Science is dead because we already know everything there is to know about building systems**! Don't allow those darn so called architects looking to generalize and find patterns that work well for given problems get a foot-hold! Onto the barricades! (Btw. average will prevail by definition; the architect's job is to be above the average which is a never-ending quest towards being a better engineer) – Henrik Feb 12 '11 at 17:30
4

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.

Jon Hopkins
  • 22,734
  • 11
  • 90
  • 137
  • How about modularizing everything, and then just replace modules as you scale? or is that overkill as well!? – Theofanis Pantelides Nov 24 '10 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. – Jon Hopkins Nov 24 '10 at 16:13
1

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.

gablin
  • 17,377
  • 22
  • 89
  • 138
  • 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! – Theofanis Pantelides Nov 24 '10 at 16:07
1

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.

Bill
  • 8,330
  • 24
  • 52
1

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