Posts

Showing posts from March, 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"

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