The Codewright Mentality

If someone asks you, "What is a Codewright?" how would you answer? You could provide something out of a dictionary, "A Codewright is someone who does x, y, and z" but would you be prepared for the next question, "What if they do a, b, or c"? While coming up with a definition for a Codewright is not impossible, it must take into account those people who have the Pakled-like tendency to want simple answers to complex questions.

Is it possible that a set of questions would be more useful in our attempt to explain the Codewright mentality? I propose that we start collecting a set of questions that help us identify candidates while not rigidly being definitive. This would keep the poseurs at bay. In all fields, there are those who can talk the talk enough to get chosen to do the work but have no real desire to know what it takes to do a good job or even the desire to improve themselves. We call these people "Consultants".

The desire to do a good job would seem to be related to what we call customer service. I recently read an article about Fog Creek's attempts to provide good customer service. For those who study business, Fog Creek's approach sounds not too far off from a well-known discount airline. I submit that the desire to provide good customer service is not only an attribute of a successful business but of a Codewright as well. It is entirely possible that the traits that make-up a Codewright are shared by many of the top-performing individuals regardless of their field. Someone who desires to do a good job and is driven to continuously improve by learning from their mistakes will find themselves near the top of the heap eventually; passing those who found a comfortable niche and live by the motto of "it's always worked for me before". If all it took to be a successful airline was to fly 737s, have goofy ads, and hire cheerful flight attendants, the low-fare airline serving as our model would have much more competition than it does. It would need nice if all it took to be a Codewright in the software world was to subscribe to the language-dujour (Java these days), be fluent in UML, and exhibit a pollyanna-like belief in the latest methodologies like Extreme Programming, Agile, Scrum, etc. If it were that easy we'd be producing systems of such quality and timeliness that questions like "Why is software development so hard" or "What's wrong with Software?" would be a fading memory.

So, one attribute of a Codewright is the desire and drive to provide remarkable customer service. Desire is not enough. Everyone desires to be in good shape but if all you ever do is say that you need to visit the gym 5-times a week, you'll eventually rationalize with yourself, "I'm in shape - round is a shape!" Having the drive without the desire is more like the demanding parent who relive their childhood vicariously through their children.

One criteria down, umpteen to go. Any suggestions?

Trust In Thee

I subscribe to a blog about coding whose audience seems to be .NET developers. I keep asking myself why I keep it in my list of feeds. The answer comes in posts like this one where they discuss what to do when a design surpasses the ability of the coders that maintain the application. It's an age-old problem that has been around since programming began and will be alive and kicking far longer than you or I.

I'd say there are at least two flavors of this. There is the code written by the Code Cowboy who feels that if you can't read his code then tough luck. I actually ran across an example of this where the said coder left a warning in the comment for the afflicted function. To paraphrase it said "Warning, really nasty code ahead. Don't touch anything you don't understand. Don't say you weren't warned." This essentially expresses the opinion "If it was hard to write, it should be hard to read."

The second is a bit more thoughtful. For those applications that are big enough and have been around long enough to need a good size maintenance team, it's possible for some design retro-fits to outstrip the capabilities of some of the support staff. While it is true that it might indicate that the design is too complex, more often than not the design expects developers to understand some nuance of the language. Virtual destructors anybody? How about multiple inheritance? Run-time-typing? It would be one thing if the issue was design complexity. It's quite another to declare that you don't trust the support staff to understand the platform for which they are responsible.

What would drive a Codewright to lower their expectations of their fellow coders? To answer that, ask yourself this question, how many times have you seen a poorly thought out bug-fix or enhancement that not only made the code messier but where a more seamless solution was in plain view and it is obvious that the code monkey that did it actually did more work and the code ended up more brittle than before? Seeing, time after time, well-designed code mangled by some fix where a simpler and easier-to-support solution was visible can destroy the resolve. Why code to high standards when you can expect your well thought out code change to be treated like newspaper lining a bird-cage by the next code monkey to get hold of it?

When it is so easy for mediocre programmers to find work and companies are so willing to hire with an eye to quantity instead of quality, hope becomes a rare jewel spoken of in whispers. Despair sets in and you reach for the opium of conformance.

Have Design, Will Travel

In the article I've linked to, the author discusses how we need to change our understanding of design. For some reason we tend to make our disagreements into horse races or battles where we arbitrarily define sides and then feel compelled to identify ourselves with one side over the other. This restricts our perspective and encourges irrational arguments. "Waterfall sucks, Iterative is the way to go" or "XP doesn't work in the real world that's why I do Agile".

The duty of a Codewright is to understand the pros and cons of the tools and techniques available to him and choose the right one for the job at hand. To do otherwise is to blindly follow in the footsteps of those who have gone before us. The sense of security we may get from knowing that our trail-blazers made it to the end of the road and so will we, won't help us when we realize that they took the hardest and longest route over the mountain instead of going around it and we've just signed up for the same thing.