Actually I am interested in hearing others experience on this subject: Time wasters.

By saying that, I mean the things that are a trap to fall into during the development phase and let us developers lose a ridiculous amount of time - which ultimately does not deliver any useful output in the end. Here are some examples of things I have encountered that waste time:

  • Instead of accepting some part of a code written by a colleague as a black box that works perfectly fine, I dive into deep details of it to understand how it works.

  • When I start to look for a solution to a problem on the Internet, to end up on an article or a forum discussion which is too far beyond what I actually wanted to find out.

  • Focus on polishing the code itself and forgetting the main goal of the functionality.


+48  A: 

StackOverflow, of course. Although I feel that I gain alot from it, my boss would beg to differ.

Josh Stodola
Yes, everytime I hit 'F6' I say "hmm, let's take a quick look at SO" ... an hour later I remember that my build finished 59 minutes ago...
Philip Wallace
Haha, compile time always gets me too!
Josh Stodola
+1 I would have to say I probably spend a little too much time on here aswell!!
@Xaero, F6? How dare you? it's Ctrl-L
hasen j
@Xaero, I'm resisting the urge to insert an obligatory XKCD reference
Julson Lim
Of course, Xaero, what this means is that compile time is the real time-waster. If compilation were instantaneous, you wouldn't flip over to StackOverflow in the first place. Perhaps this makes a case for separating projects by interface boundaries, for instance, so that a change in one project doesn't cause a cascading recompile in everything else.
+71  A: 

Over-architecting, premature optimizations, writing irrelevant unit tests for the sake of writing unit tests

Good one. IMHO it's better to have no unittests than to have unittests that don't properly exercise the most complicated, and therefore potentially buggy, parts of your functionality. Having unittests that only test the simple cases gives a false sense of security.
I wish I could up vote this twice.
+3 for premature optimizations
Simone Carletti
Which would take more time: over-architecting or under-architecting? Think of the long term consequences, maintenance, etc.
Well this can be also almost entirely negated: under-architecting can be equally bad, not keeping an eye on performance targets early enough, writing untestable code. There are no simple answers!
+1 for premature optimizations.
-1 for "premature optimizations" cliche, +1 for each of the other points.
Probably not an issue in some places, but you missed one for when you work at Big Corp: Politics.
+1 for premature optimizations - been guilty of that in the past.
+43  A: 

Interruptions - phone calls, conversations, things you have to react to immediately. These all take you off the zone, and waste cumulatively a lots of time.

"accumulatedly" Haha I think you mean accumulatively
Josh Stodola
accumulatively - you mean cumulatively ? ;-)
Eamon Nerbonne
Thanks, I think cumulatively is more fitting.
+32  A: 
  • Ignoring the YAGNI (You ain't gonna need it) principle to build heavy software piece nobody asked for

  • Neglecting the KISS (Keep it simple stupid) principle also helps a lot in stretching beyond all deadlines

  • Saving minutes in the beginning quickly hacking things together not creating a quality codebase foundation helps waste weeks and months later in desperate attempts to maintain it

Developer Art
+16  A: 

Spending more time as a senior developer/tech lead fighting political and administrative battles than writing code and mentoring the team.

Dave Swersky

Not defining interfaces upfront.

+2  A: 

Users and managers, of course :-)

Without users complaining about the current system and asking for the impossible in the next system, and managers watching over your shoulder and giving "good advice" all the time, IT would be a really nice field to play in :)

But I think they could be even a time saver if a good cooperation and communication could be established.
burak ozdogan

Mainly loosing the focus on functionality rather then code-side techniques / useless optimalization, which cost more hours / money than the customer really needs for his/her situation.

Ben Fransen

Mmh, I dunno, customers?

"Man, if it weren't for these pesky paying customers, we could get a lot of work done around here!" You are a cliche.
Paul McGuire
+1  A: 

Fighting consultants. The way some of them react to criticism of their architecture astronautics, you'd think I'd tried to murder their children.

Bob Moore
+55  A: 

Project managers and customers who transmit their requirements telepathically.

Boy is that one true!
Telepathics beat the ones that don't transmit them at all!
Nathan Taylor
And the ones who transmit spontaneously based on the day of the week, the weather, the mood and the latest movie they have watched...
burak ozdogan
Yeah, but the responsibility has to fall back on the dev at some point for not having made ABSOLUTELY certain EVERY detail of the customers vision for the project. Non-devs don't know what they want. The most important (and most difficult) part of our job is not code, it's communication.
@ Chris what you're describing there is a business analyst. I work on enterprise level applications and there's only so much that you can second guess. You can't make provision for _every_ grey area because you have to do _some_ coding at some point.
@Chris, we double (and triple) checked a recent CHANGE to a spec, went to QA and found that the change wasn't what they wanted!+1 - Users cause most delays on development projects!
@ adriano, what you are saying is absolutely correct in paper, but you know it: The magic is you, not the analysts. I have a very strong shield of analysts between me and the customer (3 layers), but when the walls shake, the line becomes VoodoMagic<-------------->YellingCustomer. No analysts in between. Regards! Ari
Yeah, everyone scarpers when the fit hits the shan.

Workflow, when you have to slack while your application is building.

Pavel Shved
+4  A: 

Debugging. Unless your compile takes all day, start with print statements or write unit tests. Debugging is extremely more useful when you have a unit test (failing of course) that can reproduce the issue.

Kelly French
Seriously? You find debugging a waste of time? I usually laugh at myself when I find myself stepping through my code in my head instead of just launching the debugger and seeing exactly whats going on.
No, but I've found it easy to spend hours in the debugger looking for some bug or trying to figure out why some condition is failing when I would have been better off to narrow the problem down first using print statements. Debug all you want if you have a unit test to help you reset the conditions that are causing the problem.
Kelly French
Thats not my down vote BTW
I'd say using debug print statements is a form of debugging
Breakpoints and Watches are print statements that don't clutter your code.
+1 for unit testing. Keeps you from wasting time in the debugger and from doing rework when testers or the customer find a bug.
I try to avoid debugging at all, if something is wrong, I look at the code and understand it. The last time I really did any real debugging was in some assembly projects. I agree with unit tests too.

Handling with users and clients...


Users flip-flopping on what they want causing the development to run in circles. For example, changing the layout of a page so something that was on the left is now on the right. Put back on the left. No, put it back on the right. No, put it back...

Sometimes not even getting there can be a time waster, IME. An example here would be going to a meeting to get approval but no one in the meeting can give it. I suppose another way to see this is a useless meeting.

JB King

Complete and utter lack of specifications.

+4  A: 

Boredom. When I find my mind wandering, it usually means that I need to step away from the problem for an hour or a day. My brain is bored and wants some rest to recharge. Then I can hit the project again with energy. It's during those wandering times that I make the most mistakes or decide to re-write large swaths of code.

Robert Wohlfarth
+6  A: 

Trying to adapt the job to the tools instead of the tools to the job and rolling-your-own libraries.

+6  A: 

Changing the same functionality over and over and over because contradictory user requests

This is the worst!

Too much talk about how it would be 'great to do this and that' instead of just keeping it simple and work on it without dreaming about things that probably will never come true. (code-wise).

Convincing other developers to write at least some tests if they check in new code.

Working with Selenium in complex dynamic websites => major time waster, don't try this unless you got more money you can dream off.

Stefan Hendriks
+15  A: 

Besides trying to make thing work for ie6, I'd say the internet itself as beautifully explained on


People who think premature optimizing means they should never consider performance in designing. I spend way too much time fixing stuff that never should have been written in the first place like cursors.

+24  A: 

Being FORCED to use Lotus notes as an email client.

It's soul destroying :(

Matt Joslin
argh - I endured a year of that. Never again.
Amen brother! The thing is an absolute abomination.
Gordon Mackie JoanMiro
Unemployment is starting to look pretty good.
I wish I could +2
it actually wastes my time in 2 ways. 1 because its so bad and unusable and 2 because I then spend ages moaning and fuming about how bad it is!
Matt Joslin
My supervisor let me spend two days of my internship configuring fetchmail, mutt and some internal Lotus-to-POP gateway bridge software -- provided I wrote up the instructions when I finished.
a paid nerd
I feel your pain +1
+1 I've been in Notes Hell for months now after years of Outlook... someone kill me
Dave Swersky
+5  A: 

Pointless meetings I get drawn into when I cannot contribute any value and the meeting brings me no value.

Wading through red tape to get something as simple as more memory in a machine or a piece of software installed. The larger the corp, the more steps involved and the more potential points of failure, leading to tons of time wasted by waiting.

Also having to go back correct other people's poor design decisions. I, of course, never make such mistakes! ;-)

our company handles that with a culture of everyone bringing their laptops to meetings. I was shocked the first time I saw it, but it really is useful
That would be awesome. It would probably offend the client I'm currently working for, however. Still, it would really help me!
Yes, I hate to have to go into a meeting where your contribution is for only one agenda point and takes just 5 minutes, after which you can sit an twiddle your thumbs for another hour...
+3  A: 

Getting the requirements wrong.

cost == time?

Citing Barry Boehm:

Fix specification errors early. To fix later, they will cost:

* 500% more at design stage
* 1,000% more at coding
* 2,000% more at unit test
* 20,000% more at delivery
Can you give a more specific citation? I'd love to show that quote to some folks.
Alex Feinman
*A diagram, approx in the middle*: the end, there are some more references;*Barry Boehm's lifetime contributions in one book*:

Team members who thrash and team leaders who let them.

Whether it's through SCRUM and daily stand ups or other means, it's important to avoid devs 'going dark' whilst they struggle with a piece of work or a bug they are trying to fix.

Gordon Mackie JoanMiro
+43  A: 
  • manually executing repetitive tasks: automate as much as possible and automate early so you get the most benefit. E.g. build, test, deploy, ...
  • googling for solutions: instead download the information you need, RTFM, know your tools well. Then you will have to jump online less often. You can waste hours online.
  • eating junk food: your brain will stop working, you will get sick. Big time waster.
  • not getting enough sleep: your brain will stop working, you will get sick. Big time waster.
  • not getting enough exercise: your brain will stop working, you will get sick. Big time waster.
  • not having a plan for what you are going to do in what time scales: if you don't have this you will wander around in circles wasting loads of time. It doesn't have to be that accurate. But you need it to stay focussed. It doesn't even have to be for a long period of time. E.g. make a plan for what you are going to do this week or even today.
  • noisy offices: phones, sales, buzzers, music. Will kill your productivity. Wear headphones.
  • poorly defined requirements:
  • non testing your code properly: the cost of a bug increases dramatically the later it is found in a project.
  • rebuilding your development environment again: it's fine - just use it.
  • meetings: keep these to a minimum
  • poor management, demoralised staff: will kill your output
  • integration with other systems - especially 3rd party systems: unless you've well defined interfaces you will spend ages sorting these out
  • overly complicated designs: do you really need distributed transactions, do you really need an enterprise mega-bean container that takes ages to configure and re-start
  • a poorly designed GUIs or a GUIs that kill productivity: click, click, click, scroll, click, yawn. Makesure you can set up your system entirely via configuration. Much better than doing things manually.
  • not using source control: are you mad? And put everything under source control: Source, build configurations,
  • too much documentation, conflicting documentation: Try to keep documentation to a minimum. Keep the documentation you have up to date. Put it under source control.
  • stupid processes: makesure your using a process that the team is happy with and that works for YOU.
+1 for the first 6 points
hasen j
+1 for the time it took to write all this:)
Antonio Louro
"• reading long lists"
a paid nerd
+6  A: 

The under-spec dev machine.

Time lost waiting for compile cycles of large solutions, and perhaps more significantly these days, unit test runs and static code analysis, can really mount up and represent a major amount of lost time.

Gordon Mackie JoanMiro
and a related problem: the too-expensive-to-replicate -- due to software licenses, data volume, or other rot -- dev or QA environment. So the environment has to be shared, taking turns, running slowly, or just flat out stomping on each other's data.
+6  A: 

My number one time waster...

alt text


Lack of any, even remotely organized, source control!

self rant Why wont my boss let me add it?!

Ian Kremer
I'd be updating my resume. No source control == insane risk.
I locally source control everything.
Paul Nathan
I was only recently brought into my company. Everything is sitting in multiple folders on our server. No real organization going on. Lots of 'Copy of Source 11/9/01', 'Dan's copy of Source 03' folders littering up the server.last I checked, our flagship product has 49,229,029 lines of Borland C++ (5.02) code, 27,837 warnings, and 0 comments.And I am the only programmer. 1 year out of school... Doing my best!
Ian Kremer
+3  A: 

Writing useless documents only because it is required by the corporate procedure/process/methodology.

Ryan Liang

Spending time on bogus or soon-to-be-thrown-away code for the sole sake of meeting some PM milestone.

Ed Schembor
  • Status update meetings. For the project I'm involved in currently, we're having two a day, each uses about 45 minutes.
  • Poor development environment setup. I primarily develop SharePoint solutions, if there's ever a situation which involves a shared development server, things get ugly, fast.
  • Poor project requirements. This one is self-explanatory.
Dylan Berry
+1  A: 
  1. Waiting for code to compile, IDEs to load, etc. Not because it take so long, but because it often takes just long enough for me to get distracted by something else.
  2. Troubleshooting code where errors have been suppressed or ignored (a la On Error Resume Next in VB).
+1  A: 

Frequently changing requirements.

Shailesh Kumar
+13  A: 

The biggest timewaster I have ever encountered, the black hole that sucks resources and mental health like no other, is: Basing a new project on an existing codebase that sucks. First, you spend months trying get accomated to it, just to find out that it is really that bad, no hidden beauty to be found. Then you spend lots of time to patch the new functions to it. Then you spend eternally in hell trying to debug the resulting monster. Meanwhile, requirements change - they always do - and you are forced to create more patches, breaking even more things that have worked - or have they?

+1 - Technical Debt's bad news.

Screwing around trying to get fancy development tools to work; (IDEs, linking libraries, project files, code syntax highlighting, remote debugging) when all that's really needed is a text editor and a compiler. Oh-jeez, no, gotta use the vendor's IDE because we're using the vendor's platform, and the vendor's API (cough Microsoft cough). (cough IBM cough)


Along the lines of Conor's comment on documentation: undocumented shared code.

  1. You need to use internal library X for your project. Its use is not obvious from the class and method names/signatures. XML documentation is minimal if present. There are no unit tests.
  2. You look at the source. You grep other projects for examples.
  3. You find one of the developers who wrote it and interrupt his work for an explanation.
  4. Another developer needs to use library X and repeats steps 1-3.


  1. You need the functionality that library X provides, but you don't know that it exists.
  2. You duplicate the functionality.

I'll throw in "projects that are not under CI" too. I hate spending half a day trying to get a project to build.

+2  A: 

Absence of requirements, or presenting them in unmeasurable, nonspecific manner:

the program should do thing as good as predecessor or better

+1. If you can't write acceptance tests for a requirement, it's not a requirement.

Boring useless meetings that serves as time vampire!


Feature creep. Small requests for small features might seem okay at first... until they take 4 weeks to implement.

The real biggest waster of my time though is having to port things to PS3... but I don't think that applies to everyone somehow.


Analysis paralysis.

The main goal of programming is adding value faster than adding cost. As any successfully developed area of human activity the returns reach a diminishing optimal minimum. To beat this problem of adding more value one should spend significant time in searching the solution and during this time there is no any new value being added. Thats how the magical circle of wasting time works.


Procrastination, of course.

Eli Bendersky

deciphering poor/obscure code and research.

I have to say if you know what you are doing its not going to take long. Unfortunately, when I have to deal with modifying or adding to an existing project... or making such and such web platform do something it doesn't do/can't do wastes time. Then to research the solution, track down how to fix it/make it better can take hours at times.

but what is your definition of waste?

If this is part of the project criteria, then it isn't a waste at all. Its part of the job.

So naturally that eliminates everything left - that which is unnecessary.

I had a co-worker that used to talk to his mom every day for an hour on Skype. Sure you could say that was necessary for him. but it wasn't for me. It was distracting and caused me to waste time because I wasn't completely focused on the work at hand.

Rejected projects/rejected code/rejected design is a big waste too I have found, as the time and energy I put in doesn't ever see the light of day. So ever since then I make sure I design my code in modules so even if the client never uses it, I can!

Talvi Watia
  • Usage of Internet for example facebook, twitter must be forbidden
  • software with poor documentation
  • bad management strategy (for example beginners in technical project)
  • non-use daily build of non-regressions tests
  • bad coding rules
  • Absence of requirements
  • My code compiles is not a proof that the code runs
  • non automatised tasks
  • non usage or bad usage of control version

IT nothing like waiting a week to get Java installed, because they randomly decided to screw up your PC to make it more secure.

A: ....good times.


Putting loads of effort into writing really nice documentation... which noone ever reads (hopefully because your app or API is so intuitively sensible that noone needed to, or because they just built on your example code, or you paired with them for just long enough to get them up to speed...).


Pesky customers

  • Deploying to Websphere manually through console rather than doing it through automated scripts.
  • Refreshing your view from Clearcase and even if it takes 10 minutes to refresh keep ignoring it.

Sometimes when any task (IDE loading/compiling source/deployment) takes longer time, there is a tendency for developers to get distracted and the task takes even longer time.

  • discussing sports, politics or stocks during office hours.
Priyabrata Hota

Micro-management by team leads that don't trust the developers they've hired.

It slows the team leads down - as they're having to think everything through and police the implementation. It's like having a team of one programmer plus a bunch of typists.

It demotivates the team and discourages people from improving the software.


Converting one language to another. For example, wrapping your c++ methods in C# and monkeying around with P/Invoke even if its automated (SWIG). Automatic code generation is something you probably want to avoid altogether.