Stack OverflowWhat are the biggest potential time wasters in development?
[+41] [52] pencilCake
[2009-11-19 15:28:02]
[ productivity time-wasters ]

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:


(120) Spending too much time on SO. - evolve
(1) This is related:… - Paul McMillan
(1)… would also be related. - JB King
I agree SO is a time-waster but adds to productivity :) - 0A0D
(2) There are some times when it's really important to understand what someone elses code is doing as it may radically alter how you choose to interact with it. This becomes more important when there's poor documentation. Besides, you can learn a lot from seeing someone elses code. especially if they're Jon Skeet! - Middletone
[+74] [2009-11-19 15:30:21] Rich

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

(11) 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. - dsimcha
I wish I could up vote this twice. - Gratzy
+3 for premature optimizations - Simone Carletti
Which would take more time: over-architecting or under-architecting? Think of the long term consequences, maintenance, etc. - MPelletier
(13) 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! - MaR
+1 for premature optimizations. - Chris
-1 for "premature optimizations" cliche, +1 for each of the other points. - peterchen
(2) Probably not an issue in some places, but you missed one for when you work at Big Corp: Politics. - felideon
+1 for premature optimizations - been guilty of that in the past. - adrianos
[+61] [2009-11-19 15:36:46] adrianos

Project managers and customers who transmit their requirements telepathically.

Boy is that one true! - HLGEM
Telepathics beat the ones that don't transmit them at all! - Nathan Taylor
(1) And the ones who transmit spontaneously based on the day of the week, the weather, the mood and the latest movie they have watched... - pencilCake
(5) 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
(3) @ 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. - adrianos
@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! - pipTheGeek
@ 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 - BeMeCollective
Yeah, everyone scarpers when the fit hits the shan. - adrianos
[+52] [2009-11-19 15:30:00] Josh Stodola

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

(47) 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!! - James
@Xaero, F6? How dare you? it's Ctrl-L - hasen j
(8) @Xaero, I'm resisting the urge to insert an obligatory XKCD reference - Julson Lim
(1) 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. - Kyralessa
ProductivityOverflow? - Konerak
[+47] [2009-11-19 16:38:23] Conor
  • 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
(2) +1 for the time it took to write all this:) - Antonio Louro
(5) "• reading long lists" - a paid nerd
[+45] [2009-11-19 15:30:27] simon

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
(3) accumulatively - you mean cumulatively ? ;-) - Eamon Nerbonne
Thanks, I think cumulatively is more fitting. - simon
[+34] [2009-11-19 15:30:34] Developer Art
  • 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

[+25] [2009-11-19 15:56:26] Matt

Being FORCED to use Lotus notes as an email client.

It's soul destroying :(

argh - I endured a year of that. Never again. - Nick
Amen brother! The thing is an absolute abomination. - Gordon Mackie JoanMiro
Unemployment is starting to look pretty good. - Morbo
I wish I could +2 - Nescio
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
(1) 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 - Phaedrus
+1 I've been in Notes Hell for months now after years of Outlook... someone kill me - Dave Swersky
[+17] [2009-11-19 15:49:57] lorenzog

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

[+17] [2009-11-19 15:32:06] Dave Swersky

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

[+17] [2009-11-19 18:34:20] ammoQ

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. - TrueWill
[+8] [2009-11-19 15:44:36] Robert Wohlfarth

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.

[+8] [2009-11-19 15:45:08] monorailkitty

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

[+8] [2009-11-19 15:45:45] Drevak

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

This is the worst! - TheSean
[+8] [2009-11-19 16:39:00] Gordon Mackie JoanMiro

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.

(1) 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. - Roboprog
[+8] [2009-11-19 16:59:22] JasCav

My number one time waster...

alt text

[+6] [2009-11-19 17:24:52] Ryan Liang

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

[+6] [2009-11-19 16:17:12] Kilhoffer

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

(1) 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 - Steve
That would be awesome. It would probably offend the client I'm currently working for, however. Still, it would really help me! - Kilhoffer
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... - tomlog
[+5] [2009-11-19 15:39:21] Kelly French

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.

(1) 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. - Gratzy
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 - Gratzy
(1) I'd say using debug print statements is a form of debugging - CiscoIPPhone
(2) Breakpoints and Watches are print statements that don't clutter your code. - Annabelle
(1) +1 for unit testing. Keeps you from wasting time in the debugger and from doing rework when testers or the customer find a bug. - TrueWill
(1) 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. - Longpoke
[+4] [2009-11-19 16:31:02] miku

Getting the requirements wrong.

cost == time?

Citing Barry Boehm [1]:

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: At the end, there are some more references; Barry Boehm's lifetime contributions in one book: - miku
[+3] [2009-11-19 15:34:26] marc_s

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. - pencilCake
[+3] [2009-11-19 18:51:03] artdanil

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. - TrueWill
[+2] [2009-11-19 15:36:13] Bob Moore

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

[+2] [2009-11-19 17:30:52] Marc
  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).

[+2] [2009-11-19 18:31:28] Shailesh Kumar

Frequently changing requirements.

[+1] [2009-11-19 17:06:12] Ian Kremer

Lack of any, even remotely organized, source control!

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

(1) I'd be updating my resume. No source control == insane risk. - TrueWill
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
[+1] [2009-11-19 16:35:13] Gordon Mackie JoanMiro

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.

[+1] [2009-11-19 15:50:28] HLGEM

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.

[+1] [2009-11-19 15:43:32] JB King

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.

[+1] [2009-11-19 15:43:38] chills42

Complete and utter lack of specifications.

[+1] [2009-11-19 15:33:59] Tim

Not defining interfaces upfront.

[+1] [2009-11-19 15:46:29] Stefan Hendriks

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.

[+1] [2009-11-19 18:48:40] NDP

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)

[+1] [2009-12-05 13:20:15] cartoonfox

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.

[+1] [2009-11-19 17:30:00] Dylan Berry
  • 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.

[+1] [2009-11-19 20:25:20] jheriko

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.

[+1] [2009-11-20 04:21:23] RocketSurgeon

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.

[+1] [2009-11-20 06:16:20] Eli Bendersky

Procrastination [1], of course.


[+1] [2009-11-20 07:20:11] Talvi Watia

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!

[0] [2009-11-20 11:00:58] Nadir SOUALEM
  • 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

[0] [2009-11-21 00:51:13] Name

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

[0] [2009-11-21 01:12:42] Shaun ....good times.

[0] [2009-11-21 01:33:58] timday

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...).

[0] [2009-11-21 14:12:59] JonoW

Pesky customers

[0] [2009-12-03 16:06:26] Priyabrata Hota
  • 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.

[0] [2009-12-09 21:15:59] iterationx

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.

[0] [2009-11-19 18:49:56] TrueWill

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.

[0] [2009-11-19 18:55:41] azamsharp

Boring useless meetings that serves as time vampire!

[0] [2009-11-19 15:42:18] ApoY2k

Handling with users and clients...

[0] [2009-11-19 15:39:08] Pavel Shved

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

[0] [2009-11-19 15:34:40] Ben Fransen

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.

[0] [2009-11-19 15:34:42] Erlock

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
[0] [2009-11-19 17:25:31] Ed Schembor

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