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?"
fix it later (Score:5, Interesting)
Stuff that makes a developer wait. (Score:5, Interesting)
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).
42 (Score:5, Interesting)
TFS (Score:2, Interesting)
Too Much Documentation (Score:5, Interesting)
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.
Lack of flexibility; misaligned communication (Score:5, Interesting)
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.
Re:The Number One Impediment is MEETINGS (Score:5, Interesting)
Right now I'd say that Scrum is the biggest source of unnecessary meetings in this industry. I think the principles of agile development are great, but Scrum is a bad way to do it.
Weekly planning meetings, demos, retrospectives, and worst of all: daily standups at a rigid morning time. Not good for night owl engineers who want to sleep in or for early birds who get to work too soon before the meeting because it introduces a big context switch.
Instead of all these meetings, why aren't there more companies that just solve their accountability problems with tooling? My solution: Git + Bugzilla eliminates the need for all these meetings except the occasional demo.
Here's how:
Want to put a feature on the release calendar? File a bug. Want to prioritize features/bugs for an upcoming release? Fiddle with the bug priorities. Need input from an engineer about whether or not the priorities make sense based on dependencies? Meet with one or two senior engineers privately just on that topic. There goes all those massive planning meetings.
Want to know what someone is working on? Make all developers work in their own git branches. Ask developers to name their branches after the bug number they're working on. Ask the developer to commit their code daily, whether it's finished or not. That way anyone can check on their progress. When the developer finishes his task, merge the branch into master and close the bug. There goes all those redundant daily standups.
Institutionalized Waterfall (Score:4, Interesting)
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.
Re:Easy answer; (Score:5, Interesting)
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.
Re:Another Big Impediment (Score:4, Interesting)
as our policy is to not promote changes to anything that 'already works.'
If this policy is in place, it's because management doesn't trust you. You need to do some introspection, is there a reason they don't trust you? Are you capable of making those changes without adding new bugs and causing problems? If then answer is no, then there's a good reason they don't trust you.
If you are capable of making changes, then you can train them. Start by making small changes and not adding bugs. After a while you'll be able to convince them to let you make bigger changes, because there haven't been any horrific bugs that have gotten through in a while, and they'll forget why that policy existed in the first place.
The most stupid company (Score:5, Interesting)
Re:fix it later (Score:3, Interesting)
Many deadlines are not artificial but are imposed by the physical world you live in. Crops are sown and harvested on nature's deadline, you don't do it right you can lose your farming business.
Airlines and all other shipping businesses have deadlines, mining operations have deadlines, retail has deadlines, etc.etc. These are often tied to natural seasons but also to fiscal seasons, to interest payments, to loan terms renegotiations, business deal renegotiations, etc.
To you many things may seem arbitrary because you are looking at it from your limited perspective. Businesses actually have reasons for deadlines, many of those reasons are market oriented, you have to try and bring a product to market first and it does not mean it's just a caprice, it may have to do with business deals that are made across board with others and they have their deadlines, etc. Business agreements are also not made in vacuum, there are limitations on how long a factory can stay open for example if there are no orders coming in if there is no credit available, etc.
The problem may be that there are too many promises made and not enough resources allocated, that's a different story, but often deadlines are more than what you think they are.
Re:The Number One Impediment is MEETINGS (Score:5, Interesting)
But the money part is, charge the meetings to another department. When finance calls for a meeting to check on progress, bill back the time spend preparing for and attending the meeting to finance. When they see $10,000 hit their budget for a one hour meeting, they'll never call another meeting. If they are all internal IT meetings, then the "fix" is to replace the CIO/director/manager, so you live with it.
Math Test (Score:5, Interesting)
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]-
Re:Bad meetings? (Score:4, Interesting)
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.
Boy, where to start... (Score:5, Interesting)
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. :)