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
Saying, "I'll fix that bug later" or "QA will catch anything I miss." The sooner you fix a bug, the less time it will take you. Spending an extra 5 minutes now to verify the documentation for a function you call can save days later on.
"First they came for the slanderers and i said nothing."
#1 visiting slashdot
...software patents?
When I get in the zone I want to write code. I had a job that made you RDP to a development network to use Visual Studio on a machine that didn't have access to the internet (only to source control and the database server) and there was no copy/paste or file transfer to your environment -- you had to get the IT group to move files for you. You couldn't last 'in the zone' for very long before needing someone else's help to do *something*
Hitting brick walls like that, and not being able to take care of your own needs seriously crushes developer productivity (and to a certain extent, morale).
Procrastination is the Number One Productivity Impeder (Not sure if right word, but spellcheck isn't getting me)
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.
Trolling Slashdot generally eats up 50% to 80% of my work day.
The rest of the time in meetings or organizing meetings for later.
Nothing kills progress than having to create documentation that will never be read or updated.
Don't get me wrong - certain types of documentation are important (overall systems design, data models, for example). But unless you're going to continue to use the documentation after the project has been completed, don't bother creating it.
What most people seem to forget is that if you don't plan on maintaining all the documentation you create, you're wasting your time. Once a document is out of date, it no longer serves it's purpose. I'll expand on an adage: Outdated and incorrect documentation is worse than no documentation at all.
Imagine a manager who asks you about what helps you be productive, and what is slowing you down, then works to change your working environment, schedule, hours, etc. to maximize your quality of life & productivity....
Naturally, it's not common, because instead managers assume their developers won't know the first thing about their own work habits (and what improves/degrades them), and instead blindly tries to establish top-down processes that will make "the team" more productive.
Sometimes it'll work out; but to be sure, people are individuals, the best developers are *already* thinking about these things (and how to hack their own lives), and the ones that aren't will become better if they're encouraged to think about how they actually work.
One thing that applies to everyone, at a general level -- getting the level (and kind) of communication right.
Some people can't get difficult tasks done unless they can retreat into a silent bubble for days on end, free from distractions and completely focused. Most people, however, need at least some level of communication along the way, to intercept them (and help) if they're getting bogged down, getting lost and attacking the problem via brute force, or getting tangled up in their own perfectionism and spending way too much time polishing the first step when they have 19 steps of the solution still to go.
So they need regular (but short and very focused) communication where they're comfortable honestly discussing where they are and where they're going. (Hint: it's hard to avoid triggering ego traps in these kinds of discussions, but if you do, you'll quickly make the whole relationship completely dysfunctional, and useless).
Other people thing best in conversation, and will work best when more-or-less permanently paired with someone else (with similar needs, of course... don't pair them with the solo deep thinker!) -- together they can be far more clever and productive than they could possibly be separate.
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
Management who believes that every project must be analyzed, then designed, then coded, then tested. The IIC in our company has never written a line of software yet has built an organization that prevents anyone else from doing it efficiently, either. Since we have no development teams, just handoffs of work products, there isn't even a chance to get the right people together to do agile or even iterative work.
If we were even 5% as efficient as the rest of you developers, I would be absolutely amazed.
John
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
HOLY capital letters that was a LONG comment... I see where your COMING from but I don't TOTALLY agree. Meetings DO harm you as far as time is CONCERNED. Rarely are YOU exiting the meeting with a better UNDERSTANDING of what the meeting was SCHEDULED to resolve. Most of the TIME its so that some MANAGER can get the people who KNOW what they are DOING in one room to REACH a DECISION. Rarely are meetings beneficial to ALL parties involved which results in TIME loss and PRODUCTIVITY wasted. I'm using GRATUITOUS use of all caps like you HAVE in your response because I'm emphasizing my WORDS so you understand my intelligence level.
I'm not all the way into drinking the Agile koolaid, but to be fair the original idea of Scrum meetings was explicitly designed to avoid that problem. Scrum meetings are supposed to be led by a "Scrum-master", who is not supposed to be the manager or boss of the meeting participants. In fact the manager is not even supposed to be there. Scrum is supposed to be a way to facilitate communication within a team, so everyone knows what everyone else is working on. The scrummaster is just supposed to be another engineer on the team who facilitates the meeting so it moves along, and is not supposed to be someone who has any particular authority over the project or the participants.
Most companies have ignored that part, and the Scrum meetings are, as you say, run by the manager, as these daily "report your progress" checkins.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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
No, not at all. Remember the Dilbert Principle: The dumbest people in your organization should be promoted to where they do the least damage, i.e. management.
Lawrence J Peter described the same phenomenon as "Percussive Sublimation", and mentioned one film company that practiced this on a grand scale: They built a new Head Office, hundreds of miles from any studio or camera, and promoted all the useless people to work in the Head Office, where they busily ran around conferring with one another and otherwise wasting time, while the useful people happily worked in the studios making films.
So that's the point of management: Remove useless people from the code repo.
I am officially gone from
I've had managers that constantly try to shift my priorities to whatever has their attention that day. They want me to drop whatever I'm to focus on the most recent urgent pet project.
When it affects cash flow, I fully understand. We need to take care of a big advertiser or something like that, totally understandable. Pretty much everything that doesn't fit in that particular realm though, forces me to tell my boss it will have to wait so I can finish my other 10 urgent projects. The line "everything is top priority" also fits in this realm.
Pivotal Tracker is actually really helpful in this regard because there aren't task lists, there's a queue and something is at the top of it. That is what you work on. If a manager wants you to do something else you force them to de-prioritize your other tasks. It's fantastic in that regard because it forces managers to acknowledge they are slowing down their own requests.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
One company I worked for recently had a singularly interesting practice. They had no receptionist or phone answering service, so a call from an outside line or press on the door buzzer made every single fucking phone -- 25 of them -- in the open non-partitioned office ring until someone answered it. They would then have to ascertain who was calling, call the person they were trying to get through to (phone directory in word document on "intranet"), work out where that person was (notice system on "intranet"), take a message or let the person in. This included software developers, of course, who were sharing the open office with systems analysts, IT support staff, production support, and the kitchen area. Requests to work in other (quieter) parts of the building or at home were denied as it was deemed to be bad for team work or unmonitorable.
Interruptions and a poorly designed work environment that encourages them. Right outside my cubicle is a BIG OPEN AIR MEETING ROOM with included MEDIA CENTER.
OK, so BIG OPEN AIR MEETING ROOMS are bad. Very bad.
Other bad things:
Speakerphones. Damn things should be destroyed on sight. There is no reason for anyone not in an office to have a speakerphone on their desk. Any "manager" who says developers in cubicle farms need speakerphones should be fired. Don't allow speakerphones on the same *floor* as the development team, except inside of small, well-sound-isolated offices.
Not enough meeting rooms. Encourages people to do what I'm hearing right now, which is stand around between cubes and have loud conversations.
Phones in general. The only people who call me are recruiters or customers who got lost in our phone system and got me by mistake. Which of those 2 groups do you want me to talk to?
Bad climate control. Too hot in the summer, too cold in the winter.
Requirements to be on email or messenger at all times are counterproductive. They let managers feel important, but that's the only benefit they have.
Cell phones with obnoxiously loud ringers left on desks. I tell my team "in your pocket or on silent" is the rule for all cell phones. Anyone in violation of this rule that receives a call returns to their desk to find their phone turned off and the battery removed if possible. If they find their phone at all. I've hidden them in the ceiling before.
Here's a list of the seating assignments I've been given in buildings:
Share a conference room with other developers.
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
I had a similar thing going on with a clueless manager. He wanted an explanation why projects weren't getting completed on time. I suggested I could do one better and show him why. He agreed. I downloaded I think it was a sample SAT math test. Where ever I got it, it was one of those four or five hour timed math tests.
I gave it to my manager and told him it had to be completed that day. And that just a passing score wasn't acceptable. It had to be returned at 100 percent. No exceptions. But the good news, it was open book. When completed, at his discretion, he could go back over any or every answer and double, triple check, use Google or whatever he wanted. But that no matter what, 100% was needed.
I handed it to him and said your time starts now.
Then I continued taking and mentioned the two meetings we had scheduled. I also told him I'd be needing his help later that day solving an issue we had with a project that was also due that day, etc.
I said I'd be back at the end of the day to see how well he did accomplishing his basic minimum job requirements. I wished him good luck
My goal was to convey that programming is like taking a math test. A math test requiring 100% accuracy. A task requiring full, uninterrupted concentration. That checking every answer when finished was equivalent to testing the code. Even if it was similar to taking the 4 hour test several times. But along with that, meetings, telephone interruptions, being pulled off on unrelated tasks were all part of the job.
Did I mention he was a little clueless? By the end of the day he hadn't even started the math test. And yet he never seemed to 'get it'.
-[d]-
I program better when I am in a quiet environment.
I have been amazed how hard it is to get work done in cube farms, especially when there are people nearby whose job it is to talk on the phone often.
A few gigs like that made me invest in these. They work as well as ear plugs but without the inconvenience of roll and stuff them:
http://tinyurl.com/cw33u3x
There is this popular article about research that shows that quiet and solitude boosts productivity, including for developers
http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?pagewanted=all&_r=0
If an org will not pay for real offices they should consider separating people with noisy jobs ( phone use ) from others and make some rules about noise levels
That's not how our meetings go.. more like
...Think tank mode for the group...
Person 1) All is going well, notice this is part is x% slower than expected and their other part is x% faster than expected based on our last discussion
Person 2) Nothing here, all is well
Person 3) I'm stuck on this one part, this is what's going on, this is what I researched, this is how I'm thinking of attacking the problem
Ideas tossed around, move on
Most meetings around here aren't of managers, but of senior developers, architects, and engineers.Some times a manager or two will sit in and listen, but they tend not to say much, but that's more like once per month.
I think the biggest thing is probably "assuming that the same practices are good or bad for everyone". Consider "face time"; this ranges from essential to disruptive depending on the people involved. If you don't make sure that your socially-oriented developers are getting the human contact they need to be engaged, you are crippling them. If you don't keep your non-socially-oriented coworkers free from disruptive enforced socializing, you are crippling them. So if you pick a policy, and use it for everyone, you're likely hurting productivity.
Honestly, though, the biggest thing I've seen, by far? Blame. When I have worked places where there was a focus on identifying fault and trying to punish failure, it meant that the bulk of effort in responding to issues was spent on identifying or avoiding blame. Where I work now, the corporate culture is that we all know we make mistakes (although I like to think I make more of them than anyone else; I have a spectacular track record in that regard), and we also know that in nearly every case, any of several people could have prevented something. If code goes in that breaks something, and I reviewed it, I don't say "oh, there's no way I could have known that would happen", I say "whoops, my bad, I reviewed that one".
And that means that, when something goes wrong, we have the best information we can have about what went wrong and how as soon as possible, and we can focus on fixing it. And "fixing it" doesn't mean "sitting around waiting for the person who screwed up to be around to fix it", it means "best fit of availability and schedule". I will fix mistakes I didn't make, other people fix mistakes I make, and we get stuff done.
I basically laugh when people ask me whether I'm looking for work. :)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
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."