Search This Blog


Wednesday, May 7, 2008

It's Up to the Management to Prevent Poor Programming

There are some discussions on the net on the weakness of Collective Code Ownership. One of the purported weakness of this Collective Code Ownership is that it is possible for the bad programming to hide itself.

I agree that Collective Code Ownership is not able to expose poor programming, but then, there is no way to expose poor programming at all. Unless, of course, the management can review the code written and have the knowledge to tell good code from bad code.

But the IT management normally won't have the time, or the ability to conduct code review. The management, well, have to do lots of managerial stuffs. And reading code isn't exactly fun. Which is why we have code peer-review, in which you have your own fellow developers who review your code and you review theirs. It's kind of self-checking mechanism here.

In the process of code review, defects will be fixed, and the slower developers can learn a few things from the good developers. Sure, the good developers can get frustrated with the poor code, but at least they get a chance to fix the code base sooner rather than later, when the slower developers leave. The important points of code review are that
  1. Defects get fixed sooner
  2. Poor developers have mentors
Elevating code review to an extreme, we have pair programming and collective code ownership.

Well, it is entirely possible that the management doesn't know the performance of both Bob The Poor and Gwen the Great. But this is not so much of Collective Code Ownership's problem. Rather, it's management problem because telling a good developer from a bad one is always a management problem.

The management will not know that bad developers are a drag on a team, regardless of whether the team practices pair programming or not, unless it is actively listening to the developers and the developers have the gut to tell the management the truth and the management has the wisdom to tell who is a good developer and who's not in the first place.

This is a hard task for management, especially for the management who are not good software developers themselves. But still, blaming management's inadequacy on an agile practice is not exactly fair.


Greg Pritchard said...

I agree. Ensuring developed code meets sufficient standards is always management's problem. Management's role is in defining the quality standards, in collaboration with senior developers, and enforcing adherence to those standards. Management may not have the direct skills to evaluate good vs bad code; but it is management's responsibility for putting in a framework (regardless of the employed development methodology) that can identify and rectify the sources of bad code as it occurs.

Rob said...

"Elevating code review to an extreme, we have pair programming and collective code ownership."

Not correct. Code review should be carried out by someone not involved in the original construction. If you're using pair programming then you need a third person (or second pair) to do the code review, otherwise those little "groupthink" errors where the original pair convinced themselves and each other that their code was "correct" while they were writing it will sneak through.

That's not to say that their aren't benefits to pair programming (personally I don't think they necessarily outweight the costs, but YMMV), but removing the need for a code review is not one of them.

rob said...

"that their aren't"

Ugh! That should have been "that there aren't", of course.