Stories about Software


High Stakes Programming by Coincidence

Editorial note: I originally wrote this post for the Infragistics blog.  Click here and check out the original at their site.  There are a number of authors worth checking out that write for them.

Have you ever found yourself running your code to test out some behavior when you noticed something unrelated and thought, “that’s odd?”  Maybe you wanted to verify that clicking “run” kicked off the process it was supposed to, but you noticed that the “cancel” button was randomly green for a second when the window opened.  “That’s odd,” you thought.

After verifying that the process was kicked off properly, maybe you re-launch the application to see about that odd, green cancel button.  But when you open the window this time, nothing.  It’s the normal color, with no sign of the green you noticed before.  Again, you thought, “that’s odd.”  And maybe, at that point, you shrugged, chalked it up to some weird OS rendering burp, and moved on.


You never knew why the button went green, and you never knew why you couldn’t reproduce it.  This is a relatively benign version of the phenomenon known as “programming by coincidence.”

“Programming by coincidence” was coined in the book, “The Pragmatic Programmer,” and they define it as “[relying] on luck and accidental successes” rather than programming deliberately.  In the case of the mysteriously green button, the accidental success is the fact that the problem just kind of vanished on its own.

It’s probably no great surprise that the Pragmatic Programmer’s stance on programming by coincidence is “don’t do it.”  It’s my stance as well, and I imagine a lot of you reading agree.  And yet, it’s something we’ve probably all been guilty of at one time or another. Read More


Is Programming Art?

Don’t look now, but I’m pretty sure this makes three weeks in a row of doing at least 1 reader question per week.  Today, I’m going to tackle a question I received: is programming art?  Here is the actual text of the question.  It’s a well-written consideration that cites two parallels: painting and writing.

This article asks if computer [scientists] apply scientific methods, but perhaps we should reconsider the premise, is computer science even a science at all? I contend that a software engineer has more in common with an artist than a physicist. If a painter applied scientific principals and determined that the most pleasing color is purple and the most pleasing subject matter is a tulip, then all artists would paint nothing but purple tulips, which would not be pleasing at all.

Lets compare the developer to another type of artist, the writer. Whether you’re writing the great American novel or assembly instructions for a book shelf, or anything in between, you must consider questions like what tone of voice should I use, how formal should it be, how long should each chapter be, etc. There is never a single, scientific answer to those questions any more that there is to questions like how long should a method be, how descriptive does a local variable name need to be, etc.

To answer these questions, any writer or developer must consider the target audience. The great American novel will be written in a much different tone than a book to teach children how to read. The audience for your code is not the user (that’s the audience for the UI). The audience is the CPU, but much more so, its the next developer who needs to edit your code, or even a future you.

Bear in mind that this was written against the backdrop of this post that I wrote back in the fall, in which I answered a reader question about whether what programmers do is scientific (as in the “computer science” that we learn).  Thus the sentiment here seems to be, “I think maybe what we do is better compared to art than experimental science.”

Fair enough.

What Is Art?

But before going further, I’d like to level set a bit with the actual definition of art.  If I go the classic, find a dictionary definition route, I get an adorably Lieutenant Data-like answer.

1. the quality, production, expression, or realm, according to aesthetic principles, of what is beautiful, appealing, or of more than ordinary significance.
2. the class of objects subject to aesthetic criteria; works of art collectively, as paintings, sculptures, or drawings: a museum of art;
an art collection.

If I go look for any number of essays on the topic, two main themes emerge.  The first is some rallying around the “it’s hard to define, but maybe it’s like the obscenity case in that I know it when I see it.”  I think this line of reasoning is intended as inoculation against the philistine in the art museum saying, “throwing paint at a canvas ain’t art — I coulda done that!”  That one isn’t particularly interesting for our purposes here, which brings me to the second theme: aesthetics.


Read More


Modularity on My Honeymoon

If you hadn’t noticed, I’ve been gone for the last couple of weeks.  I got married and went on a honeymoon and left the blog on auto-pilot, with scheduled cross posts of things I’d written for other blogs.  I figured this was better than providing no content and hopefully the posts and social media announcements synced up closely enough that I didn’t look ridiculous.

During the trip, I didn’t think a whole lot about software, per se, but I gave occasional thought to what I might say upon my return.  I think really good bloggers make cool segues out of trips and experiences.  You know, like  “I was gazing up at the Eiffel Tower and I couldn’t help but think of Liskov’s Substitution Principle.”  I’m not that good, so I didn’t come up with anything like that.  I was in France and Monte Carlo, and I ate a lot of cheese, saw a lot of sites, drank a lot of wine and spent a lot of time reading.  None of that reminded me of code or software, really.

An Idiot (Me) Abroad

In fact, the only technical lessons I could relate were birthed from my own stupidity.  I brought my Mac Book pro along, but, incredibly, managed to forget its charger.  Upon arrival at our hotel in Paris, jet lagged, I dug the laptop out of the bag to charge and discovered that this would be quite impossible.  Suddenly, the Mac’s 90% charge was an ominous harbinger of computing scarcity.  I’d have to ration, what, like 3 or 4 hours of latpop usage for the entire trip? Read More


Code Kata? How About Product Kata?

When I was a kid, I spent a bunch of years doing karate. As best I can recall, there were three main types of activities around which we’d focus: kihon, kata, and kumite.  I listed these roughly in order of sophistication.

  • Kihon translates to something like “basics” and it involved executing the same punches, blocks, or kicks repeatedly, going for correct technique.
  • Kata was something like “form” and this involved stringing together moves into more complex sequences and practicing those, presumably to emphasize rote practice of sequential movements.
  • Kumite was sparring, and this was meant to be in-situ, improvisational practice, using the first two activities as building blocks.

There’s a lot of spiritual type stuff that goes on around martial arts, and it’s not my intention to rag on that in any way. You get out of things what you put into them and you find value that makes sense to you.

But, at its core, these activities are really all about learning how to punch and kick other people and win fights. So you practice the basics, string those together into sequential movements and then have dress rehearsal sparring matches.

This is all done so that when the time comes to actually punch and kick people in real life, you’re good at it. You don’t flinch when someone throws a punch because your countless hours of practice have made stepping into the blow, deflecting it and countering as second nature to you as cringing and protecting the head are for most people.

Learning to Punch People with Our Code

When I first heard of the martial arts concept of “kata” being applied to software development, I found it sort of interesting and weird. There’s intense marketing power in appropriation of this nature, and it can really make a concept take off.

And, there are parallels between the two beyond the simple notion that deliberate practice improves technique. One of the main benefits to code katas is the practice of techniques like refactoring, TDD, etc. when the pressure is off.

When in coaching/mentoring roles, it’s pretty common to see people try new techniques, only to abandon them when delivery pressure is perceived. To have “stickiness” for a software development technique, it’s essential that it hit a tipping point where the practitioner finds it less efficient to skip it than to do it. And doing a lot of code katas is a way to work toward that tipping point.


Of course, as with any cross-disciplinary metaphor, there are gaps and those gaps can be problematic. Again, putting aside the spiritual overtones, karate is about learning to punch and kick people effectively. This is pursuit heavy on instinct and muscle memory and relatively light on cerebral cortex activity.

A fight also spans seconds or, at most, minutes, where programming is a pursuit of hours, days, weeks, months, or years. I believe it was this sort of information gap that led John Sonmez to post about code katas. He heard the term “code kata” and mapped the martial art version onto it — one where you practice precisely executing the exact same movements until you can do them in your sleep.

That’s not the intent of the code kata, but recall that we’ve been over what happens when you recycle terms with baggage for marketing purposes.

Read More


Delegating is Not Just for Managers

I remember most the tiredness that would come and stick around through the next day. After late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle. After late nights of futility, it was a taunting adversary that wouldn’t go away. But whatever came, there was always tiredness.

I have a personality quirk that probably explains whatever success I’ve enjoyed as well as my frequent tiredness. I am a relentless DIY-er and inveterate tinkerer. In my life I’ve figured out and become serviceable at things ranging from home improvement to cooking to technology. This relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career. On a long timeline, I’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.


And so, throughout my career, I’ve labored on things long after I should have gone to bed. I’ve gotten 3 hours of sleep because I refused to go to bed before hacking some Linux driver to work with a wireless networking USB dongle that I had. I’ve stayed up late doing passion projects, tracking down bugs, and everything in between. And wheels, oh, how I’ve re-invented them. It’s not so much that I suffered from “Not Invented Here” syndrome, but that I wanted the practice, satisfaction, and knowledge that accompanied doing it myself. I did these things for the same reason that I learned to cook or fix things around the house: I could pay someone else, but why do that when I’m sure I could figure it out myself?

Read More