Atomic Spin :: Elements of Software

A short article in Scientific American entitled “Tough Choices: How Making Decisions Tires Your Brain” looks at “executive function.” A growing body of psychological and neurological studies demonstrates that the human mind has a limited amount of decision making juice available each day.

When said juice is used up decision making declines markedly in measurable ways. Given that software development is an all-day exercise in decision making, trade-off resolution, and implementation (all topics discussed in the article), the evidence cited in the article supports the idea of Sustainable Pace (the idea, nay fact, that programmer productivity goes down past about 40-50 hours of work per week).

The human mind is a remarkable device. Nevertheless, it is not without limits. Recently, a growing body of research has focused on a particular mental limitation, which has to do with our ability to use a mental trait known as executive function. When you focus on a specific task for an extended period of time or choose to eat a salad instead of a piece of cake, you are flexing your executive function muscles. Both thought processes require conscious effort-you have to resist the temptation to let your mind wander or to indulge in the sweet dessert. It turns out, however, that use of executive function—a talent we all rely on throughout the day—draws upon a single resource of limited capacity in the brain. When this resource is exhausted by one activity, our mental capacity may be severely hindered in another, seemingly unrelated activity.

So, scientific study is bearing out what good programmers know implicitly and what great programmers incorporate into their lives. Working longer actually leads to poor decisions and negative productivity; working at a sustainable pace optimizes productivity.

Allan Kelly draws some interesting conclusions about Agile software development methods as related to forming business strategy. The impetus for his post was a piece in the MIT Sloan Review entitled “Should you build strategy like you build software?.”

From Allan’s “Make strategy like you make software?”:

...for companies which use a lot of technology software and strategy are increasingly converging. Ultimately your software is your strategy – so much so that I sometimes imagine software code as liquid strategy.

...many of the practices and techniques used in Agile software development can be applied to strategy formation and execution. McFarland focus on techniques such as small iterations, collective ownership, overlapping phases, direction changes (i.e. refactoring), organising around people not tools and abolishing big up front design.

It is not only software development where managers and companies have suffered from the Illusion of Control it occurs in strategy formation and planning. Strategy formation is an emergent process, in the same way that software design is emergent.

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.

The blog post "How Cognitive Science Can Improve Your PowerPoint Presentations" discusses four ways cognitive scientist Stephen M. Kosslyn offers for creating more human brain-compliant PowerPoint presentations. The basic concepts, however, are likely equally helpful in developing user interfaces.

As mentioned in a previous post, we’re talking more and more internally about user interface and user interaction design. Just came across an interesting resource: the User Interface Design Pattern Library.

We’ve been talking quite a bit these days in the office about user interfaces and interaction design. I came across an interesting post on the Architectures of Control | Design with Intent blog by Dan Lockton, a PhD researcher at Brunel University’s School of Engineering & Design.

In his post Interesting Parallels, Dan draws on unique definitions of interaction design and security (namely, that both are related to shaping human behavior) to tie the two together. He quotes a computer security specialist and interaction design expert to draw the parallel:

“Security is about preventing adverse consequences from the intentional and unwarranted actions of others. What this definition basically means is that we want people to behave in a certain way… and security is a way of ensuring that they do so.”

Bruce Schneier, Beyond Fear

“A simpler way of thinking about Interaction Designers is that they are the shapers of behavior. Interaction Designers… all attempt to understand and shape human behavior. This is the purpose of the profession: to change the way people behave.”

Jon Kolko, Thoughts on Interaction Design

It’s a rare software project that doesn’t require a developer to think about and implement user interfaces or security in some fashion. So it seems immensely useful for a software developer to view himself or herself as a shaper of human behavior, asking questions as a behaviorist to effectively create useful interfaces and secure software.

My friends at Citerus put together a great newsletter. If you don’t mind reading through a little Swedish intro (the content is mostly in English), I’d highly recommend subscribing.

From a recent interview with Jerry Weinberg in their newsletter:

Q: You seem pretty relentless about quality, why is quality so important to you?

A: Because if you don’t care about quality, everything else is trivial. (I call this The First Law of Software Engineering.) You need to ship on a certain date? If you don’t care about quality, you just ship. You need to cut costs? If you don’t care about quality, you just stop when you run out of money. You need to boost morale? If you don’t care about quality, you do whatever your people want. (Oh, wait a minute. What if they want quality, even if you don’t care? You want to destroy a professional software organization. Act as if you don’t care about quality. The professionals will leave, either physically or psychologically.)

So, that’s why quality is so important, not just to me, but to our industry. And, until we start caring, we’re not going to get better. And I know we can get better, because when I’ve worked with clients whose entire business (or people’s lives) depends on quality, they produce quality software. Curiously, it turns out that quality software is cheaper in the end, but if you’re not into long-term thinking, you won’t see that.

We are, after all, Atomic Object…

A gallery of products using radioactive materials.

Because radiation was seen to be new and powerful, at the beginning of the 20th century radioactive material was used in products such as face creams, mineral water and medicine, by equating power with rejuvenation. For similar reasons it was even used in items from spark plugs to condoms.

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.

Read the rest of this entry

I've just now gotten around to posting the materials I've presented at the OSCON and Agile conferences in the last month. The Agile paper discusses what we learned on our first embedded projects; the OSCON presentation focuses in on the tools and techniques we now apply to embedded development.

OSCON presentation

Agile paper + presentation

Rapid Growth is a very cool, weekly online magazine covering the development and transformation of Grand Rapids. They published a short article about us.

“GR software firm’s growth projections anything but atomic“

I just came across a fascinating article written by Alistair Cockburn in 2004. The article is lengthy and fairly academic, but it’s well worth the time of anyone involved in software development.

In his article, Cockburn offers that software is best understood as a game and not as an engineering discipline. His use of game here is in the vein of game theory – i.e. understanding an activity as the interaction of multiple players making decisions to maximize gain.

Cockburn explores the history of engineering and chronicles the shift in understanding of it from primarily a craft to a formulaic discipline. He goes on to explain the inadequacies of framing engineering in this way and details the specific shortcomings of force-fitting software development into an engineering discipline. Rather, he suggests that viewing software development as a game is far more effective at explaining its inherent nature and reaching successful outcomes.

Those familiar with the ideas of Software Craftsmanship and Agile software development will find Cockburn’s thoughts especially intriguing.

“The end of software engineering and the start of economic-cooperative gaming“

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.

Read the rest of this entry

We started working with a really interesting new client recently, Realius. Realius is a new gaming site specializing in Fantasy Real Estate™. We’re their application development team.

Realius’ Fantasy Real Estate games use real-world data to drive the games. Realius has some big plans and cool ideas; it will be really interesting to see how things unfold. A significant update to their first game Price Me Now™ will be available soon. See their website and blog.

The very first post on the Realius blog explains just one of the intriguing values of their approach:

“I wished I could have played with my ideas to better understand the market before cutting the real check. As a result, we are designing Realius Fantasy Real Estate™ games to follow the homeowner life cycle so that we can have fun with real estate and learn in the process of playing games. The premise is – if you are good at Fantasy Real Estate™, you’ll be good at reality real estate.”

Realius’ games rely on real-world real estate data and listings. As time goes on and more games are developed, local search and geo-aware data will become more and more important. Wired magazine has a couple interesting articles on where local search has been and where it’s going: Google Maps Is Changing the Way We See the World & Dispatches From the Hyperlocal Future.

Methods & Tools is a quarterly software development e-publication with a distribution list of 45,000. The summer edition of Methods & Tools is now available. It includes an article on our embedded development approach and tools (the PDF version can be found at the preceding link).