What things tend to slow a developer down?
Please try to refrain from posting answers that:
- are slow now but useful in the feature. (TDD, Refactoring, ...)
- list a distraction.
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
Oh this ones easy:
Anything that causes context switching.
Any attempt to follow a process that is not suited to the task at hand.
This can be all sorts of things, but common ones I see include:
All of these things can be immensely worthwhile on some projects or in some situations, but some organizations try to do everything one way and that leads to poor fit on other projects which often is productivity death.
Many answers talk about context-switching and getting out of the zone, and noise, especially conversation, is one of those things that leads to those for me.
In my cubeworld, I'm surrounded by noise and conversation on all sides. One row over, the mainframe team holds constant planning meetings in the cube row. Sometimes, they'll meet with consultants in an office along the wall, and that tends to lead to loud hootin' and hollerin' and laughin' and I have to go over and ask them to close their doors.
On the other side, the web team conference table is on the other side of my west cube wall, so I am part of every meeting, like it or not. There's also a printer on the other side of the south cube wall, and that's always good for chit-chat from people hanging out waiting for their printouts.
The immediate and obvious answer of "Can't you just get noise-canceling headphones" doesn't help when what you want is silence.
Sometimes for code reviews, I take my stack of papers to the lunchroom (at non-lunch times, of course), but there's a TV in there that's usually blaring. I'll turn it off if no one is watching. Otherwise, I'll go find an empty cube in an other department in another part of the building.
If you want your programmers to do the work they need to do, which is predominantly thinking and pondering and considering, they need an environment where they can do it.
Avoid everything that gets you out of "the zone". That means your email inbox, your twitter popup application, your corporate chat, etc.
Having a quiet working condition means avoiding that desktop noise too.
The Much That Slows You Down is a good blog post for this.
Many projects repeat core infrastructure-level features over and over, slowing that business down in delivering features that differentiate the business from its competitors.
It is inevitable that products and innovations will help reduce the time developers spend on non-differentiating tasks. The question is what form those services and tools will take.
Well lately the biggest slow down is because we are developing several things simulatneously that should have been done in a specific order. So I'm waiting until (names changed to protect the innocent) John finishes his component that I need for my SSIS package and Harry is slowed down waiting for me to import records because he needs some data to see to test his export (ever try to write a complex export report when there is no data in any of the tables?) and everybody is slowed down because design isn't done and the database tables we need to do our tasks haven't been created yet and may not even end up being what they said they were going to be, etc.
Even though you asked not to list distractions, they can be a big factor. Look at their work environment, check to see if they're being interrupted frequently or asked to do other things that aren't related to the project.
Sometimes, a developer might get stuck because they're doing something they've never done before, and they don't know where to look for help. If it's a small team or individual, it can be even more difficult. We tend to be somewhat prideful and dont like to admit when we dont know how to do things. Also, we dont like asking others for help. There's no easy way to get a developer to admit this, except maybe to ask if they can meet the deadline, or what they need to meet the deadline, and then hope they'll be honest. You may need to offer to bring in other help, or find someone that can help them.
Lack of clearly defined requirements, which leads to them having to figure things out or make decisions.
I could go on, but it's Friday and I want to forget about work.
Too many people on the project.
Seen it several times where the management decides based on no real data that they need to add more people to the project. That ends up in the ppl who know what's going on needing to stop everything to hold the hands of people who know little about what's going on. I've seen more than one project mushroom in size and then go in the toilet quickly from there whereas before it was going along fine, although maybe a little slow.
So you go from being a month late because of not enough velocity/too much to do to not delivering at all because you totally blew the budget on all those extra people.
Apart of the things mentioned by others, the long way between deciding to compile&run your code and getting a positive/negative result. Ideally, this RTT would be just a second, but I've seen an example of hours. BTW, unit testing tries to deal with this problem.
Another related this is a general latency of your working environment. Imagine you'd need to work over remote desktop connection to the computer on the other side of the world, over a creepy connection. I've been there. I've hated this.
Having a dependency on someone who's never around (such as your boss - if you need to ask a question but he's always in meetings)
Inadequate tools & equipment.
People shoving their oar in for no reason (any UI-visible change is subject to this) or just arguing the toss about trivial stuff.
Broken coffee machine
Being assigned the wrong tasks
This is a highly personal and perhaps controversial opinion, but planning and thinking too much about design up-front or writing "quality" code all the time. There's a saying that "weeks of coding can save you hours of planning" that might be true in some cases.
However I often see programmers try to sketch out a good design before starting coding. I find myself that it's easier to just "get going", as you program you will learn more about your problem and solution which will allow you to refactor your solution rapidly into a good design. Most of the issues arising are pretty much unknowable at the start of coding (atleast to my feeble mind) so wasting a lot of time designing up front is just a waste of time.
This is also why I don't like TDD, you waste too much time writing tests which makes you either less likely to refactor or takes up a lot of time to rewrite the tests. Unit Tests are great for some cases and some stages of a project, but the beginning of one isn't one of them IMHO :)
Get something working quickly and improve it.