Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Question everything

Question everything.

Question the answers you get, but more importantly question the questions you are asking. Learn, unlearn, relearn, repeat. Object oriented programming is tied to fast processing, as is the process of refactoring into well named concise procedures, but there was a time (and likely still is in some real-time programming environments) when huge procedures were common because every procedure call was a notable performance hit and object instantiation was considered a resouce hog. If all current constraints were thrown out the window what would the best programming model be? The ideas that I currently advocate are all at least 10 years old and moving mainstream.

On my radar now are Aspect Oriented Programming and Domain Oriented Programming. I plan to delve into them some more to get a better understanding. I wonder if these will take root and what others am I missing.

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

Dirty code? Clean it up! Refactor!

Coding is a subjective science. I'm sure most of you have written code under pressure that just didn't feel quite right or perhaps had a design evolve under new requirements and realized the design was less than ideal. Some have spoken of code smells. I've always thought of code in terms of dirty and clean. When critiquing others I tend to refer to code and design as either 'feeling clean' or 'not feeling clean' as it is a little more politic.

Dirty code in an application is like a baby with a dirty diaper:

  1. You know its time for a change.
  2. If you put it off too long you'll have a big mess on your hands.
  3. Eventually there'll be more changes needed.

The answer to dirty code is refactoring, which is the process of changing code to improve readablility or structure without changing its functionality. Automated tools may be available to help with some refactoring depending on your development environment. A good introductory resource for best practices, including refactoring is Code Complete 2 by Steve McConnell. For an in-depth look at the topic I recommend Refactoring by Martin Fowler.