Avoiding Mistakes Can Be a Huge Mistake 268
theodp writes "No doubt many will nod knowingly as they read Paul Graham's The Other Half of 'Artists Ship', which delves into the downside of procedures developed by Big Companies to protect themselves against mistakes. Because every check you put on your programmers has a cost, Graham warns: 'And just as the greatest danger of being hard to sell to is not that you overpay but that the best suppliers won't even sell to you, the greatest danger of applying too many checks to your programmers is not that you'll make them unproductive, but that good programmers won't even want to work for you.' Sound familiar, anyone?"
Re:Agreed, Too Much Oversight Kills (Score:2, Informative)
Forgot to mention, morale is in the toilet, because after 2 years of effort we're about to release a new, fully standard-compliant version of the application with -0- new features, and even less compatibility with external applications than before.
Most people here have told me the only reason they have not left is because we'd never be able to get the same money or even half the vacation elsewhere.
Re:Death March (Score:2, Informative)
if you use metrics to understand how hard someone is working, then you fail before you have begun.
metrics == management
Unfortunately, there isn't a magic bullet (Score:1, Informative)
The truth about software engineering is that nobody has THE solution. There isn't a true 3 step fills all the buckets and "everything will be fine" approach. Every environment and every procedural approach will (and IMHO should) be different.
There can be similarities between systems but you can't apply the doctrine of a compiled desktop development cycle to embedded development for engine management systems. It's appropriate for the developers of engine management systems to be very careful and just as appropriate for developers of utilitarian desktop software to release early, release often.
What Paul touches on in the article is the real issue. It's about motivating people to do what you need them to do. When somebody works with their mind, motivation is critical. You can force a factory worker to produce x widgets in an hour, but you can't force somebody to think effectively.
It's not necessarily about having the best people, it's about getting the best from the people you have. And I've got the feeling Steve Jobs would agree.
Re:Real Talent? (Score:3, Informative)
No, there really are programmers who are 10x as productive as "normal", and of course programmers who contribute negatively. You'll know either extreme when you work with one.
Boss: we've had a team of 5 on this problem for a couple months now, and they're way behind - could you take a look?
Dev: sure, give me a couple of weeks.
Two weeks later.
Boss: so, can how's that project going?
Dev: oh, I'm done.
Boss: Done? Great - what was your analysis; how can we speed things up?
Dev: No, no, I'm done with the project. The approach that team had was crap, so I just did it right. I'm running my unit test now, but it looks good so far.
Boss: -speechless-
You may not believe it until you work with someone like that, but they're out there (and large companies do a terrible job of retaining them - as Paul Graham suggests, the main thing devs like that want is to not have obstacles to their productivity).
Re:Real Talent? (Score:3, Informative)
I know what "productive" means. Knowing that is part of my job. "Productive" is delivering features in a maintainable, supportable way, per unit time. Sizing features and defining "maintainable" and "supportable" in terms of concrete rules and best practices is a large part of the skillset of a very senior engineer. Finding the hyper-productive programmers and twisting management's arm to retain them at all costs is another.
Again, the 10x developer sounds like a myth until you work with him -- I'd say it's the top 1% -- but 3x developers are common. The "contributes negatively" programmer is someone you've met, though the hallmark of bad management is to encourage that guy to work more.
There's a reason that "real" engineering companies have fellowships and Distinguished Engineer titles to recognize, empower, and retain the top 1% engineers on other fields.
An alternative rendition... (programmers as swarm) (Score:1, Informative)
self-organizing, that is...
http://www.zoion.com/~erlkonig/writings/programmer-beekeeping.html [zoion.com]
Cheers!
-Captain Fairly-Obvious.
Processes galore (Score:3, Informative)
In my previous job, I worked for a huge manufacturing company. I developed, maintained and supported an add-on (plug-in, extension, module, whatever) for their 3D CAD/solid modeling application (Pro/Engineer).
When I first hired on, and started working with the application, I learned about the quality process we used: SPQA, or software process quality assurance. This was relatively straightforward, and, in my opinion, didn't add too much overhead. It was basically a checklist of things that a manager went over with the development group. Then we added AQA, application quality assurance. Not only did this add more overhead, but some of the requirements of the two processes conflicted!
The projects my group worked on were fun, cool, and cutting edge, and the majority of the staff was quite engaged in their work. So we worked through all this process nonsense, and basically got used to it. However, lurking in the background all the while was 6 Sigma. The company had adopted this methodology wholesale, and was forcing it to be used in every facet of operation. Now, not only did we have our previous processes, SPQA and AQA, but we had 6 Sigma to contend with.
Looking back, it's sad how much time and effort was wasted just trying to figure out how to integrate all these processes into our development. Literally, the whole section (about 12--15 people) spent many meetings and countless hours coming up with process maps, just to explain how our development would proceed, and comply with AQA, SPQA, 6 Sigma and anything else management felt like we needed to do. I used to eat lunch with the supervisor of another group---he had actually worked in the same group as me, years ago. I'd be moaning about how much of my effort was spent just trying to juggle all these processes, and he'd say, "Back in my day, we just thought up an idea and coded it." I'd talk about the growing queue of bugfixes and enhancements, and how none of them could ever be realized without eliminating all this process nonsense (or doubling the staff and budget) and he'd smile and say, "I remember when so-and-so called me up, asking if I could make the program do such-and-such, and I did it the same afternoon!" Sigh.