Thursday, March 17, 2016

Painting while blindfolded

In a discussion yesterday about how to know if our code was thoroughly tested, one of my tech leads mentioned "Unit testing without a code coverage tool is like painting a wall while blindfolded". I think it's a very apt metaphor, and something that developers should take to heart.

In most modern programming languages, there are tools to both automate unit level tests as well as determine how much of your code was actually executed as part of a test run. To run unit tests without validating what has and hasn't been covered is unprofessional. Imagine if you hired someone to paint your house and the first step is to blindfold themselves...what is your confidence that they will do a good job?

What amazes me is that I've heard a number of developers repeat this phrase "My professor told me that 100% code coverage is practically impossible"...which seems to lead them to the inevitable conclusion that "so therefore I won't write ANY tests". Fine 100% is tremendously difficult (especially if your code is poorly thought out or a "bad design (TM)", but 100% is NOT practically impossible...anyone who says this is either: #1 a hack, or #2 unprofessional. On that note, I will point out that typically CS/CE professors are quite often not professional developers or engineers, they're more often academics and/or scientists.

P.S. Professors, please stop saying this to your CS/CE students...

Wednesday, March 16, 2016

The craft of software development

There has been a recent spike (well relatively ancient in software terms...) in the term Software Craftsmanship. This is the notion that developing software bears more resemblance to a craft or art than to a scientific pursuit. This is a very accurate and a good explanation for why guilds and other artisanal concepts creep into software development circles.

I've noticed interesting contrasting correlations in folks who "grew up" developing software to solve problems versus people who learned computer science or computer engineering at a university. While the latter generally have a more sound grounding in the theoretical underpinning of "how computers work", the former have a better grasp at "how software delivers value". Put another way, computer scientists and computer engineers seem to have a focus on the nuts and bolts of how computers work instead of how to get them to do new and valuable things.

This is not a BAD thing, but losing sight (or not focusing on) "how what I'm building adds value" and instead focusing on "how the computer does stuff" tends to lead to what I'll term "science experiments". Using a different metaphor, a craftsman finds tools that are "good enough" for the job and spends a little effort of time to constantly refines them whereas a scientist will spends a LOT of effort over time finding or building the "perfect tool" for the job and little effort to actually do "the job".

Put another way, if I want to build something out of wood, I could spend days/weeks/months studying the various characteristics if different kinds of wood, or I could build a cabinet out of whatever lumber I can get my hands on and refine my techniques as I progress through more projects with different kinds of wood. I find the latter to be a more useful approach, unless my value proposition is that I want to be the foremost expert on "all things wooden". To illustrate the difference I ask the question: "Do you want your cabinets built by someone who has built many progressively better cabinets with a variety of materials, or by someone who has never actually built anything, but can explain the shear strength of cedar versus maple?".

While I realize this is an oversimplification (well maybe not as much as we'd like to admit), where I find a particular weakness in the industry right now is in developing the "craft". Too often, industrialized software development ignores a particular aspect of craft, that is, the continuous improvement of your tools and process and instead focuses on a particular "perfect technology" without refining the art. I've seen too many developers focus on finding the "perfect tool" instead of learning how to work with the ones they already have...the process of learning new tools and techniques better serves "building useful things" when it is constant and evolutionary instead of intermittent and revolutionary.