«« Whoa, it's August 2007 Twisting Rails is Risky Business »»
blog header image
Risky Business? My Take on Early Alphas

It's a bit funny being a Software Engineer these days. On the one hand there are lots of technical details to figure out and on the other -- yes there is another -- you have creative problem solving.

It's easy to forget that while you're making software you're solving a problem, especially if you're a code monkey in the lower layers. It's useful to see the forest for the trees sometimes. The professors at the University of Ottawa did a great job teaching us how to get to the root of the problem at hand, even if the people who "needed" the software didn't even know what the root of the problem was. That's part of what Software Engineers do.

Allow me to go on a short tangent: any creative profession has a technical side that we don't always think about. Music recording and production is extremely technical, as is the audio setup for a live concert. Visual art like painting and drawing is dominated by chemistry. And the culinary arts involves all sorts of science, just ask Alton Brown. Technology supports the art and is a necessary aspect of it even though the artist may not be aware of all of the details.

My return from the tangent reveals that yes, I'm doing my seemingly quarterly blog post on Why Software is Creative Art. Art doesn't come out of nowhere -- it evolves. A painting or song changes over time, even AFTER it is released to the public for consumption. People's perceptions of the art change over time as well.

The problem with software development is figuring out what the hell the problems are. Extreme Programming's (borrowed) take on it is this is to quickly figure out a rough idea of the problem and release a rough software solution early. Then people can use this software, see how closely it solves their problem and provide feedback. The software is then updated regularly using the feedback until the problem is solved in a close enough fashion. The problem isn't figured out at the start, it's a destination.

That's just fine for internal software projects but what about the general public? The problem (another?) is when to release and to whom. Releasing too early and to the wrong people can cause all sorts of problems (more?), including too much feedback and a possible everlasting bad taste in people's mouths that's hard to recover from.

But releasing early has a lot of benefits, the least of which is knowing extremely early if your "brilliant" solution actually solves anyone's problems. If it doesn't you can abandon it early on and save yourself some time and money. If you were developing it in secret and released it when it was done, you (and your investors) would have to trust your marketing mind(s) that your product will sell.


Personally, I like early alphas. I'm still figuring out the best way to release them but I think I'm getting the hang of it. I still consider my Ruby on Rails side projects to be early alphas: fanconcert, Layered Genealogy and my newest creation Hey Heads Up!.

They solve problems I personally have but are also creative outlets. They are my art portfolio. The early alpha releases and feedback I get from people help me turn them into projects that also solve other people's problems. I can do a little bit of mind-reading to guess what people might like -- but every wrong guess costs me time, so I try to limit the impact of wrong guesses. On the other hand, sometimes I'll add a new feature just to see how people react to it.

As you can imagine this kind of organic growth doesn't suit certain kinds of software development. Incorporating feedback introduces a lot of project entropy, so the process used to develop the software needs to be able to deal with it.

The main strategy I employ, borrowed from Extreme Programming, is starting with the big/risky details and moving down to increasingly smaller and smaller ones, limiting the effects of the entropy. A trivial counter-example is if a developer carefully fine-tuned the design and colours of a page on a dynamic website only to discover a few days later that the page was no longer needed. This is wasted effort caused by project entropy.

Software developers know about the risks of early optimization for performance. I would also argue there's a similar risk of early optimization for usability and design. Working out the flow and larger usability aspects first will inevitably lead to an optimal design later. A common strategy is to design mockups first, program second and grab the shoehorn third. Seems riskier than early alphas to me.

A secondary strategy I use is writing unit testing to ensure that the software stays working in the manner in which I expect. If I can be assured that it will stay working, I'm more apt to make changes to it and respond to the feedback I'm getting because I'm not afraid that my project will break. Testing's impact on responding to feedback cannot be understated. Iterating quickly without tests is just asking for trouble.

But unit tests are just as subject to entropy is the project code itself. And just like design, it's possible to test too specifically at early stages. If the specific tests aren't needed any more because the thing they test got axed, it's wasted effort.


So my early alphas are functional but not completely functional, not the complete vision of the project I had at the start of the project. But that vision will change over the course of the project anyway, so what do I care? These alphas are clunky but they work and they solve my problem. As they get filled out with features and stabilize, the usability details and graphic design details can be filled in.

It's like how pictures used to render on the late 90's Internet: at first you saw big blocks of colour, which progressively became more and more detailed until the picture appeared. Technology meeting art.


Posted at August 08, 2007 at 02:30 PM EST
Last updated August 08, 2007 at 02:30 PM EST
Search scope: Web ryanlowe.ca