Technology is a Harsh Mistress

Technology is a harsh mistress; a modern-day Athena bestowing miraculous improvements and silver bullets with one hand while sowing complexity and chaos with the other. The line of the hopeful souls waiting to receive their next gift stretches back out of sight. You notice the nasty wounds poorly bandaged and the disconcerting gait. When you ask about their plight the barely-coherent reply is, "It's not as bad as it looks. It isn't as bad as the time before last. Next time it will work, I just know it!" and then they shuffle forward as if you weren't there.

The first time I heard the rant on technology not being a silver bullet was over C++ and Object Oriented Programming. While that just shows my age, has anything really changed? These days, XML is all the rage. While XML/XSLT and so forth are not silver bullets, they do provide a common language for describing data. What they do not address is the disparate ways in which data is used. It does not help companies agree on a data model to use to trade data back and forth between themselves. It does not help communicate existing standards to those poor souls tasked with converting a legacy system's data feed being sent to a more modern system. It does not help when other protocols are thrown into the mix, like messaging or business services, at a dizzying pace.

Don't get me wrong, XML, XSD, XSLT, etc., they all have their place. I'm not suggesting we discard our new toys. The question we have to ask ourselves is 'What problem do they solve?' Usually, it's that we hope to be released from the tyranny of change. We can add fields to our hearts content, as long as they are marked as optional and we updated the schema. We can leave out fields -- again, optional ones. We can change tag names, as long as it's ok with the schema. Oh, and did I mention that your partners in communication need to know about all of this? You did remember to update the version number in the XSD, right? Anyone noticed a pattern here? We've traded parsing fixed-length records in a flat file for parsing document object models in never-ending data streams.

What is that weight you still feel on your shoulders? It's the weight of responsibility for your data. We've had the responsibility of managing change thrust upon ourselves. Without understanding your data, communicating with others is an exercise in futility, like a truck with its wheels stuck in the mud on a rain-soaked road in the middle of nowhere. Both sides have to understand and agree on both the data model and the terminology regardless of the tools used to describe them. That's all XML and the rest of the alphabet-soup are, tools. Gifts from the Technology fairy.

So, while you're gazing at your latest gift from Technology, ponder whether you received a silver bullet or a seed of chaos. The first can make life seem like a fondly recalled warm summer day with no worries or rush, the second can make life seem like being dropped into a steaming cauldron of blistering misery. It matters not to her, she'll never run short of supplicants hoping for a silver bullet.

The Codewright Mentality revisited

In my last post about the Codewright Mentality I had some fun at the expense of consultants. When my friend Paul, whom I met while he was a consultant, pointed out my over-generalized stereotyping of consultants, I felt that I needed to clarify my point. Being a consultant does not imply lacking drive to improve. I was going for humor but instead stepped on some toes. Don't get me wrong, if there are toes that need stepped-on I'm all for it, but this time he had me dead-to-rights.

Maybe I should have said contractors instead of consultants but that would have traded one set of toes for another. The truth is nobody has a monopoly on the lack of drive; this means contractors; as well as consultants; as well as full-time employees. I'm not sure there is a consistently used differentiation between consulting and contracting. The behavior in question is, for contractors they either did what we asked but no more or for consultants they gave us the answer to our question but no more. You would hope that if there was a better way to do something or a better question to ask, the contractor / consultant would mention it. Both assume the client being open-minded enough to listen. What we're describing is being optimistic about the intentions of those involved.

Paul's observation:

I also have noticed a tendency to blur the distinction between a consultant and a contractor in the IT world. I tend to perceive "contractors" as being hired for very specific skills (C++, Oracle, whatever) and as being mostly just complements to a team, rather than a facilitator/leader. The "contractee" often doesn't make the distinction because "consultants" are, like "contractors", just "not full time employees but being paid by us, directly or indirectly". Doesn't much matter, I suppose, so long as both parties agree on expectations.

I give Paul a lot of credit for helping me start thinking about programming as a craft and worthy of study in it's own right.

Here is what Paul had to say about what it means to be a Codewright:

For me, codewright-ship is...

• About not settling for intention-obscuring code
• About not settling for inarticulate requirements
• About seeking out other codewrights to learn from
• About seeking out codewright apprentices to teach
• About not settling for code without tests
• About believing there is something noble about programming
• About tuning out the voices of developers past who want you to think that coding is monkey business, or that quality is the testers' job, or that you have to figure it all out ahead of time before you write even one line of code.
  
• About realizing that simplicity is beautiful; and that the simplest things that could possibly work probably isn't the first thing you think of.
• About building systems people are passionate about using.
• About realizing that developing such software is difficult-- that maybe it shouldn't be easy -- that maybe gains in software productivity needn't or can't keep pace with such gains in hardware performance
• About creating sustainable solutions -- software that future maintenance programmers don't mind maintaining (as opposed to the mind-bogglingly putrid legacy code much software is).

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?