What are the biggest potential time wasters in development?

Question

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.

Related:

• Any aids to help you get back in the flow?
• What are things that make a programmer's life miserable?
• How to deal with interruptions at work?

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

• 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

Answer 5

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

Answer 6

Not defining interfaces upfront.

Answer 7

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

Answer 8

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.

Answer 9

Mmh, I dunno, customers?

Answer 10

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

Answer 11

Project managers and customers who transmit their requirements telepathically.

Answer 12

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

Answer 13

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.

Answer 14

Handling with users and clients...

Answer 15

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.

Answer 16

Complete and utter lack of specifications.

Answer 17

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.

Answer 18

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

Answer 19

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

Answer 20

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.

Answer 21

Besides trying to make thing work for ie6, I'd say the internet itself as beautifully explained on http://www.phdcomics.com/comics.php?f=878

Answer 22

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.

Answer 23

Being FORCED to use Lotus notes as an email client.

It's soul destroying :(

Answer 24

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

Answer 25

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

Answer 26

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.

Answer 27

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

Answer 28

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.

Answer 29

My number one time waster...

Answer 30

Lack of any, even remotely organized, source control!

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

Answer 31

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

Answer 32

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

Answer 33

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

Answer 34

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

Answer 35

Frequently changing requirements.

Answer 36

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?

Answer 37

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)

Answer 38

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.

Or:

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.

Answer 39

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

the program should do thing as good as predecessor or better

Answer 40

Boring useless meetings that serves as time vampire!

Answer 41

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.

Answer 42

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.

Answer 43

Procrastination, of course.

Answer 44

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!

Answer 45

• 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

Answer 46

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

Answer 47

cracked.com ....good times.

Answer 48

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

Answer 49

Pesky customers

Answer 50

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

Answer 51

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.

Answer 52

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.