DaedTech

Stories about Software

By

If You Automate Your Tests, Automate Your Code Review

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at CodeIt.Right.

For years, I can remember fighting the good fight for unit testing.  When I started that fight, I understood a simple premise.  We, as programmers, automate things.  So, why not automate testing?

Of all things, a grad school course in software engineering introduced me to the concept back in 2005.  It hooked me immediately, and I began applying the lessons to my work at the time.  A few years and a new job later, I came to a group that had not yet discovered the wonders of automated testing.  No worries, I figured, I can introduce the concept!

Except, it turns out that people stuck in their ways kind of like those ways.  Imagine my surprise to discover that people turned up their nose at the practice.  Over the course of time, I learned to plead my case, both in technical and business terms.  But it often felt like wading upstream against a fast moving current.

Years later, I have fought that fight over and over again.  In fact, I’ve produced training materials, courses, videos, blog posts, and books on the subject.  I’ve brought people around to see the benefits and then subsequently realize those benefits following adoption.  This has brought me satisfaction.

But I don’t do this in a vacuum.  The industry as a whole has followed the same trajectory, using the same logic.  I count myself just another advocate among a euphony of voices.  And so our profession  has generally come to accept unit testing as a vital tool.

Widespread Acceptance of Automated Regression Tests

In fact, I might go so far as to call acceptance and adoption quite widespread.  This figure only increases if you include shops that totally mean to and will definitely get around to it like sometime in the next six months or something.  In other words, if you count both shops that have adopted the practice and shops that feel as though they should, acceptance figures certainly span a plurality.

Major enterprises bring me in to help them teach their developers to do it.  Still other companies consult and ask questions about it.  Just about everyone wants to understand how to realize the unit testing value proposition of higher quality, more stability, and fewer bugs.

This takes a simple form.  We talk about unit testing and other forms of testing, and sometimes this may blur the lines.  But let’s get specific here.  A holistic testing strategy includes tests at a variety of granularities.  These comprise what some call “the test pyramid.”  Unit tests address individual components (e.g. classes), while service tests drive at the way the components of your application work together.  GUI tests, the least granular of all, exercise the whole thing.

Taken together, these comprise your regression test suite.  It stands against the category of bugs known as “regressions,” or defects where something that used to work stops working.  For a parallel example in the “real world” think of the warning lights on your car’s dashboard.  “Low battery” light comes on because the battery, which used to work, has stopped working.

Read More

By

Characteristics of Good APIs

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at their monitoring solutions.

The term “API” seems to present something of a Rorschach Test for software developers.  Web developers think of APIs as REST endpoints and WSDLs.   In contrast, desktop developers may think of APIs as “library code” written by developers from other organizations.  Folks writing low level code like drivers?  API provides the hooks into OS system calls (emphasis mine).

I understand this mild myopia that can happen, but the bigger picture matters.  API offers a much more generic way of thinking.  I personally like the definition from “tech terms.”

An API is a set of commands, functions, protocols, and objects that programmers can use to create software or interact with an external system. It provides developers with standard commands for performing common operations so they do not have to write the code from scratch.

An API defines how other programmers interact with your software.  Thus each of the personas I mentioned have the right answer, but a small slice of it.  As you write code, ask yourself about the user of that code.  If that user interacts with your code via code of their own, you’re building an API.  And before you ask, yes, that even applies to other developers in your company or even your team that use your code.

Consequently, understanding properties of good APIs carries vital importance for our industry.  It makes the difference between others building on your work or avoiding it.  And, let’s be honest — there’s a certain amount of professional pride at stake.  So what makes APIs good?  Let’s consider some characteristics of good APIs.

Read More

By

Habits that Pay Off for Programmers

Editorial Note: I originally wrote this post for the LogEntries blog.

I would like to clarify something immediately with this post.  Its title does not contain the number 7, nor does it talk about effectiveness.  That was intentional.  I have no interest in trying to piggy-back on Stephen Covey’s book title to earn clicks, which would make this post a dime a dozen.

In fact, a google search of “good habits for programmers” yields just such an appropriation, and it also yields exactly the sorts of articles and posts that you might expect.  They have some number and they talk about what makes programmers good at programming.

But I’d like to focus on a slightly different angle today.  Rather than talk about what makes people better at programming, I’d like to talk about what makes programmers more marketable.  When I say, “habits that pay off,” I mean it literally.

Don’t get me wrong.  Becoming better at programming will certainly correlate with making more money as a programmer.  But this improvement can eventually suffer from diminishing marginal returns.  I’m talking today about practices that will yield the most bang for the buck when it comes time to ask for a raise or seek a new gig.

Read More

By

Elements of Helpful Code Documentation

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, check out GhostDoc, which can automatically generate help files for you.

If you spend enough years writing software, sooner or later, your chosen vocation will force you into reverse engineering.  Some weird API method with an inscrutable name will stymie you.  And you’ll have to plug in random inputs and examine the outputs to figure out what it does.

Clearly, this wastes your time.  Even if you enjoy the detective work, you can’t argue that an employer or client would view this as efficient.  Library and API code should not require you to launch a mystery investigation to determine what it does.

Instead, such code should come with appropriate documentation.  This documentation should move your focus from wondering what the code does to contemplating how best to leverage it.  It should make your life easier.

But what constitutes appropriate documentation?  What particular characteristics does it have?  In this post, I’d like to lay out some elements of helpful code documentation. Read More

By

Improving .NET Application Performance

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at the application monitoring options you can take advantage of.

First of all, make sure that you use StringBuilder when concatenating strings.  You see, the “+” operator — just kidding.  I mean, that’s not bad advice.  Rather, I’m kidding in that I just don’t want to offer this style of tip today.

Often, advice about application performance comes at you with the staccato of rapid fire tips.  “37 Ways to Shave Nanoseconds off of Your Overnight ETL Process.”  I exaggerate for comedic effect with that title, perhaps.  But the point remains.  Authors serve up advice for optimization with many tips that matter only inside of tight loops.  And it’s hard to keep all of those in your head.

I’d like to take a different tack here today and offer fewer suggestions in the hope that they’ll stick with you.  But I differentiate my message in another crucial way as well. I want to offer performance tips for .NET programming that will also help you write clean, readable code.

All too often, these concepts stand in opposition to one another.  Performance tips often demand changes that produce the desired effect while making the code harder to read.  This phenomenon gives rise to the iconic wisdom that “premature optimization is the root of all evil.”  Implementing them might bring relatively insignificant marginal gains in performance while creating confusing, hard-to-read code.

But it strikes me that readable and performant sometimes overlap.  And, since tips for that serve two purposes, they are definitely worth filing away.

Read More