Slashdot Mirror
Ask Slashdot: What Practices Impede Developers' Productivity?
nossim writes "When it comes to developers' productivity, numerous controversial studies stress the differences between individuals. As a freelance web developer, I've worked for a lot of companies, and I noticed how some companies foster good practices which improve individual productivity and some others are a nightmare in that regard. In your experience, what are the worst practices or problems that impede developers' productivity at an individual or organizational level?"
Meetings are how people who don't know what they are doing suck the productivity out the people who do.
Sent from my ENIAC
#1 visiting slashdot
...software patents?
Anytime the process boils down to "if it's not a new feature or an emergency bug fix, you are not allowed to spend any time on it. And if you do spend any time on something like fixing spaghetti code so that implementing new features and emergency fixes don't take an act of God, we will refuse to promote it to production, as our policy is to not promote changes to anything that 'already works.'"
Also: any environment that promotes code ownership (either explicitly or, more often, implicitly) so that you can't make any changes without it almost immediately becoming an HR issue.
you're already having trouble meeting a deadline
Artfical deadlines imposed by management are a major suck of productivity.
Having to answer the phone is a big one, I find. First is the interruption of the ringing phone itself, then the interruption in your thought process because you have to shift gears to answer someone's question, then the scramble to try and remember what you were doing before you were interrupted.
!#@%*)anks for hanging up the phone, dear.
I might be in a minority, but having a cube-less environment, where everyone is sitting in a huge room, behind a desk and can see and hear everyone else, is the worst. I feel like sitting in a 60's call center. The "goal" of this arrangement is "collaboration". The result is distraction and irritation.
It should really be renamed the I'M-COVERING-MY-ASS button.
As has been covered on /. before, this button is increasingly being disabled within corporations, and only to good effect.
Sent from my ENIAC
Offshoring any part of the development process.
giggity
Not to your customers ... shitty bug ridden releases which should have spent more time in DEV and QA are a nuisance.
And usually either mean management are lousy at setting release dates, or the developers are lousy at living up to them.
Your customers don't want to QA your code for you.
Lost at C:>. Found at C.
It doesn't matter if we're talking about bouncing between meetings and coding, coding and documentation, or just coding too many unrelated modules -- every time there's a substantial context switch, it takes a little bit for you to get your bearings and get up to speed. Sort of like a vehicle making sharp turns all of the time.
Koans and fables for the software engineer
Some meetings are necessary obviously... I'm in my first senior developer position now and I've instituted hard limits on meetings because it frustrates me to no end when idiots discuss minutiae for valuable hours of my team's time.
Agreed, but the actual time spent in meetings exceeds the required time by a significant factor at some workplaces.
Then there's the pay structure. It's almost as if some places want to pay as much as possible for work (paid overtime for panic fixes) or intend it to take as long as possible (long unproductive unpaid overtime). A better approach would be to pay for results, and damn the work time spent to achieve them, provided they meet the schedule. A 20 hour week can be as productive as a 40 hour week, and more productive than a 60 hour week.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
So... nobody posting responses understands project management... which is ok I guess, but let's see if I can put it in lamens: A project has due dates called milestones, a milestone typically is a product ready for QC, another milestone is completion of QC, so if QC is expected to take a week and then you have another week to fix it, a smart programmer who is about to not meet a deadline should mash out as much code as possible to not get fired for missing the deadline and then take advantage of the extra week... I'm not saying to deliberately introduce bugs or ignore them, but an edge case scenario can be resolved later during QC, or if that float isn't lining up right... that's not as mission critical as not delivering.
You want me to be productive as a developer? OK, here's what I need to do that:
A comfortable workspace. Give me a good solid desk with drawers and shelving to store reference and work materials. A phone with a headset so I can hold a conversation and work on the computer at the same time. A comfortable chair. Not one of the $99 specials from Office Depot, something high-end that's rated for 8 hours of continuous use. If what you're providing for an office workspace isn't at least as good as what I can afford personally at home, there's probably something wrong.
A good computer. It needs to have enough CPU horsepower and enough memory and disk for the software you expect me to be using. And it needs to be better than the minimum spec, I can't be productive when my tools are barely limping along. Good monitors too, and more than one. I'm going to regularly be pulling up digital reference materials and I'll have a lot of work on my screen, I need the screen real-estate to have all of it available without constantly having to shuffle windows to the top. You want to understand why, try doing your work with only one sheet of paper visible at a time and if you need to refer to 2 reports at once you have to lay one on top, read it, pull the other one out and lay it on top to read it, lather rinse repeat. If you don't think you can be productive working that way, why should you expect me to be?
Give me the reference materials and tools. If you expect me to work with tools or systems, give me all the documentation on them. It doesn't have to be physical, but it has to be available and up-to-date. If you want me to work on something, give me the tools to work on and with it. IDEs, editors, file comparison tools, merge utilities, it's possible to not skimp without going overboard. If you want me to work on software that accesses a database, give me a database client and access to those databases and a personal database I can play with to test things before I break the world for everybody else. If you want me to work on a system, set it up so I have my own installation I can put changes into to test. And for crying out loud, give me documentation on how to set it up and configure it and use it so I'm not completely lost going in.
Give me the ability to work uninterrupted. I know open-plan offices are all the rage, but you're expecting me to do work that requires high concentration for hours at a time. I can't do that with every conversation in the office distracting me, or everybody coming over randomly with questions or conversation. Same for phone calls. People should not be calling developers directly unless the developer's asked them to. If you need to, hire a receptionist to field calls and route them where they need to go (as opposed to where the caller wants them to go).
Let me work on my projects. I have a priority list. I use it to decide what things I should focus on now. But it doesn't do me any good if the priorities are constantly changing. I know, I know, the old saw about responding to business needs. Think a minute: maybe the problem isn't that I need to respond, but that business needs to start thinking more than a few days ahead? If requirements for a new project are constantly changing, perhaps you just don't have a good enough idea of what you want to start actual work on it yet. One of the worst ways to kill my productivity is to give me just enough time to get a handle on a project and start work, then make me drop it and start on a completely different project, and keep doing this repeatedly. When you pull me away from project A to work on B, it costs project A more than just the time I was working on B. The distraction will make me forget some of the details of what I was working on for A so when I get back to it I won't be able to just pick up where I left off, I'll have to backtrack and spend time remembering my train of thought and reconstructing all those details before I can start working again. So try to settle the priority lists down so they're not changing on a daily b
There are two strategies to deal with bugs; i'll fix it now or ill fix it later.
Cost for i'll fix it now'
X number of hours of developer time.
Cost to fix it later.
Time for QA to find bug.
Time for QA to document bug in replicatable manner.
X number of hours to fix bug
y number of hours to re-equant with code surrounding the bug.
QA time to test bug and verify it is fixed.
In effect by not fixing a known bug while trying to meet a deadline all you are ensuring is that the next stage will be late and the whole project will be even later. There is no time saved a a lot of time wasted. There is an applicable saying "you can pay me a little now or a lot later". Burying issues is never a good idea.
Your post is an excellent example of how a bad culture encourages bad decisions by developers. The company culture rewards the just mash out the code with known bugs for QC to find approach, then sliding the fix in when someone else "catches" it. A better culture would be to enter the bug in tracking yourself if the code is needed immediately and you don't have time to fix it before a drop dead deadline.
It shouldn't be necessary to have headphones on to be able to concentrate. I need an office. Two-up is fine if there's enough space, but the HP/Intel cube farm style or even worse, open-plan offices are not acceptable.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I have never, ever, in my life seen too much documentation. I have rarely seen anything that was even close to sufficiently documented.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/