Comment by timbre | Hacker News Reader

Comment by timbre | Hacker News Reader

Parent Full thread

> The second secret is that most teams, frankly, are not that good.

It's so important to remember this, as well as the corollary: I'm not that good myself. The article included this line:

> If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.

I'm not sure if I agree with the statement itself, although I certainly think -- and know no one who doesn't think -- that the quality of your staff is more important than your process. But I'm sure I disagree with the way this statement is used to dismiss the idea of a prescribed process. One of the main goals of such a process is to get as good work as possible out of mediocre staff. Because there aren't enough high quality staff to go around. You won't get great work out of mediocre workers, but if you can get pretty bad work instead of total garbage, in many environments that's a big win. (In the startup environment that is hn's focus, pretty bad might be just as bad as total garbage.)

> I certainly think [...] that the quality of your staff is more important than your process.

I don't think those are independent variables.

In my experience, one of the properties of a good development team is that if a project lacks clear guidelines so the developers can work effectively together, the team will naturally tend to self-organise. They will establish enough ground rules among themselves to collaborate effectively, and they will adopt or create any tools necessary to support that basic process. A good team that does already have a decent process and competent leadership will still naturally review and update that process over time based on their experiences using it.

This also explains why one or two substandard developers on an otherwise competent team are so damaging: they are sufficient to disrupt any reasonable attempt at self-organisation, and the team now requires strong leadership rather than merely collaboration among peers. Unless the leader is capable of both instilling discpline in the rogue elements and simultaneously accepting and promoting good ideas from the remainder of the group, which is a very difficult thing to do even for an experienced manager with good intentions, the result will still be lower performance than a team without the negative elements.

I objected to the same statement but for slightly different reasons. It works when your project is of a size that can be done by a fairly small team that can communicate intimately and instantaneously at all times. We're talking 1 -5 people max. But what happens when there are 30 developers, 50 developers, or 100 developers. Without some overarching system of coordination these people will just be flailing around, constantly treading on each other, breaking each others stuff. Somehow you have to break it down and give people a way to understand what everyone else is doing, and that turns into "process". You can do it any way you like, but what ever you come up with is still going to be that evil word "process".

The problem is that said "process" then gets deployed in a cargo cult manner to any project regardless of size, divisibility, who is managing it working on it, etc.

Reply on news.ycombinator.com