Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When I program, I often get too involved with details. There might be some little thing that doesn't do exactly what I want it to, or maybe there's some little feature I want to add. Either way, none are really essential to the application - it's just a minor niusance (if any). However, when trying to fix it, I may happen to spend way more time on it than I planned, and there are things much more important that I should be doing instead of dealing with this little detail.

What can I do to avoid getting carried away with details, when there's more essential things that need doing?

(I didn't know how to tag this question, so feel free to add whatever appropriate tags that are missing.)

share|improve this question

9 Answers 9

In my experience it's always worth the time to figure out why it's doing what it's doing, because that improves your understanding of the system, and makes you better in the long term. After you understand why, then you have to make an educated guess: is it most cost-effective to fix the problem, work around it, or just document it and move on. This is a business decision.

If it really is an annoyance for the user, I'd err on the side of fixing it, or else you end up with "death by a thousand paper-cuts". Details matter.

share|improve this answer

Strange as it may sound, boredom can be your friend.

Try to enjoy the moment when an application/module/library "comes to life", when it first starts to operate, even if it isn't flawless yet. Once you get used to that feeling, you'll find that fine details, while interesting for some time, eventually get boring.

Another observation is that it's easier to let go of a small-scale problem, if you document it and file it in your todo list. Make sure you do revisit these problems though. After all, you don't want to hand over code that isn't quite up to scratch.

share|improve this answer
    
+1 for keeping a todo list. Must try that on my next project. –  gablin Feb 9 '11 at 14:25
    
@gablin If you are referring to your work life then I'd hope a TODO list in the form of a backlog or other means already exists. –  Aaron McIver Feb 9 '11 at 14:31
    
@Aaron: Yeah, but now I'm mostly concerned with personal or uni projects. ^^ –  gablin Feb 9 '11 at 14:32

I try to keep a list of TODOs to avoid this. Whenever I am working on a task and noticing something which would take some improvement but is not directly related to the actual task I am working on, I may fix it right away if the fix is trivial. Otherwise, I try to resist the temptation and instead make a note to return to this. (It could be a TODO comment in the code, a note on paper, a new entry in a text file etc. Note that the first works only if you don't already have dozens of unhandled TODOs sprinkled all over your codebase. I am working on a big legacy app with hundreds of TODO comments inherited mostly from prehistoric times, so I use paper.)

Once I finish the immediate task, I return to my notes and take the most important which still relates to the wider issue I am working on, and is doable within reasonable time limits. And so on.

In the end, when I finalized everything and committed the whole work, I may still have a few tasks left which are either not related to the current issue or too big to be done right now. I usually feed these into our issue tracker.

share|improve this answer

If you're getting things done on time, you're not spending too much time on details. Hopefully, this is not a result of fooling your superiors/customers into believing your time estimates are normal.

Sometimes it's easier to stick with a task that you know is completed by everyone else's standards and just keep tweaking some small piece of it then to get started on the next task which is not as much fun/is going to be very difficult. Some people are just detail oriented/borderline OCD.

I have the opposite problem and tend to want to get things done and miss out on some of the details. I force myself to hold off submitting things, and after a short break, go back and review.

In your case, once something 'works', take a break, and force yourself to move on to the next task knowing you can go back and work on some of the details if you have time. If you get things done on time, it's not really a problem, but a good trait to have as a developer.

share|improve this answer

Todo lists with a priority level can really help with this.

Any random thing that comes into your head that you want to add/fix/change/investigate, add it to the list, but make sure it gets the right priority level. Then just start from the top!

share|improve this answer

What do your "customers" want you to work on? While we sometimes write software strictly for our own use, most of the time we are writing software for someone else to use. Listen to them and set your priorities based on their feedback. This is where agile programming becomes helpful, a series of short releases giving you quick feedback.

share|improve this answer

Build in a delay for working on any new feature except those items which truly need immediate attention.

  • Saves from jumping around on details which later prove insignificant
  • Allows staying focused on the big picture -- the stuff that really matters

A lot of those new features are just distractions along the way. Very few items truly require immediate attention, and when they do they're obvious.

Stay focused by using a ticket managing system, like Trac or Jira or even a sheet of paper and a pencil. Continually re-prioritize in light of the main focus of what you hope to accomplish. It's amazing how many distractions can be eliminated this way.

share|improve this answer

Walk away from your desk and get a glass of water.

When you realize that you have spent way to long working on one thing. Walk away from your computer and think about what you were doing and ask yourself if it is really working towards completing your primary task.

Don't go back to your desk until you have a game plan on what you should be working on. Sometimes it means you will back out ALL the changes you have been working on so that you can refocus on your main task. Sometimes it means saving out the code you were working on and adding a new task to the project. And sometimes it means you will finish what you were working on.

share|improve this answer

Here's what I have learned from my experience:

Less is The New Perfections

  1. Build less scope.
  2. Build less feature.
  3. Build it perfect.

Build Less Scope

If you think you can't finish your app within several months, then you're scope is definitely too large. Split it into several milestones or sprints, makes adjustment of wich part of the system that is most essential, and which part is less. Or simply throw away scope that doesn't even makes sense.

Build Less Feature

I love features, we loves features don't we? But that's not what we really need. Think of the features that's really needed by the user, act yourself as a user and feel it, is it what you really need. Throw away features that's not really needed, or wait until the next release if you think it will be needed in the future.

Build It Perfect

That's it. If you have less scope and less feature, you can focus more on perfecting your app rather than bloating your app with unneeded features and scope. Perfect means works flawlessly, not necessarily being full featured.

It's hard to build something less complicated for a person like you, I know how you feel, I've been that road before. But what's the point in building an app that gets carried away indefinitely? It works for me, I hope it works for you to. :)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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