ProAm software development

I have been considering this article, which looks at the increasing prevailence of amateur software developers, and how they are demonstrating the ability to produce innovative software that consumers actually need, rather than want. Two examples I have is Irfanview (a picture viewer), and Terragen (a landscape terrain genenator - check out the images here, and just go "Oooooo" - then go to Luc's pages, and take a look at what he's doing with version 2. Don't worry...I'll wait...).

Firstly, my attitude to this software (recommend to everyone, at any opportunity) made me realise that building software that people need (or love!) drives its own success, regardless of how "fancy" or feature-filled it is. Because it solves a problem, becuase it makes my life easier or better, it doesn't require any marketing because I promote it. Lesson One: Build software that people need and it will likely be successful.

Secondly, development of successful ProAm software is heavily reliant on its user community to drive development. I was taught early in my career that software development functionality should be driven 80% by the users (of which 50% are those small, minor tweaks which can make such a massive difference to peoples interaction) and 20% by the developer, who often has a broader understanding of the marketplace and can anticipate functionality early on. Its interesting to see something like Terragen, where this model holds true, in comparison to many of the other "professional" software houses where the 80:20 becomes 20:80. At Talis, we certainly used to fall more heavily into the latter category, and I'm gratifyed to see a real drive currently to get "closer to our users". This is coming about in several ways - our more agile development approach which places the customer at the centre of the process, our ongoing overhaul of the enhancement/defect process, our internal review of customer relns processes, our forums and RSS feeds, etc. We're starting to reap some benefits from this already, and I can only see these growing. Lesson Two: Listen to your users, and build to meet their needs.

Thirdly, something I touched upon just then, is development method. ProAms are not weighed down by the cumbersome development practices which have grown up in the professional domain for a variety of reasons I haven't time to discuss. Which is where the more agile or XP methods come in; user-focused, delivery-focused, function-focused. To give an analysis example, in a 4 hour period recently and working with two product managers, we generated enough raw requirements (read "stories") to provide such a shared understanding of what we wanted to build, we could have started an agile development the very next day. And I didn't need to formalise these requirements any further, to cross-reference, and categorise, and model, and specifiy, and review, and get sign offs, and...you get the picture. I can do any of these things if it adds value, but now I ONLY do these things if it adds value. The process doesn't "make" me do this. Lesson Three: Drive the development process, and don't let it drive you.

Final Lesson: It can only be that you should give Irfanview a try, and go and have some fun with Terregen. And that lesson says it all ;-)