Innovation in Software

In the last few weeks, I’ve been evaluating source code I’ve written over the last year under closed source commercial agreements. I did this partly to try and look at what I did wrong and learn from those mistakes at a business level and technical level, but also to find out if there are common themes to anything I was working on that I could extract to make my life easier in future.

What I found shouldn’t surprise most people. Everything I did was about building forms, allowing data from those forms to be collected, and then looked at in some way. Every project looked like this:

• Define a form
• Build form
• Users input data into form
• Save data
• Look at data

Sometimes I would define/build the form and deliver the app, but at least two apps included the ability for users to build forms them (basically, survey software).

In fact, all web sites with UGC follow this model at some level – a blog engine is a form for a post, followed by the display of entered data in a particular way or set of ways. YouTube is a set of forms to handle file uploads followed by some data processing, and then displaying that content.

That’s quite interesting, because we have so far thought about web applications being custom little pieces of code in almost every case. Rails and similar frameworks enforce this model however, and make it easier by doing a lot of the heavy lifting involved in describing those processes. However, ultimately all we’re doing is putting lipstick onto relational databases. If that’s all we’re doing, surely there is a quicker way of doing it?

I was thinking that each of those stages in each application is already defined somehow as a real world business process we want to map into software. Why can’t we find a way of being able to quickly define a business process in code, and then just generate an application based on that definition?

It seems I’m a few years behind in my thinking. Business Process Management (BPM) is a mature area of development with a gazillion standards out there and it would seem XPDL is the XML-love of choice for this crowd. Digging further, I found something even cooler for the Rubyists amongst you: OpenWFEru nicknamed ‘Rufus’ amongst developers seems to have most of the heavy lifting done for you. The example looks promising.

This is interesting for me, because I have to build a couple of pieces of software soon which really are understanding workflows within teams, and I’d rather spend more time reading 19th-century books on political philosophy (hey, everybody’s got to have a hobby).

As a result I’m trying to work out how to hammer this into those projects. If I can find a way of being able to take the “I’ll look after the forms for you” aspect of Rails with the ease of defining workflows found in OpenWFEru and coupling them could you define a bunch of schemas and a workflow and then generate a better scaffolded Rails application? Would the controllers be able to mature over CRUD and do something more useful? Or could you build a CMS in Rails that uses user-generated workflows to allow for quickly hacked-together custom applications? It’s an intriguing bunch of thoughts…