Fred Brooks meets Mozart

For some reason, as I started to read this blog entry I thought that a better analogy would be that writing software is like writing music for hire.

Music has well established connections with mathematics. That doesn't mean I'm going to hold my breath waiting for my computer to compose 'The Magic Flute'.

I started to describe the idea to my friend Craig and the more I talked the more apt the comparison became. It's partly ephemeral yet can be reproduced in the real world and its acceptance is controlled by someone other than the writer.

It also depends on those who perform the instructions. Maybe coding is like writing a symphony. You can write as grandly as Bach or Mozart but if the players are terrible, so will the performance. The same goes for good players using poor instruments, or good players using good instruments but having a poor conductor, or having all the players and conductor as first rate but the audience is completely tone-deaf.

Maybe we have Code-Cowboys instead of Virtuosos or Divas.

Ok, instead of a symphony, it would be an opera. In addition to the symphony (for the music) you have a company of actors with which to contend.

My friend Craig chimes in with: and a director

Now you're getting it.

Think about estimating how long it would take to put on a production of an opera that had never been done?

The estimate would be pretty worthless because it depends on how long it takes to do the casting, figure the lighting, blocking the scenes, creating the scenery and all that is dependent upon the budget.

Craig:Yes - building the stage is like erecting the infrastructure for a platform not currently used. You have to set up sound, seating, temperature, etc

Talented individuals can create great performances, they can make it seem effortless. We even have terms for these people in the arts. An singer can be a 'diva' and a musician can be a 'virtuoso'. When we limit the scope to the talent of a single individual we can get good material but what marks transcendent art is when the creator inspires the performer using the sheer force of ideas alone.


Music expresses that which cannot be said and on which it is impossible to be silent. ~Victor Hugo

Can this be the equivalent driving force behind the open source movement? There is an idea that needs expressed, the code, compiler, and CPU serving as the artist's paints, brushes and canvas. The Software Craftsmanship movement has much in common with the artistic temperament.

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).