Stories about Software


Bridging the Communication Gap Between Developers and Architects

Editorial Note: I originally wrote this post for the NDepend blog.  Go check out the original here, at their site.  While you’re there, have a look around at the other posts and at NDepend itself.

If you want to set off a ceaseless, spirited discussion, ask a roomful of people what makes some music good and other music bad.  The opinions are likely to be as spirited as they are diverse, with, perhaps, good points to be had.  But consensus is unlikely.


If you want to see a similar dynamic in the software development world, ask a roomful of software developers what a software architect is.  What makes a person an architect?  Does the architect write code?  What kinds of decisions should an architect make?  What is the relationship between architects and developers?  Do developers report to the architect, or is it a “dotted line” reporting relationship?  Maybe they’re peers?  Do architects need to have a lot of domain knowledge?  Do architects need to be the best programmers (or at least have been at some point)?  You get the idea.

Go out and observe enough software shops in action, and you will see every different imaginable answer to these questions in every possible combination.  This fact alone lays seeds for myriad communication complexities between developers and architects.  In any shop, a developer is more or less a developer.  But the architect role varies widely and, as developers move from company to company, this creates confusion.

Before going further down that path, let’s consider some things that are often true of a software architect.  And, I say “often true” because, as I just pointed out, the definition is fluid enough that it’s hard to pin things down definitively the way we might say, “software developers write computer programs.”

  • Architects tend to be the ones to make “big picture decisions” (which language/database/framework will we use?)
  • Architects tend to have more tenure at companies and more industry experience.
  • Architect tends to be a leadership role, meaning they supply either thought leadership, org chart leadership, technical leadership, or some combination.
  • Architects tend to have more face time with “the business” than developers.

What do all of these tendencies mean?  Well, simply put, they mean that architects have somewhat of a different area of focus than software developers.  Developers concern themselves primarily with the tactical, and architects concern themselves mainly with the strategic.  The concept of tactics versus strategy can be (perhaps over-) simplified to the idea that strategy is the “what” and tactics are the “how.”  If it comes to your personal finance, “diversification” may be the strategy and “spend X amount on stocks, Y on bonds, and Z on real estate” may be your tactics.


Read More


Chess TDD 61: Testing an Actual Game

Editorial Note: I was featured on another podcast this week, this one hosted by Pete Shearer.  Click here to give it a listen.  It mostly centers around the expert beginner concept and what it means in the software world.  I had fun recording it, so hopefully you’ll have fun listening.

This post is one where, in earnest, I start testing an actual game.  I don’t get as far as I might like, but the concept is there.  By the end of the episode, I have acceptance tests covering all initial white moves and positions, so that’s a good start.  And, with the test constructs I created, it won’t take long to be able to say the same about the black pieces.

I also learned that building out all moves for an entire chess game would be quite an intense task if done manually.  So, I’d be faced with the choice between recording a lot of grunt work and implementing a sophisticated game parsing scheme, which I’d now consider out of scope.  As a result, I’ll probably try to pick some other, representative scenarios and go through those so that we can wrap the series.

What I accomplish in this clip:

  • Get re-situated after a hiatus and clean up/reorganize old cards.
  • A few odds and ends, and laying the groundwork for the broader acceptance testing.

Here are some lessons to take away:

  • No matter where they occur, try to avoid doing redundant things when you’re programming.
  • If, during the course of your work, you ever find yourself bored or on “auto-pilot,” that’s a smell.  You’re probably working harder instead of smarter.  When you find yourself bored, ask yourself how you might automated or abstract what you’re doing.
  • When you’re writing acceptance tests, it’s important to keep them readable by humans.
  • A seldom-considered benefit to pairing or having someone review your coding is that you’ll be less inclined to do a lot of laborious, obtuse work.
  • Asserting things in control flow scopes can be a problem — if you’re at iteration 6 out of 8 in a while loop when things fail, it’s pretty hard to tell that when you’re running the whole test suite.


Solve Small Problems

Editorial Note: I originally wrote this post for the Infragistics blog.  Go check out the original at their site.  While you’re there, go check out their developer tools and controls.

It’s fun to think of great moments in the history of science, particularly the ones that have a memorable anecdote attached to them.  In the 3rd century BC, a naked Archimedes ran down a city street, screaming Eureka, because he had discovered, in a flash, how to measure the volume of irregular solids.  In the 1600s, a fateful apple bonks Issac Newton on the head, causing him to spit out the Theory of Gravity.  In the early 1900s, another physicist is sitting around, contemplating the universe, when out pops E=MC^2.

Newton Getting Bonked with an Apple

These stories all share two common threads: they’re extremely compelling and entirely apocryphal.  As such, they make for great Disney movies, but not such great documentaries.  Point being, we as humans like stories of “eureka moments” and lightning bolt inspiration much better than tales of preparation, steady work, and getting it right on attempt number 2,944, following 2,943 failed attempts.

But it goes beyond just appreciating the former type of story.  We actually manufacture them.  Perhaps the most famous sort of example was Steve Jobs’ legendarily coy, “oh yeah, there’s one more thing” that preceded the unveiling of some new product or service.  Jobs and Apple were masters of “rabbit from the hat” marketing where they’d reveal some product kept heretofore under wraps as though it were a state secret.  All that is done to create the magic of the grand reveal — the illusion that a solution to some problem just *poof* appeared out of thin air.

Unrealistic Expectations

With all of this cultural momentum behind the idea, it’s easy for us to internalize it.  It’s easy for us to look at these folk stories of scientific and product advancement and to assume that not having ideas or pieces of software fall from us, fully formed and intact, constitutes failure.  What’s wrong with us?  Why can’t we just write that endpoint in one shot, taking into account security, proper API design, backward compatibility, etc?  We’re professionals, right?  How can we be failing at this?

You might think that the worst outcome here is the ‘failure’ and the surrounding feelings of insecurity.  But I would argue that this isn’t the case at all.  Just as the popular stories of those historical scientists are not realistic, and just as Apple didn’t wave a magic wand and wink an iPod Nano into existence, no programmer thinks everything through, codes it up, and gets it all right and bulletproof from the beginning.  It simply doesn’t happen.

Read More


The Role of Log Files in Experiments

Editorial Note: I originally wrote this post for the LogEntries blog.  Head over to check out the original at their site.  LogEntries provides a service that allows you to centralize, monitor, and search your log files, so if you’re interested in logging and related topics, there is a lot to check out.

You have heard, no doubt, of the Lean Startup.  If you need a refresher to place the name, it’s a book, but it’s also a business trend with such momentum as to have a website advertising it as a “movement.”  And, frankly, that advertisement is hardly a stretch.  The title and the terms coined in it are on everyone’s lips in the tech industry these days because people at companies of all shapes and sizes want to capture some of that startup magic.

For instance, it’s pretty likely that you’ve heard a process described as “lean,” and it’s a veritable certainty that you’ve heard the term “minimum viable product” tossed around at some point or another.  You may even have heard these terms used correctly.  I say this because the use of these terms has become so ubiquitous among the book’s readers that non-readers adopt them as well and map their own situational contexts onto them.  Definitions drift.  “Minimum viable product” has come to mean “beta” or “prototype” and “lean” is a hipper, newer version of “agile” that has something to do with Toyota, or something.

But if you peel back a layer from breathless use of buzzwords, you’ll find genuine, serious substance underneath.  To summarize the Lean Startup in a ridiculously short sound byte, I would offer, “apply the scientific method to your business.”  And that’s an extremely powerful concept.

You’ll note that there’s nothing in my description about startups, per se, and that’s intentional.  As Eric Ries argues in the book, there’s nothing to say that the same approach can’t be leveraged within large, established businesses.  He even gives a number of examples of exactly that application.  Make no mistake; the Lean Startup approach has lessons for you no matter what your business and no matter how well-established.

Business, Science, and Software

For me, and for most reading, our business is the business of software.  The question thus becomes, “how can we apply the scientific method to building software?”

To do that, let’s consider the scientific method a bit more formally.  Here is what it involves, quoted from the linked page.

Read More


How to Get a Raise

I’ve been slipping a little in my quest to answer reader questions of late, so I thought I’d course correct.  The question revolved around the notion of how to get a raise.  Actually, that was the question in its entirety.

How do I get a raise?

A deceptively simple question that one.  So much so, in fact, that I’m going to be kind of roundabout in my response.

Paying the Iron Price for Cable

Assuming that you’re one of the millions of people that pay for cable television, you fork over your $100 per month and get the full rainbow of channels.  You probably don’t think a whole lot about the $100 that you’re spending each month because it’s the closest a recurring cost can come to being a sunk cost.  You’re used to cable and you’re used to your wallet being $100 lighter, so continuing to have cable for $100 per month is not a decision that you consciously make.  In fact, to do something different would be the conscious decision.

Bearing this in mind, do you ever think to yourself, “you know, I love how they’ve finally stopped killing off erstwhile protagonists on Game of Thrones, so I think I’ll call the cable company up and offer to pay $103 per month, starting in the next fiscal year?”  Of course you don’t — that’s ridiculous.

But, let’s consider a slightly modified version of that scenario.  Let’s say that the cable company called you and said, “we’re raising the price of your Premium Thingamajig Package to $103 a month, so if you want to continue to see what Sansa, Arya and the gang are up to, you’re going to have to pay up.”  You probably go on to Facebook, post a cathartic rant, and then pay the extra money.  Because, while that’s inconvenient, what would be more inconvenient is to have to spend time figuring out how to compensate and vary your routine.  You could go with Dish or AT&T or whatever, but that’s probably too much effort to expend over a 3% increase.  If it were a 10% or 15% increase, on the other hand, it might be time to comparison shop.


Employment as a Zero Sum Game

As you’ve no doubt surmised, I offered this silly parallel to help you empathize with your employer’s position.  You’re the cable company in their lives — non-critical, largely taken for granted, and prominent enough to be missed as long as the price isn’t too high.  And, like your relationship with your cable company, your relationship with your employer is, talk of family and work-life balance notwithstanding, a zero sum game.  The more money you have, the less they have, and vice-versa.

Read More