Ask Slashdot: What Practices Impede Developers' Productivity? 457
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?"
The Number One Impediment is MEETINGS (Score:5, Insightful)
Meetings are how people who don't know what they are doing suck the productivity out the people who do.
#1 visiting slashdot (Score:5, Insightful)
#1 visiting slashdot
Wouldn't that be...... (Score:5, Insightful)
...software patents?
Another Big Impediment (Score:5, Insightful)
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.
Re:The Number One Impediment is MEETINGS (Score:5, Insightful)
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.
Re:The Number One Impediment is MEETINGS (Score:4, Insightful)
I second this.
Meetings are a big waste of time. Take each person's topics, multiply the time by the number of people, and soon enough you realize that for most people at the meeting, they are wasting 1 / (n-1)*T of the meeting time (T), with n-people.
I'd rather send out an email, "Working on module X, starting connection to module Y" and keep working. Yeah, there's value in keeping up with your peers' work, but this is not worth an hour a day, for example. I can go spend that time with the specific people that I am working with and get a lot more out of that than their piece in a meeting.
Other runners up for wastes of time: Power point presentations of nearly any sort, design reviews with non-technical folks, and repetitive "because it's in the contract" presentations.
Re:fix it later (Score:5, Insightful)
you're already having trouble meeting a deadline
Artfical deadlines imposed by management are a major suck of productivity.
The phone (Score:4, Insightful)
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.
For me, it's a distracting environment (Score:5, Insightful)
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.
The Number Two Time-Waster is "REPLY-ALL" (Score:5, Insightful)
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.
Offshoring (Score:5, Insightful)
Re:fix it later (Score:5, Insightful)
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.
Multitasking between unrelated activities (Score:5, Insightful)
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.
And then there's the PAY (Score:5, Insightful)
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.
Re:The Number One Impediment is MEETINGS (Score:3, Insightful)
I'm going to politely disagree with you on some points.
Agile and Scrum (in theory) are wonderful tools, but once you get away from the blessed toolset and modify it for your usage it becomes a nightmare.
Case in Point: My team started having daily 10 minute status meetings. Some of us learned how to manage expectations in the meeting and kept our updates under 30 seconds. Others spend several minutes communicating to the entire team about something that could/should be taken offline (or to a subgroup). Now we've gone to 2x/week meetings that are at minimum 30 minutes long. The 30 second developers are still reporting in 30 seconds. The long duration ones are taking even longer.
Re:Multitasking between unrelated activities (Score:4, Insightful)
How about a team lead that text, calls or drops by every 30 minutes like clockwork? How am I supposed to get anything done when he interrupts my train of thought 15 times a day?
Re:The Number One Impediment is MEETINGS (Score:5, Insightful)
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.
The issue isn't meetings, it's bad meetings. Each meeting should have a set agenda and a time limit for each topic. When I was a senior developer, I would have a weekly status meeting with my team. The meeting always started off with basic status reports (what did you do, what are you stuck on, what do you need help with), followed by project updates from other teams (where pertinent) and finally a free topic session to discuss any issue. If something took more than a couple minutes to discuss, we'd table it for a separate meeting with only the people that needed to be there. Meetings should exist to make sure everyone's on the same page and so people who need something have a forum to ask for it. Without a firm agenda (which is aggressively held to) meetings lower productivity.
Re:fix it later (Score:4, Insightful)
Re:The Number One Impediment is MEETINGS (Score:5, Insightful)
Working environment (Score:5, Insightful)
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
Re:And then there's the PAY (Score:2, Insightful)
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.
I'm pretty sure that's how the higher-ups think it works. That is, they have a project they want done and believe it can be done by Date X. They then hire/assign the appropriate number of people, such that 40-hour weeks will result in success. But they are horribly, horribly bad at estimating productivity.
Under a pay-by-hour model, the cost of poor estimates is on the company. Under a pay-by-piece model, the cost of poor estimates is on the programmer. ie, if you underestimate the time it will take to finish a particular Result, then you also undercut your wage. Also, I'm pretty sure that human nature is to fill up the allotted time with procrastination, such that any project takes just a little bit longer than the time allowed.
Re:For me, it's a distracting environment (Score:4, Insightful)
That is bad, but I think much worse is a geographically dispersed "team" (like some people on US east coast, some west coast, some Asia, some Europe). Come in at 9AM, need to ask a question of another team member who won't be at work for another 12 hours, wait a whole day for a simple response, repeat as needed.
Re:And then there's the PAY (Score:5, Insightful)
Or people start getting the idea that if you can finish work in 20 hours, they can thus give you double the work.
Re:The Number One Impediment is MEETINGS (Score:4, Insightful)
The alternative, scheduling meetings at the beginning or end of the day, misses people who arrive and depart early or those who arrive and depart late. Core hours with meetings scheduled during that time is about the best you can do, if you want to give everyone some flexibility in working hours. Of course, you could have people attend meetings at both ends of the day (as those of us working with overseas teams have come to love), but I'm pretty sure that wasn't the solution you were looking for, either.
Re:fix it later (Score:5, Insightful)
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.
Re:fix it later (Score:5, Insightful)
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.
Re:And then there's the PAY (Score:4, Insightful)
That already happens to the people who can finish their work quickly.
Re:And then there's the PAY (Score:5, Insightful)
Yeah, nothing like not knowing how much your pay check will be for or getting some shitcan job you are doomed to fail at.
Pay a good salary, motivate the team, listen to them when they tell you a project is doomed from the start and set realistic goals. Works for me.
Comment removed (Score:4, Insightful)
Re:Too Much Documentation (Score:5, Insightful)
I have never, ever, in my life seen too much documentation. I have rarely seen anything that was even close to sufficiently documented.