Stories about Software


API Design Using Behavior Driven Development

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re there, take a look at some of their products in the code review, testing, and API spaces.

Test-driven development (TDD) has been around for a while now.  Behavior-driven development (BDD) is a comparably recent methodology that emerged from the practice of TDD.  It could reasonably be called a narrower application of TDD.

TDD is a process where one uses a failing unit test to express a shortcoming of the system.  The next step is then to modify the production code to get the failing test to pass, without making existing tests fail.  BDD more or less takes this same concept and adds to it the idea that the tests should be written in easy-to-understand language about the problem domain, and that they should express user acceptance criteria.

So instead of

you would have

As a practice, this has found its way into the agile canon, and given rise to something conversationally termed, “three amigos.”  This is a practice wherein a representative of “the business,” a tester, and a developer get together and agree on what a requested feature is, what it means, what it looks like when done, and how to verify completion.  In teams practicing BDD, the output of this conversation will often be an acceptance test, expressed in the Gherkin specification language.  When added to the codebase, this test will, of course, fail.  The folks implementing the feature know that they’re done when they’ve succeeded in making the test pass.


If we put agile aside for a minute, this is a pretty common sense approach for any team.  The essence of it is, “let’s define and be clear about what success looks like and then automate a check for it.”  So you don’t need to be an agile team for this to make sense — you just need to be a team looking for clarity.

Read More


Targeted Code Reviews in Regulated Industries

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re there, check out the work of the other authors writing for them as well.

For a lot of people out there developing software, life is pretty simple.  I say this not because there’s anything simple about software development, but because life around the practice of software development is simple.  You come in around 9, spend the day doing what the software needs to have done to it, and you go home at 5.  Maybe every now and then you stay late some days to make a push.

As organizations get bigger and more specialized, however, the outlook starts to change.  Growth brings larger and larger headcount, which, in turn, means more communication channels and general, bureaucratic overhead.  Growth also brings more outsider scrutiny and general public interest, particularly as companies go public and make headlines.  Such organizations start to become regulated.


Simply put, a regulated organization is one in which the government takes an interest.  Legislation about how the organization must behave is created, enacted, and enforced, the latter often coming in the form of check-ups, inspections, or audits.  Large companies may find themselves regulated in ad hoc fashion, or it may happen due to their size and public influence.  Other companies are regulated at any size, simply by virtue of their industry.  This latter designation applies to the finance, energy, healthcare, and defense industries, to name a few.

The Productivity Impact of Regulation

However your company comes to be regulated, the impact on you, as a software developer, is noticeable.  You have to do stuff with which your peers at other organizations needn’t bother.  You need to follow certain protocols for database access or document your code in certain ways.  Often times, and at larger organizations, this takes on a “death by a thousand cuts” status in your life, and it starts to feel as though you do a lot more box-checking than software development.

This, in spite of the importance of complying with this regulations, is an untenable state of affairs for a group.  To put a point on it with hyperbole, one surefire way to have your software comply with all regulations is not to write any software.  And, while that’s clearly never the actual mission of your company, it can sometimes feel that way as regulation compliance starts to swallow your time.

Read More


4 Ways Custom Code Metrics Make a Difference

Edit: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and give it a try.  If you like static analysis, you’ll find yourself hooked.

One of the things that has surprised me over the years is how infrequently people take advantage of customizable code metrics.  I say this not from the perspective of a geek with esoteric interest in a subject, wishing other people would share my interest.  Rather, I say this from the perspective of a business man, making money, and wondering why I seem to have little competition.

As I’ve mentioned before, a segment of my consulting practice involves strategic code assessments that serve organizations in a number of ways.  When I do this, the absolute most important differentiator is my ability to tailor metrics to the client and specific codebases on the fly.  Anyone can walk in, install a tool, and say, “yep, your cyclomatic complexity in this class is too high, as evidenced by this tool I installed saying ‘your cyclomatic complexity in this class is too high.'”  Not just anyone can come in and identify client-specific idiosyncrasies and back those findings with tangible data.


But, if they would invest some up-front learning time in how to create custom code metrics, they’d be a lot closer.

Being able to customize code metrics allows you to reason about code quality in very dynamic and targeted terms, and that’s valuable.  But you might think that, unless you want a career in code base assessment, that value doesn’t apply to you.  Let me assure you that it does, albeit not in quite as direct way as it applies to me.

Custom code metrics can help make your team better, and they can do so in a variety of ways.  Let’s take a look at a few.

Read More


How to Get that First Programming Job

If I think through the corpus of posts I’ve published, it seems they rarely focus on concerns at the entry level.  Or, at least, at the entry level of software, specifically.  Today, I’d like to look at a reader question about getting that first programming job.

My question is, what if I’m not exactly a developer yet?  I’m just wrapping up one of those full stack coding bootcamps, and I’m anxious about finding that first job.  Can you offer any advice?  I want to show that I care about doing things right.

First, I’ll offer a few caveats.  Nothing in the reader question spoke to how much experience the asker had outside of the programming industry.  That can matter, but I’ll write this post in such a way where it won’t.  Secondly, because I’m not entirely clear on the context for the last sentence, I’ll assume it exists as a way to show (and provide) value to prospective employers.  In other words, I’ll assume that “I care about doing things right” means “I want employers to see that I have good work ethic and care about the craft.”

The Entry Level Conundrum

When I graduated college at the end of 2001, I graduated into the teeth of the .COM bubble bursting.  Offers I had received dried up, and interview invitations I had received evaporated.  A new reality emerged — a reality in which entry level folks found themselves subject to a paradoxical conundrum.


Nobody wanted to hire software developers without experience.  And I couldn’t get any experience without getting hired.  I did what anyone in my position would do and went to work at Radio Shack.  I’m actually dead serious about going to work at Radio Shack.  That’s how bad things got in my search, and I needed money.

Eventually, after almost a year of peddling cell phones, freelancing a bit, and looking for work in my spare time, I landed a job as a “Software Quality Engineer,” or, as I like to think of it now, “Software Engineer with Training Wheels.”  I took the job, shed the training wheels and never looked back.

While my story eventually ended in joy (or at least employment), I believe the entry level conundrum holds true in the industry to this day.  Developer fortunes as a whole have improved substantially since I graduated with my CS degree.  But it can still be hard to find that first gig.

Read More


Reviewing Strangers’ Code on Github

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re there, check out some of the pieces by their other authors.

I make part of my living these days as an IT management consultant, and in this capacity, I’ve developed an interesting niche: evaluation of codebases.  Specifically, an organization’t management will bring me in to spend a week or two looking through a codebase, sizing it up, and making recommendations for what to do with it going forward (e.g. “stay the course, rework the architecture, targeted training, scrap it, etc.”)

As you might imagine, this part of my practice leads me to looking at and quickly grokking a lot of unfamiliar code.  Every few weeks, I’m squinting at strange classes, running static analysis tools, and making lists of assumptions and questions to ask the development team.  And I’ve found that this practice has benefits to me beyond helping me earn my living.  I’d argue that it makes me a better programmer.

Consider the opposite situation — one that describes an enormous cross section of industry developers.  They come in to work each day and deal with the same codebase.  This continues day in and day out for weeks, months, or even years.

This year, my wife and I are hoping to make a visit to the Galapagos Islands, which are noteworthy for the uniqueness of the wildlife there.  The animals living there have been isolated from the wider world of fauna for millions of years, and the result is that they’ve developed unique and unusual characteristics that cannot be found anywhere else.  This is what tends to happen to codebases in shops where the majority of developers work in relative isolation.  A bubble forms, and practices drift toward the unusual.


For an individual, this isolation tends to put a damper on skill acquisition and can even be career limiting.  It’s the polar opposite of the situation in which I find myself — constantly immersed in unfamiliar code.  So how can you remedy the isolation if your professional life shows you the same code in day in and day out?  (Without drastic career moves, that is).  Well, the dead simplest thing I can think of is to seek out and review other people’s code.  And to do that, there’s no better place to go than Github.

Here’s what you can do.  Every few weeks or so, poke around idly on Github, searching for random codebases in your language of choice.  Big or small, popular or niche, active or forgotten — it really doesn’t matter much.  They just need to be different and new.

Once you’ve found one (and just about any one will do), clone it and get the code locally on your machine.  Open it up in your IDE/editor/environment of choice, and start looking around.  If you start to perform this exercise with some regularity, here are some benefits that you can expect, in my experience.

Read More