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

Project managers and customers who transmit their requirements telepathically.

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

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

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.

• 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

Being FORCED to use Lotus notes as an email client.

It's soul destroying :(

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

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

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?

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.

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

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

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.

My number one time waster...

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

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

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.

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

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

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

the program should do thing as good as predecessor or better

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

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

Frequently changing requirements.

Lack of any, even remotely organized, source control!

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

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.

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.

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.

Complete and utter lack of specifications.

Not defining interfaces upfront.

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.

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)

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.

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

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 ^[1], of course.

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!

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

cracked.com ....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.

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.

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.

Boring useless meetings that serves as time vampire!

Handling with users and clients...

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

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.

Mmh, I dunno, customers?

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