Blood, Sweat, and Tears

Showing a fellow developer how to create JUnit tests for Java code, I came up with a saying. "Refactoring is a whetstone with which you can hone your design skills." Maybe I can come up with another good phrase that includes unit testing.

Being a Codewright is like being a blacksmith. While casting something in iron is relatively straightforward, it also requires much more prior planning. It also assumes that we want to make copies of an existing design. Anything custom means pounding it out by hand the hard way.

With much sweat and toil in the crucible of coding, we put code into the forge of the code review to make it malleable, we use unit tests like an anvil to support our efforts as we bring to bear the hammer of refactoring to shape the code to our will all the while evaluating how much work is needed to achieve the desired design.

So, when you hear your team banging away at the code ask yourself, is the noise they're making that of peices being moved around with fervent hope that "maybe *this* will work!" or are they methodically improving the code through the use of the forge, hammer, and anvil?

Or Else What?

So, I'm about to do some development on a project that will be using IBM's RAD7. In prepration, the developers are going to a RAD7 class. During class the instructor is dutifully showing us all the bells and whistles and he does this:

if ( somecondition)
{
return success;
}
else
{
return failure;
}

I thought I'd exhert some independence and remove the else block:

if ( somecondition )
{
return success;
}

return failure;

My code is equivalent to the previous example but I began to wonder how do you know when the 'else' clause is unnecessary? In simple cases like this one, it can be easy to show that it doesn't matter. Is this a case where we can make things less clear by being more explicit? Consider the example that uses the 'else' block; if another programmer were to come along and wanted to add more code, how easy would it be for them to decide whether to put the new line in the 'else' block or after it?
Could that question indicate that the 'else' statement is part of a code smell? I'm not sure what the smell would be called, I'm not entirely convinced that it is even a smell. What keeps bugging (ha!) me is how similiar it is, at least as a symptom, to why one of our code standards is to require braces everywhere even if they are optional. I might look this up in Scott Meyer's C++ books.

NON-STANDARD:

if ( chaporones_are_gone) drink;
cleanup;

STANDARD:

if ( chaporones_are_gone)
{
drink;
}
cleanup;

The braces are the safety-net to keep the programmer from inadvertantly making changes to code that isn't affected by the 'if'. The compiler will never be a replacement for a thinking human and since humans are fallible, it makes sense to develop habits that keep us from burning ourselves. How can we define a rule to keep us from overusing the 'else' clause? My initial attempt was something like "only use an else if the else block contains another if" but that doesn't really do it. Maybe when the condition includes something like 'Do x unless a=1' but

Let's add an alternative activity, dancing. If you converted the condition into English syntax, you could say "The teenagers will dance or drink depending on whether the chaperones are gone; in any event they'll have to clean up." This says we clean up always and isn't really affected by the condition. There are two exclusive activities mentioned. We never do both. What I notice is that the sentence has two verbs and one object. I'm having flashbacks to sentence diagramming from junior high, not pleasant.

This is related to the discussion about using negative logic in conditions. Yes, the order of the 'then' and 'else' blocks won't matter to the compiler but one way makes it easier for humans to read. Eliezer Yudkowsky discusses this in a Bayesian logic article using the example of why story problems can be so hard for students to understand.

In all the efforts to get programmers to use more powerful tools, maybe we can spare some time to hone our logic skills. However much we'd like expect our tools to do more work for us, there are some things that will always be left to the individual. Computers won't gather requirements for you. Humans can parse the customers requests and know what to take literally or when to use context to help with the interpretation. A sound foundation in the English language can be a powerful tool in the developers toolkit.

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

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.