Innovation in Software

For a long time, I’ve had a problem explaining exactly why software engineering doesn’t work like other kinds of engineering. One of the issues I’ve had is trying to find the wording needed to explain that programmers don’t really build anything, and that to manage building software like building a bridge makes no sense. I couldn’t quite put my finger on the right words though.

Until now.

Jack W. Reeve’s essay on ‘What is Software Design?’ is the best work I’ve seen to date on the subject. He argues – convincingly – that programmers are designers, architects, draftsmen at a drawing board. We don’t build anything: compilers, linkers, interpreters do that for us. He points out how flawed an idea it is to produce a design document that can never truly represent the details of how the software will work, because it is an abstraction of an abstraction. The only accurate design is the software source code itself.

What’s more, it makes sense that in the same way that an architect can build a model, which can be turned into a few more detailed drawings, which can then be turned into engineering drawings, it makes sense to start all software development with a set of mock-ups which are then turned into a UI (say, static HTML) which then become plugged together with code. It’s like building a skyscraper by defining what the bits ‘users’ will see will look like, then working out how the nuts and bolts will hold it together: exactly what an architect does.

His essay dates from a time when the best language available to programmers to express their design was C++, and he argues that C++ helps his model of ‘design as code’ along nicely. It was the best language for the job because as an object-orientated language, it allowed an expression that most closely resembled how we abstractly thought about objects and data in the real World. Since then, of course, things have moved along a little bit.

I would argue today that Ruby is the best design language we have available to us. I claim this, because I actually find it easier and quicker to express an abstract design – which in turn can then execute – through Ruby than I do through a diagram or notation or pseudo-code.

At this point you might be thinking “yeah, right, whatever!”, but this isn’t some idle boast, I eat my own dog food.

The other day I needed to clarify a design point with another programmer via e-mail. I needed to express a HABTM relationship being used as a way of listing ‘exceptions’ to a ‘everybody/nobody’ flag stored in a model. The details aren’t important, but I considered for a moment the very best way of communicating this. I considered drawing a UML diagram. I thought about a quick sketch with some boxes, I considered a little pseudo-code. I then remembered that the programmer I was discussing this with could code Ruby, and maybe if I just developed a few stubs with some comments he’d get the idea.

Five minutes later, I had not just produced stub code. I had some migrations that would build the tables needed in Rails, and I had a few methods I was proposing adding to a model. It was untested, and some DateTime handling code would need a little fleshing out, but I’d discovered it was just quicker to write the code than it would be to write the comments explaining what the code would do. I actually ended up writing a software design in my mail client, that I could copy and paste over into a code editor and with a little bit of expansion and testing, get running.

In other words, the perfect design notation seems to have been discovered – it’s not UML that generates stub C++ in a CASE tool, or some formal design notation. It’s Ruby that just, well, runs. It is perfect because it is the perfect balance of programming language and design notation.

So not only was Reeves right in saying that source code is the best detailed design possible, that we are designers at heart, that programming languages that work at an abstract level are a step in the right direction, that formal design tools are useless and pointless, but he was even right that eventually we’d produce a programming language that was just a compilable design notation.

We now have that tool and its name is Ruby.

UPDATE: Two separate comments – each without seeing the other, as I didn’t approve them until this morning – suggest that LISP is a better design tool than Ruby.

It is worth pointing out that Ruby is kind of a grandchild of Lisp because it inherits so much from Scheme, itself a dialect of Lisp.

So is Ruby just another Lisp dialect? No. Whilst borrowing aspects of Lisp, it is more closely related to Smalltalk in terms of its object-orientation. It also borrows from Python, Dylan and CLU. It uses the best of all of them – Lisp included – and makes something better.

Also, there is another important part of Ruby that Lisp (and Smalltalk to be fair) do not yet have: an easy way to rapidly produce production-level, deployable, useful software. I can build a web application in Ruby – thanks to Rails, or Camping – in relatively little time compared to 10 years ago in PHP or Perl. I suspect, although haven’t researched it fully, that to do the same in Lisp might take me a little longer.

Ruby has many of the great features of Lisp baked in, but many of its own bolted in to boot. What’s more, the design ethos of Ruby is its strongest point: Ruby is designed to make programming pleasurable. When you enjoy writing code, you write more of it in less time, and with fewer bugs. Lisp might be fun for those who enjoy it, but I agree to some extent with Larry Wall on this one: it “has the visual appeal of oatmeal with fingernail clippings mixed in”.

If you like Lisp, I suspect you will love Ruby, and you’ll find yourself more productive in it. Either way, I’ll concede that for some people in love with it, Lisp is as useful to them as a design language as Ruby is to me. We’re both lucky, we both know we are, and we’re both a step ahead of the C# and Java guys.

I still say Ruby rocks more though. :-P

UPDATE 2: Changed link to the PDF to point to one held at the official home and authorised version of these PDFs. Thanks to Daniel Read for pointing out my error in directing you all to a pirate copy.