Stories about Software


Building Superior Code … Is It Achievable?

Editorial Note: this post was originally written for the SmartBear blog.  You can read the original here, on their site.  As I’ve mentioned before, they have some good authors that I respect writing over there, so give it a look!

I’ve made stops in a lot of software development shops in my career, both as an employee and as a consultant. This has afforded me to the opportunity to learn that some questions and concerns are universal in the industry. One such question, asked by Fortune 500 CTOs and tiny startups alike, is “How do I make sure we have good code?” If that seems like it’d be hard to answer, rest assured that it definitely is. As much collective practice as the world has writing software, we’ve not managed to agree on the answer to a deceptively difficult question: what is good code?

David Starr wrote about this topic some time back in an excellent article entitled “Defining Code Quality.” It’s hard to opine about how a software group can have and maintain superior code quality when, as David points out, it’s difficult even to reach consensus on what it means to have superior code quality. So let’s talk about that first.


Read More


If You Promote Bad People, You Promote Bad Culture

Most of my cynicism toward the corporate world is safely directed into my new book these days, so there’s not a ton of spillage onto the blog.  But I’m going to make an exception today and talk about corporate culture.  To understand some of the terms I’m about to use, you can buy the book, if you’re so inclined, but you can also see an original definition here in this post.

I originally intended for my notes on this topic to make it into the book, but one of the main uplifting themes of the book is that I see programmers creating a professional working arrangement in which the corporate idealist doesn’t exist.  And since deliberate company culture, which I’ll refer to as “corporate religion,” is largely theater for idealists, spending a lot of time talking about it in the book would be somewhat superfluous (I do mention it, but not extensively).  But that’s not to say that corporate culture and religion don’t matter.  And, all these half-formed notes I have ought to go somewhere.  So, here they are.

Corporate culture is more or less defined by three things: what it takes to advance within the company, and what it takes to stay in the same role within the company, and what it takes to be walked out by the company.  Paintball outings and “bring your pet to work” don’t define or even describe company culture.  Perhaps more surprisingly, neither do things like company “mission,” “values,” and “principles.”  These things, which constitute corporate religion, are mainly orthogonal to culture.  Corporate religion consists of ceremonies, outreach activities, and the official canon (mission statements and expressions of “official values”).  But none of these things are culture, any more than the Ten Commandments, New Testament, and church bake sales are the ‘culture’ of a rural evangelical town in the USA.

If you look up the definition of the word culture, you’ll have to scroll all the way down to definition number 5 to get to an actual definition of corporate culture.

The behaviors and beliefs characteristic of a particular social, ethnic,or age group: the youth culture; the drug culture.

For our purposes here, we’re talking about the social group “people who have opted to work at this company.”  This means that we’re talking about behaviors and beliefs of employees when we talk about culture, and this is why culture and religion are disparate and sometimes orthogonal entities.  Corporate employees are forced to attend religious ceremonies and memorize the canon, but what they actually believe and do outside of structured activities is another matter altogether.  Plenty of people who show up to church every Sunday go forth immediately afterward and pound beer and gamble on football.

ArmchairQuarterback Read More


Quiet Isn’t Always Anti-Social

There’s a common tale I hear that seems to epitomize being adrift in a sea of corporate anonymity. It is some variant on the theme that people are using asynchronous communication media when actually (to their knowledge or not) seated pretty close to one another. At its most facepalm, it’s perhaps two people who sit within 20 feet of one another dialing into a webex for a scheduled meeting between the two of them. But at its most deceptively understandable, it’s two people in a similar situation exchanging emails.

“Just get up and talk to each other!” exclaims an exasperated witness to the exchange.

In the case of the webex, the communication barrier seems legitimately hard to justify.  It’s like calling someone in the next room to watch TV together or something.  But in the case of email, I can offer justification, though perhaps not the justification you might think.  I’ll circle back around to this.


Susan Cain on Introverts

I’ve written a few posts on the subject of introversion over the last few years, including this first one that was relatively popular.  In response to these posts, I’ve gotten some recommendations to purchase Susan Cain’s “Quiet: The Power of Introverts in a World that Can’t Stop Talking.”  Her audio book now resides on my phone and I’m listening to it as I travel.  It’s worth a listen/read, and I’m definitely going to be writing more on this topic, particularly as I wrestle with the friction that has been created by making extroversion the new hotness in the programming world.

The book has offered an explanation of my own psyche that is downright eerie in how well it describes me.  Introversion, apparently is marked by a good bit more than just needing alone time to “recharge one’s batteries” after spending time in social situations.  Here are the themes from my post that Cain predicts of introverts (and, this apparently describes me quite well, as I got a 20 out of 20 on the informal “are you an introvert” quiz near the beginning).

  • Fine with public speaking (potentially).
  • Risk aversion.
  • Over-thinking and over-preparing for social interactions.
  • Impatience with small talk with strangers (e.g. about the weather).
  • Introverts as highly analytical.
  • Strong preference for written communication.

That last one is kind of interesting, eh?  An introvert will tend to favor the written word as a means of communicating ideas. Read More


Chess TDD 53: Castling for Black Pieces

After a couple  of episodes working on castling for white, and then an episode refactoring that implementation, it’s finally time to implement castling for black pieces.  This actually went pretty well.  The groundwork that I had laid in the previous episodes made life a lot easier for me here.  It wasn’t perfect, by the end, but it’s getting encouragingly close to “good enough to move on.”  With castling and en passant both soon to be in hand, it may be time to move to clean up mode with more elaborate acceptance scenarios.  A light at the end of the tunnel?

What I accomplish in this clip:

  • Finished basic implementation of castling checker.

Here are some lessons to take away:

  • It’s pretty rare to extract a class, find testing a lot easier on it, and then, at the end, come to regret extracting the class.  When you find yourself banging your head against the wall in a growing iceberg class, extract!
  • Refactoring to clean code makes it a lot easier to hit the ground running when you come back to your code after a while.
  • The goal of test driving a production code base is not to address all possible inputs to the thing under test.  You test drive until the implementation is done.  If you continue to write green tests after that, you’re no longer test driving.  There’s nothing wrong with this activity, but take care that you’re not adding cruft instead of value to your code base.
  • I wrote maybe 10 tests to drive the implementation of castling for white pieces, and then something like 3 tests to make it also apply to black pieces.  This is normal.  Just because I wrote 10 tests to get 50% of the functionality does NOT mean that I have to write another 10 tests to get the other 50%.


My New Project and Dignity in Hiring

I saw this tweet tonight and thought of dignity in hiring.

I admittedly didn’t read through the site in a ton of detail, but notwithstanding that, I found myself feeling a little giddy. Apologies in advance for the spoiler, but one of the main things for which I’ll be advocating in my in-progress book, Developer Hegemony, is that software developers stop commoditizing their labor at pennies on the dollar. Instead, I think they/we should form organizational structures akin to law firms, and sell software expertise as a professional service. With this model, a rising tide will lift all boats. Even the odd staff developer at some non-software company will be paid more like staff counsel than like someone with 4 layers of middle management between them and people that make decisions.

But, I digress. I mention seeing this site because it was a hopeful reminder that better ways of marrying developers with automation needs are on the way.  And, for my part, I’ve been thinking about how to get there, and not just for the purpose of my book.

A bit under 2 years ago, I realized that I’d completely burned out on salaried, exempt (i.e. full time) employment.  At the core of this was the feeling that exclusive employment cedes entirely too much control over one’s circumstances to another entity.  On a long enough timeline, you’ll find yourself in a situation you don’t like, doing things that you think are stupid, and hoping for reprieve before you have to make the life-disrupting decision to go job hunting on the sly.


So, I followed the advice that brings you continuous integration: if it hurts, do it more and more, until it’s painless.  I decided that, whether it be with employers, clients, or anything else, I’d never be completely able to prevent a situation from going sideways.  But what I can control is how easy it is for me to hit the eject button when it does.  And having a bunch of different clients and a whole ton of connections makes any single depression of the eject button relatively painless for me.  I was done putting all of my eggs in one basket.

That’s gone quite well.  These days I have more offers for work than I can take on, and a lot of different connections, contacts, and clients.  Life is good.  Maintaining my own pipeline is not without its drawbacks.  When you’re taking a break from your 9 to 5 gig on weekends, you might well find me invoicing or following up on prospective contracts.  But, I wouldn’t trade the relative freedom when it comes to controlling my working destiny.  I work more hours than most, but none of those hours are spent doing things that I think are stupid, at the behest of some megalomaniacal expert beginner.  And that has made all the difference. Read More