skip to main | skip to sidebar

Wednesday, November 21, 2007

Cherryh's Law

C. J. Cherryh is a popular science fiction author who has a law that she applies to writing.

Cherryh's Law: No rule should be followed over a cliff.

I think this has abundant applications in programming as well. Another (less catchy) way of stating this is that the rules must match your context and constraints. Some areas where this applies follow:

1. Software methodology

There are software methodology zealots out there. They demand absolute adherence to their doctrines, regardless of projects size or timelines and I have trouble buying into this. I don't believe in one size fits all. There are a lot of practices that I advocate but I allow them to be flexible based on context and constraints.

I believe in design reviews, code reviews and unit testing but the level to which these are done will vary from project to project. Tight deadlines and few resources do not allow for strict adherence to these policies. It always comes down to the time-cost-quality triangle, given any two the third is decided for you. In some cases critical sections of code will receive focus where less critical ones will not. Aircraft flight systems programmers will have much different context and constraints than a business rapid application developer (like me) and in a context where lives are on the line I would expect 100% adherence to such policies and a CMM level 5 organization.

2. Project management methodology

There is a saying I once heard "A large company is not a big small company"; meaning that as your company grows you cannot continue managing things the same way because all the rules change as paradigms shift. In the corporate world this is a unidirectional concept but applying this to project management I would say that "A large project is not a big small project and a small project is not a little large project". Trying to use the same methodology on both will not work well. You must tailor your process to your context. You cannot manage rapid application development the same way you manage space shuttle software development. It always comes back to our old buddy ROI. There should not be 100 pages of documentation and charts for 20 pages of code.

3. General Policies

I received a bug on a website not long ago because it restricted length of an email address field to 35 characters and a client had a user who's email address was 40 characters long(I counted). This was because their naming convention was FirstName.LastName@Company-Something.com and the user’s first Name and Last name were both around 15 characters long. It's quite likely this user will have trouble in other places with this email address. Our site was changed to accept 50 characters, but perhaps we should have accepted 130 characters just incase someone has the following email address:


I.am.blindly.following.a.naming.convention.despite.the.fact.that.it. makes.the.email.address.absurdly.long@rediculous.IT.rules.com