Atomic Spin :: Elements of Software

A software developer by the name of Gustavo Duarte wrote something quite fascinating last month on Reality-Driven Development. Apparently, his writing drew many Slashdot readers to his humble blog.

In his post, Duarte draws from such disparate sources and ideas as physicist Richard Feynman’s thoughts on the Challenger disaster, natural selection, a linux discussion thread, the book Built to Last, and others to make his case for what he calls Reality-Driven Development.

Duarte says that “reality is invited in via experiments” and defines Reality-Driven Development thusly:

A good software development process should optimize experimentation and improve feedback from reality. This is what I mean by reality-driven development. And in software the most important realities are user experience and technical quality, while the primary experiments are working software and code.

He criticizes big up-front design:

And rigid upfront design is a sure way to a crappy code base or engineering disasters. Alistair Cockburn put it best: “With design I can think very fast, but my thinking is full of little holes.”

He also casts Agile development techniques in an interesting light:

There is no specific reality-driven methodology. The Agile principles have a lot in common with these ideas (and certainly influenced them), but the devil is in the details. I prefer to think of software engineering in terms of a toolbox, full of techniques we pick and choose for the right situation. Process tools for optimizing experimentation include iterative development, executable architecture, continuous integration, and unit testing.

It’s difficult to summarize all the juicy todbits. Reading the entire post is well worth the time.

Recently, some of us at Atomic Object have been providing a small video that demonstrates any new features that we have implemented for our customers. It has been proven to be an effective technique when a customer has either been remote, busy, or traveling. Video demonstrations are also effective when the project is so small that setting up a weekly meeting with the customer is not plausible. However, even when the customer is readily available and is an active participant in the project, having these small video demonstrations can prove useful when they would like to show his/her coworkers a particular feature.

Surprisingly, the amount of effort you, as the developer, has to put forth actually decreases and customer satisfaction increases. A video demo is easy to make and it provides a “to the point” and a clear representation of the features. The customer can easily download and view the video in a matter of minutes. Because the features are being demonstrated and focused on; the customer can provide feedback quickly about what they like or dislike.

Most customers have other jobs and cannot focus solely on your project. Because of this, they may not have the time to download, launch, or try out new features. (Especially if it is 4:30 p.m. on Friday.) A small video demonstration makes life easy for the customer and it focuses them on what matters.

Another, not so obvious benefit, is how the video could quickly become viral and propagate to other end-users. For example, we had a small, tightly-scoped project that got a good deal of feedback in a short period of time, due to the amount of people that were able to view it. This enabled us to make tweaks and adjustments quickly without “burning up the budget.”

There are two tools that I know of that can do screen video capturing. Snapz Pro is my choice for MacOS X, it is easy to use and relatively inexpensive. I do not have any experience using screen capturing on Windows. However, when I did a google search, TechSmith popped up a few times and it appears to have some nice screen capture tools.

About a year ago Greg Pattison and I began working together on a new C++ application for a client. It was the first C++ project of any significant size for either of us since becoming enamored with interaction-based testing techniques.

I’ve been reading the articles on the birth of Apple’s Macintosh at folklore.org recently. Folklore.org’s purpose (to summarize its about page) is collective historical storytelling accomplished through the anecdotes of multiple contributors. Only the development of the Mac is presently chronicled. The reading is wonderfully interesting and engaging; it’s like a book I can’t put down.

Atomic Object’s history is intimately linked with eXtreme Programming (XP). These days XP is probably better known under the larger umbrella of Agile methodologies. XP was inspired by successful practices observed at work throughout the history of software development. In reading about the first Mac I’ve been encountering examples of processes and techniques that are quite familiar; perhaps these stories are similar to those that inspired XP.

Ron Jacobs, a traveling Microsoft evangelist and host of ARCast.TV and ARCast Radio visited the Atomic Object office last week and we chatted for quite a while about TDD, MVP and Presenter First development methodologies for his podcast.

Code reviews are a common practice intended to catch software flaws by having “more eyes” on a piece of code in order to catch costly software defects. Unfortunately, many people dread code reviews, because they are time consuming and many times are not very fruitful. It takes a lot of discipline and similar mindsets to really get a cost-effective benefit out of code reviews. Not to mention that reviews often get slowed by people nit-picking implementation, code style and even arguing over where a comment, paren or brace should go!

For those of us that practice test driven development, we have an added luxury that all of the functionality in our code is backed up by unit, integration and system tests, or some mix of these. These tests also serve as living documentation of the code at hand.

Therefore, it seems that reviews of tests, which verify requirements, would be a much more suitable and beneficial initiative. After all, aren’t we all most concerned with what the code “does” and not so much “how” it does it? The tests capture the requirements put on a body of code, and that is really what is most important to be sharing with fellow developers. This technique would avoid many of the hurdles that inhibit traditional code reviews. Furthermore, changes to tests or addition of tests (requirements) could be done live in a code review and eliminate another round of reviews to ensure all concerns have been addressed. This all leads to less bookkeeping and happier developers!

Q: What is the pragmatic role of beauty in technology?

A: ...[B]eauty is the best value in software because it’s the best tool in managing complexity. If I have to build a tremendously complex machine, if I make the machine elegant, the lines clean, simple & beautiful, the chance is greater that I will be able to understand it and master it than if I slop together some jalopy of a program.

We recently got a question from one of our customers on writing and running test suites for multi-platform applications (the case in question involves Java). The thread of discussion follows. First, we have Andy’s original question. Next, Karlin and Dave respond…

Our interest in applying Agile practices to embedded software began in earnest about a year and a half ago. (You can read about our continuing adventures on our Embedded Software page and at this blog’s Embedded Corner.) After several projects under our collective belt, we’re now at the point of working on a very large and complex embedded project with X-Rite, one of our longtime clients. So far things are going quite well. For this project we’ve been using good Agile-style planning and tools like burndown charts. And, we’ve been learning some important things about successfully using Agile planning in embedded projects.

Migrations are one of the most useful additions Rails provides. Knowing that you can rely on them working is good too. Recently we've released a plugin, migration_test_helper, which makes it easier to test the migrations you create for a Rails app individually and as a whole.

1
2

 ./script/plugin install
  svn://rubyforge.org/var/svn/migrationtest/tags/migration_test_helper

Plans are nothing; planning is everything. Dwight D. Eisenhower

One of the benefits to interaction-based unit testing is how much easier it is to truly test only the class under test and not its underlying implementation. You simply compose the class with all of the “worker” objects it needs to get its job done, and then mock them out in your test. Set your expectations of these mocked out objects and there you go – you are only testing your class’s implementation.

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.

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.