Every human society has a similar expression about the nature of complexity. In English we say, “The devil is in the details”. In Sweden they say “Djävulen finns i alla detaljer”. Same idea, exactly. Customers of software development firms often underestimate, with a vengeance, the truth of this well-worn aphorism. Maybe that’s a necessary thing, as their vision needs to be unfettered by details in order to bring to life something new, innovative, and valuable. Software developers, on the other hand, are required to deal with the devilish details. Computers demand precise, detailed instructions. Software craftspeople must turn a customer’s vision into a working system, devilish details included.

Six years of working with people who have ideas for software projects they think will help them or their company make money has taught me a few things. Speaking in terms of my first career (as a professor), I feel the time is right to introduce a new course: Software Customer 101.

My hope is to improve the odds for Atomic Object customers and potential customers to have a successful project and make money from their great ideas.

The material in this course will be grouped into six major sections:

I. Inconvenient Truths

II. Doing Your Homework

III. Evaluating a Vendor

IV. Evaluating a Proposal

V. Making the Choice

VI. Running your Project

There are a growing number of developers doing TDD with JavaScript which is why unit testing frameworks like JsUnit exist for it. Sadly though, while many languages have had mock object libraries for years, JavaScript has had none. Hence the birth of JSMock, a mock object library I wrote for JavaScript that fills the ‘mock object’ void in JavaScript Test Driven Development.

We just recently got a last minute notice that we’ve been accepted to present at the Embedded Systems Conference, Silicon Valley 2007. Greg Williams and myself have the honor of presenting a 90 minute tutorial on the Test Driven Development approach Atomic Object has been developing for embedded software. The presentation will cover AO’s Model Conductor Hardware design pattern and the tools we’ve developed to do unit testing and mocking in C.

Our presentation is entitled Mocking the embedded world: practical TDD , continuous integration, and design patterns. The name plays off both the use of mocks in our approach and the challenge we were once given to make Test Driven Development work in embedded systems.

I have to say thank you to the folks over at James Grenning’s Agile Embedded Forum. Our threads of conversation have been quite helpful in refining the eventual presentation of our concepts and work. The timing of those discussions has truly been serendipitous.

The bug struck us nearly a month after we introduced it into the system. Four weeks previously we had started working on a new project that involved communication with a device. We didn’t have the device yet. The firmware wasn’t started yet. We needed to familiarize ourselves with the application. So we made a mistake that stayed hidden, like a disease with a long incubation period.

If you are looking to add a hint of BDD spice to your ruby TestCases, check out our recently updated Behaviors gem.

Download Behaviors

Start using Behaviors

I was recently introduced to the writings of Dr. Gregory F. Treverton. Treverton is currently a RAND analyst and previously a high-ranking US intelligence official. In his book Reshaping National Intelligence for an Age of Information Treverton made the distinction between mysteries and puzzles. Dr. Treverton offers that puzzles are questions with answers – for instance, how many nuclear missiles a nation possesses. Mysteries are those questions for which there are no answers – for example, whether a particular country will take military action against another. Puzzles involve facts and data. Mysteries involve judgment, analysis, and interpretation.

This distinction between Mysteries and Puzzles encapsulates something essential about the nature of software.

Carl Erickson and Dave Crosby have been working on an article with Brian Marick regarding the Presenter First approach Atomic Object helped develop. That article will be published in the February 2007 edition of Better Software. In the meantime, Brian posted an excellent video to his blog on Model-View-Presenter incorporating Presenter First.