Nicholas Becker

Approaches to making good software and enjoying yourself because of it: PART 1

nbecker — Sun, 05 Oct 2008 19:53:56 GMT

Foreword

What to blog about, what to blog about... how about the way I look at making good software, with some broad, sweeping statements of truth? Roughly translated, you might say "the way I approach making software," because we all want it to be "good." Working with a team on a software project of any significant magnitude presents choices and situations of enormous complexity, both intellectual and emotional... Perhaps more than we developers give ourselves credit for.

A word of warning: my attention span when writing such things tends to start very focused, but linearly decrease as a function of time, so I'm going to share my thoughts on only some of this stuff in this entry. My view is that having the right approach to a job like this (software development) not only makes a better product, but turns what might be "just a job" into something genuinely enjoyable. Most all of these items deserve quite a bit of elaboration, and lots of books have been written on the variants and derivatives of them.

Embrace Testability as Your Preponderant Master

Forsake all others before it. If the correctness and quality of your software is based solely on good intentions, then there's probably little need to read any further. The pseudo-paradox and arch enemy of TDD is the unfortunate fact that most all large software projects that were written without TDD still perform the function they're supposed to. Multinational corporations make billions every year on the backs of software systems that are not test driven, and probably have little (if any) automated tested at all! Egads! But this is the key to writing "good" software -- it's not that you can't eventually get it to work, it's that human nature strives for something better. I liken it to living in a cardboard box vs. a soft bed in a quiet, air conditioned bedroom -- your will certainly achieve sleep either way, but given the choice, you're probably going to take the bed. Testability (which I will write about in the [hopefully] near future) naturally leads to, and requires a measure of good design -- which, generally speaking, should lend itself to something more understandable and more easily manipulated.

Working with software that can break at a moment's whim, or requires meticulous attention to detail for even marginally complex or simple tasks, then you're probably spending most of the day being frustrated. I've oft postulated that performing well with such software tasks requires, indeed, more brainpower and determination than working with and creating a well written and executed code base. The problem is, you're wasting all the brainpower being annoyed, with your sole motivation when sitting in front of monitor being to just get the thing done so I can go home/get a better review.

Eliminating this frustration frees the mind for more constructive purposes, which means the software is going to get better, and the processes will likely start to improve. Your relationships with your coworkers will likely also become more intimate, perhaps even becoming downright neighborly -- your tie will be forged from a common drive to produce excellence and be excellent in the process, rather than just shared misery. This is all speaking in absurd hyperbole, of course, but the idea is there somewhere.

Don't Be Afraid to Make Mistakes

There was a time when my primary motivation for the decisions I'd make in programming tasks/design were based solely on one thing: to not leave any room for criticism when the work was viewed by others. Basically it meant trying not to do the wrong thing, versus trying to do the right thing. I see some of this in others today, and I think it's important to know that it's okay to make mistakes. In fact, it's probably the best thing you can do! No matter what your skill level, nobody knows everything, and openly and honestly making the best decisions you know to make and welcoming criticism/discussion by your peers is the best way to grow -- and it helps the quality of the end product at the same time.

The fundamental importance of unit tests

nbecker — Tue, 22 Jul 2008 20:51:00 GMT

The tide has shifted it seems from a mass of people who outright reject the need for unit testing, to those who acknowledge it as important and then do just enough to say, "Yeah, we've got testing." This is code for, "We have a few tests here and there but we're too busy to write them most of the time"... or more likely, "I write a test every now and again, but secretly I think they're an unconscionable waste of time -- I just feel ashamed to admit as much publicly." Whilst I might feel that these responses are unreasonable, they are at the same time extremely understandable.

As a convert to the religion of test-driven development (once an individual who echoed the same kind of thoughts as above), I must confess that the fault of the above reasoning lies not on the shoulders of those that walk the path of the lost, but falls squarely on the believers themselves. Too often we can recognize developers who seem destined to repeat the self-destructive habits of what is now a nearly obsolete software methodology -- implement first, test later (if you have time). The problem is that unless said developers see first hand the benefits of a faithfully test driven software project, they have little reason to believe it's useful.

Superficially, the idea of writing masses of unit tests seems counterproductive. Unit testing is popularly emphasized as a means of verifying that freshly written code works as you intend it to, with the "unit" part of the term meaning you test only a method at a time. Such an idea can easily come across as petty and self-conscious. While this is certainly a valuable aspect of testing in general, automated unit tests provide peace of mind and immediate feedback for how all existing code responds to change.

A developer that contributed some programming work to my current project remarked recently that it was extremely satisfying to him to come onto a sizable project, knowing next to nothing about the code as a whole, and yet feel perfectly comfortable committing major changes that would not break any existing functionality. Why? Because the code base was nearly 100% covered by automated tests, combined with an automated build that provided feedback on any tests that failed (and that feedback is only generally useful to ensure that a developer didn't overlook running tests on their own). As projects grow larger and larger, it's not the testing of code you just wrote that becomes important, it's your interacting with the mass of existing code that absolutely must be verified. Without such testing, you must be an expert on huge amounts if not all of the application (in the worst cases) to efficiently contribute. You probably also need enormous manual testing cycles (even entire release "iterations") to rest assured that your latest launch will work at least as well as the last one. Anyone who's worked on a typical huge enterprise application knows that even then, you're generally not going to get off that easy.

Unit testing is really just a part, too, of the larger holistic idea of automated testing. Unit tests, integration tests, functional tests, etc. provide the essence of automated quality control and allow for the miraculous notion of a "no defects" policy for producing software. A joy that many have never known can arise from fully automated and fully covered testing -- on-the-spot, demo-able releases of a work in progress, even on a relatively large project. These practices by their nature also encourage beneficial and maintainable software design decisions, like separation of concerns and dissociation of implementation and interface. Such patterns allow for more testable, maintainable, and more easily understood code.

Without a firm belief in these values of such a degree of testing, however, not only will the performance of a developer's project(s) suffer, but so will the code itself. Without a conclusive example or experience with a successful test driven and automated application, fewer people will be inclined to walk the path of the light.

Blake Caraway and Duane Derouen Join Headspring Systems

BeyondStatic — Fri, 11 Jul 2008 10:17:51 GMT

Duane Derouen (blog) and Blake Caraway (blog) have joined the Headspring Systems team. Welcome guys! Both bring a lot of valuable experience to the team, and I look forward to working with them in all of our projects to come.