TITLE: Someone Competent to Write Code AUTHOR: Eugene Wallingford DATE: May 22, 2007 3:55 PM DESC: ----- BODY: Students sometimes say to me:
I don't have to be good at <fill in the blank>. I'll be working on a team.
The implication is that the student can be good enough at one something and thus not have to get good at some other part of the discipline. Usually the skill they want to depend is a softer skill, such as communication or analysis, The skill they want to avoid mastering is something they find harder, usually a technical skill and -- all too often -- programming. First, let me stipulate that not everyone master every part of computer science of software development. But this attitude usually makes some big assumptions about whether a company should want to entrust systems analysis or even "just" interacting with clients. I always tell students that many people probably won't want them on their teams if they aren't at least competent at all phases of the job. You don't have to great at <fill in the blank>, or everything, but you do have to be competent. I was reminded of this idea, which I've talked about here at least once before when I ran across Brian Marick quoting an unnamed programmer:
What should teams do with the time they're not spending going too fast? They should invest in one of the four values I want to talk about: skill. As someone who wants to remain anonymous said to me:
I've also been tired for years of software people who seem embarrassed to admit that, at some point in the proceedings, someone competent has to write some damn code.
He's a programmer.
This doesn't preclude specialization. Maybe each team has one someone competent has to write some damn code. But most programmers who have been in the trenches are skeptical of working with teammates who don't understand what it's like to deliver code. Those teammates can make promises to customers that can't be met, and "design system architectures" that are goofy at best and unimplementable at worst. One of the things I like about the agile methods is that they try to keep all of the phases of software development in focus at once, on roughly an even keel. That's not how some people paint Agile when they talk it down, but it is one of the critical features I've always appreciated. And I like how everyone is supposed to be able to contribute in all phases -- not as masters, necessatily, but as competent members of the team. This is one of the ideas that Brian addresses in the linked-to article, which talks about the challenge facing proponents of so-called agile software development in an age when execution is more important than adoption. As always, Brian writes a compelling story. Read it. And if you aren't already following his blog in its new location, you should be. -----