Stories about Software


Please Stop “Geeking Out”

Mostly, I try to stay away from semantic quibbling and I almost always try to stay away from anything sensational, so please forgive me in advance.  I’m taking a hard line of sorts with a blog post entitled, “stop geeking out.” and I’m somewhat doing so for effect.  But this is coming from a place of earnestness.

I don’t really care too much about the term “geek” in and of itself; it’s the concept of “geeking out” that frustrates me.  And it truly is the concept — I’m not interested in term policing.  It’s not like I’d blow a gasket and be insufferable toward someone saying this in front of me; rather saying it in front of me inspires sort of a vague sadness in me, upon which I wouldn’t bother to comment.

But before I get to the reasons for my objection and my sadness, let’s take a look at the origins of the term “geek” as we know it today, originating from the idea of a “geek show.

The Online Etymology Dictionary give the following for “geek”: “sideshow freak,” 1916, U.S. carnival and circus slang, perhaps a variant of geck “a fool, dupe, simpleton” (1510s), apparently from Low Ger. geck, from an imitative verb found in North Sea Germanic and Scandinavian meaning “to croak, cackle,” and also “to mock, cheat.” The modern form and the popular use with reference to circus sideshow “wild men” is from 1946, in William Lindsay Gresham‘s novel Nightmare Alley (made into a film in 1947 starring Tyrone Power).

The billed performer’s act consisted of a single geek, who stood in center ring to chase live chickens. It ended with the performer biting the chickens’ heads off and swallowing them.[1] The geek shows were often used as openers for what are commonly known as freak shows. It was a matter of pride among circus and carnival professionals not to have traveled with a troupe that included geeks. Geeks were sometimes alcoholics or drug addicts, and could be paid with liquor – especially during Prohibition – or with narcotics.

Okay, so quick recap.  Before the term meant “technology enthusiast” it meant, “idiot substance-abuser that earns a living performing unspeakable acts to amuse mobs.”  That’s quite the transition!


The Historical Connection

Let’s examine that transition a bit.  When I was a kid in the 1980s, I remember “geek” being an insult, but it was sort of interchangeable among a bevvy of insulting synonyms: dork, dweeb, nerd, etc.  You can go looking for meaning in a taxonomy if you’re so inclined, but I don’t remember much distinction.

But, as I’d learn later, “geek” had a special and unique flavor of implication.  It conveyed obsession and interest in technology.  Interesting.  But how do you get from “slow-witted alcoholic that will eat chicken heads for free booze” to “guy that really, really likes computers?”

Read More


That Code’s Not Dead — It Went To a Farm Upstate… And You’re Paying For It

Editorial Note: I originally wrote this post for the NDepend blog.  Head over there and check out the original, if you’re so inclined.  I encourage you to go give the NDepend blog a read, in general.

When it comes to pets, there’s a heartbreaking lie that parents often tell little children when they believe that those children are not yet ready to wrap their heads around the concept of death.  “Rex went to a nice farm in the countryside where he can run and play with all of the other animals all day!”  In this fantasy, Rex the dog isn’t dead — he lives on in perpetuity.


Memoirs of a Dead Method

In the source code of  an application, you can witness a similar lie, but in the other direction.  Code lives on indefinitely, actively participating in the fate of an application, and yet we call it “dead.”  I know this because I’ve lived it.  Let me explain.

You see, I’m a method in a codebase — probably one that would be familiar to you.  My name is GetCustomerById(int id) and I hail from a class called CustomerDaoMySqlImpl that implements the interface ICustomerDao.

I was born into this world during a time of both promise and tumult — a time when the application architects were not sure whether the application would be using SQL Server or MySQL.  To hedge their bets, they mandated data access interfaces and had developers do a bit of prototyping with both tools.  And so I came into this world, my destiny taking a single integer and using MySQL to turn that integer into a customer.

I was well suited to this task.  My code was small, focused, and compact, and I performed ably even to the point of gracefully handling exceptions in the unlikely even that such would occur.  In the early days life was good.  I fetched customers on development machines from unit tests and from application code, and I starred for a time on the staging server.

But then my life was cut tragically short — I was ‘killed.’  The application architects proclaimed that, from this day forward, SQL Server was the database of choice for the team.  Of course, neither my parent class nor any of the methods in it were actually removed from the codebase.  We were left hanging around, “just in case,” but still, we were dead.  CustomerDaoMySqlImpl was instantiated only in the unit test suite and never in the application source code.  We would never shine in staging again, let alone production.  My days of gamely turning integers into customers with the help of a MySQL driver were over.

Read More


Be Careful with Software Metaphors

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original post here, at their site.  Head on over and check out that post and others as well.

Over the years, there have been any number of popular metaphors that help people radically misunderstand the realities of software development.  Probably the most famous and persistent one is the idea that making software is similar to building a skyscraper (or to building construction in general).

This led us, as an industry, to approach software by starting with a knowledge worker “architect” who would draw grand schematics to plot every last detail of the software construction.  This was done so that the manual laborers (junior developers) tasked with actual construction could just do repetitive tasks by rote, deferring to a foreman (team lead) should the need for serious thinking arise.  It was important to lay a good foundation with database and framework selection, because once you started there could be no turning back.  Ever.  Should even minor plan changes arise during the course of the project, that would mean a change request, delaying delivery by months.

Software is just like construction, provided you’re terrible at building software.

This metaphor is so prevalent that it transcended conscious thought and crept its way into our subconscious, as evidenced by the “architect” title.  Given the prevalence of agile (or at least iterative) software development, I think you’d be hard pressed to find people that still thought software construction was a great model for building software.  I don’t think you see a lot of thinly sliced buildings, starting with an operational kitchen only and building out from there.

But there are other, more subtle, parallels that pervade the industry and lead to misunderstandings between “the business,” managers, and software developers.


Read More


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