Donn: Wordy Entertainment

I recently came across the (wonderful) essays of Paul Graham while searching for entrepreneurship material. Paul Graham (co-founder of Viaweb (aka Yahoo! Store), essayist, programmer and more) is a big believer in the idea of rapid application development (or at least a variant of it) (it’s also known in is abbreviated form, RAD).

He often advises technology start-ups to release its application(s) as quickly as possible, even if far from perfect, in order to let market forces decide what improvements are to be made (then iterate improvements quickly). Within months of its release, he argues, the initial idea behind a start-up (and the applications/solutions they’re developing) will change very dramatically no matter how solid they seemed to be in the beginning.

I’m not sure why, but my initial reaction to this method of application development was that of scepticism. I suppose it could be that I was feeling — intuitively — that this sort of methodology was haphazard and lacked planning; and in a way, it is (you design only just enough to get out the first release). But what it lacks in planning it makes up for in speedy improvement in the right direction. (Is it just me or do you see the parallels between this and evolution vs. design? Perhaps God created the necessary conditions for the Big Bang, and that was Universe 1.0.)

RADical Examples

Though I hadn’t realised it, this methodology of application development (starting small and with plenty of rough edges) had been used by me plenty of times before. Many times though, it didn’t even have anything to do with application development! Further consideration on this subject allowed me to see that in many aspects of our lives the philosophy behind rapid application development might be applied, such as:

• Drawing (start with circle in middle of blank page with a blank mind, and work from there);
• Web-design (start with prototype layouts, build it, ask for opinions and rebuilt it until the reviews are mainly positive);
• Cooking a meal (new pasta dish “evolves” with every cooking — what works, what doesn’t? what stays and what goes?);
• Writing letters (when I first started work I was unsure of how my e-mails should “sound”, and how to sign off. Over time, I developed my style, and found out what got the best responses and what didn’t — I got rid of the latter, and did more of the former. I wouldn’t have been able to “design” letters in this sense);
• Writing code (yes, I’ve done it plenty of times EVEN when writing code!)

In a sense, rapid application development is much like how you learn anything — you start with unsure, baby steps, and as you gain confidence and skills, you develop a confident walking stride and finally break out into a run. You can design a way to break out into a run first, but it’s that much easier after the foundations have been laid (in fact, I haven’t quite come across anyone who can run but can’t walk). It’s most useful when you’re unsure of what the end product will look like — and for most creative endeavours (life itself being one), it’s difficult if not impossible to have a clear end in mind.

A RADical Case Study

Not too long ago, the fiancée came to me with a data-entry problem. She had thousands of lines of staff leave data that required conversion from MS Excel spreadsheets (done with little data control) into a standardised format (she needed to migrate the data from Excel to a database). Manually, it took hours to do just a few hundred, and it’d have taken her weeks to sort through that whole mess. Wisely, she told me about it (“can’t spend weekend with you, have to work, bla bla bla”) and I decided to see if I could find a way to automate my way out of what I thought should have been a simple problem.

So I told her to send me a few sample sheets and I’d see what I could do. One look at the mess of data and I realised why it took so long for her to do it. There was simply no standard method of inputting the data, and the data was arranged in such a way that though it was (relatively) easy for a human to make sense of, it’d take a miracle to extract the data automagically — just the sort of problem I loved tackling. (Did I mention I once walked on water? (for about 0.01s, before I sank like stone.))

After feeling a little sorry for myself for volunteering, I got to work by analysing the data and understanding the basic structure underlying it. I found that there was, thankfully, some structure behind the data, and that automating something to help with the process would be possible with the magic of macros. I fired up the VBA editor (press Alt-F11 in Excel to see it) and after an hour or two came up with the prototype Leave System 0.1 Beta. At just under a 100 lines of code, it was a quick and simple hack that allowed her to increase her efficiency by 40% (perhaps on Sunday she’d be able to go out with me).

After getting her feedback (and praise, and thanks, and virtual hugs and kisses since I was physically far removed from her location) I got about to seeing what I could do to improve it, which I then sent to her once more. This process was reiterated a few more times, each time bringing more praise (and thanks, and virtual hugs and kisses). During one of these iterations, I actually had the opportunity to observe how the fiancée used my program (I was invited by her mom for dinner… there was crab, kung pow chicken, prawn salad and more… Yum! But I digress.)

The observations I made were probably the most useful of any of the feedback I had gotten (the hugs and kisses were good too, but did nothing for the program). By observing how someone uses your program, you can really again insights into where the program’s strenghts and weaknesses are (it’s almost like knowing how someone feels when you say, “I love you” — priceless). I realised that a function I had included to speed up processing appeared not only to be doing nothing, but was actually hindering progress; I also found that a major bottleneck was the calculation of weekend leaves and the fact that a not small number of leave data were entered as comments instead of being entered into the data fields (– the fiancée looked sad).

These few main issues were fixed the next day. The final version of the Leave System? Version 3.0. Though it now takes almost a minute to run everything (due to loops within loops within loops, and the sheer huge amount of data), and at 400 lines long it’s four times what the initial prototype was, it has increased the fiancée’s efficiency (and her enlightened colleagues ) by (I believe)  at least 70 to 90%.

Thanks to a RADical idea, and the fiancée will be happily in my arms over the weekend.