Entries from May 2006 ↓

One of the things I love about Ruby is that every week I discover something new and magical, and just keep on learning. This article at artima developer is one I’ll be reading closely this weekend, not least because it shows how to implement a simple LOGO interpreter as a DSL.

Nice to get a name-check from Jonathan, a fellow London rubyist, who’s overcome his angst at not using ruby on rails fixtures.

Someone should rewrite these excellent smalltalk books with a Ruby slant.

From Smalltalk with Style (there are some 126 guidelines in this book, most of which apply directly to Ruby)

Guideline 26: Do not comment bad code – rewrite it.
Guideline 79: Write small methods.

A couple of weeks ago, one of our board members asked me for some starting points to understand agile development, specifically to assure himself whether it could work on larger and more contractually complicated projects.

Clearly I’ve been banging the agile drum loudly. Here’s what I sent him – I hope others may find it useful:

The obvious place to start is the Agile Alliance – which is an umbrella group for agile practitioners. Of particular interest to you may be their list of corporate members

To give you some flavour of agile development, it’s worth looking at some of the experience reports given at last years’ agile conference. You’ll see some evidence of large-scale deployments and get a feeling of the industry heavyweights that are beginning to explore the agile space – including Microsoft and IBM.

ThoughtWorks is a well-known agile consultancy in the UK and has achieved agile projects on a very large scale. There are case studies available on their website.

I’m biased with regard to ThoughtWorks – having worked there briefly – but other structured approaches to agile can be found from DSDM – who are a UK company that licenses their software method. Worth also taking a look at Scrum – whose best representatives in the UK are Conchango. They have some interesting case studies and a useful overview white paper

Agile is certainly not just for small companies: Forrester Research, March 2004, Liz Barnett wrote “Approximately two-thirds of large organisations working with Forrester are adopting (overtly or inadvertently) some form of Agile process for their internal application development efforts.”

Hope this helps as a starting point. One thing I would stress is that an agile approach can require much more discipline than a traditional software development approach. As I mentioned, I’d be more than happy to show you how this works in practice within the Reevoo development team.

Just some example metrics from today’s work on the Reevoo codebase: we’ve checked in code and run all tests 8 times. We’ve released to the live servers, flawlessly, twice. The revieworld codebase has some 952 separate tests run against it after every code integration and the reevoo codebase has some 634 tests.

Each developer – there have been 2 here today – will have run the whole test suite at least 4 or 5 times, and individual tests many times more than that.

We’ve completed two business ‘stories’ – one for Guy and one for Richard. And they’re released, live and generating business value. That’s to my mind the benefits of an agile approach.

Gems of wisdom from Alex Sharp’s Smalltalk By Example (free download!)

“A stupid method is one that is so obvious that it doesn’t need any documentation. The problem with documentation is that it makes a method longer, so if you have a method that is long enough to need some serious documentation, you compound the problem by making it longer and less able to fit on a screen. Not fitting on a screen, it is less readily grasped by a programmer. The ultimate compliment of a method is ‘that method is really stupid.’ ”

and

“It’s not always easy to come up with a great method name when you are looking at the method itself. It’s when the method is being invoked, when you are doing the message send, that you’ll get the best idea of how good the name is. If it makes sense in the context where it is sent, then you’ve probably got a good name. So, while it’s okay to name the method when you are writing it, be prepared to go back and change the name after you use it in other methods.”

So much of this book applies to Ruby as well, even if Smalltalk is coming back… again. Just gsub!(/Smalltalk/,’Ruby’).

A few posts on DSLs and Ruby have popped up recently. I find myself agreeing somewhat with this contribution from Maurice Codik:

In the long run, I don’t think the main value from DSLs will come from allowing non-techincal users to encode business rules, but instead in helping programmers make their programs more DRY.

To my mind there are two big wins from DSLs, and almost everything else is wishful thinking. The first is the ability to hide implementation details – often called encapsulation – and to express exact intentions.

Let’s take one of the poster children of DSLs: SQL. A typical, but basic, SQL statement could be SELECT people.name,company.name FROM people,companies WHERE people.company_id=companies.id AND people.role=”manager”;

Nothing too taxing there but a host of implementation detail has been hidden from me – I don’t care how the data is stored – whether on disk or in memory – I don’t have to describe to the database how to present the data, or how to perform the set arithmetic or how to use its indices to improve performance.

– Even so, some implementation details have leaked through – what’s with all this id=id business? Wouldn’t it be more expressive if I wrote something like: SELECT people.name, RELATED company.name WHERE people.role=”manager”. We can dream. –

DSLs are the epitome of the search for implementation hiding and clear expression of intention over process – some people characterize it as ‘declarative’ over ‘imperative’ coding.

Be warned, lunatics will try to convince you that you still need to know how the database works in order to use it effectively – that encapsulation is pointless and even dangerous. To these people, I’d point out facetiously that my Grandmother thinks electricity is a kind of spooky magic, but she still knows how to switch on the kettle.

The second big win is related to encapsulation and to my mind is even more important. DSLs remove an impedence mismatch between business and code by offering a commonly understood and comparable expression of intention. What I mean by that is that the closer the code is to expressing the intentions of the business, the more easily it can become a shared resource that both business and development can draw on. In fact, I’d go further and say that it helps break down the distinction between business and development – as an aside, can you imagine anyone suggesting a distinction should exist between accountancy, another specialised art, and business?

Let me take that illustration further: you have to learn a certain language to understand a business’ profit and loss report – what are accruals, expenses, gross margin, net margin, etc. By learning that language you can understand the business more deeply. No-one in a large business – no-one in their right mind, anyway – would ask a developer, a marketeer, a salesman to create the profit and loss reports – that’s an accountant’s job. But part of their job, if they’ve done it right, is to make that picture of the business something that everyone who invests, works in, or has some interest in the company understandable.

DSLs allow developers to communicate the way a business process is modelled in code to a non-developer. And, this requirement to communicate through your work is something that has been sadly lacking in most company development teams I’ve had experience of, but accepted in other departments – sales, finance, marketing, etc.

DSLs give us a chance to work towards it – but don’t expect that you’ll get effective results by claiming ‘everyone is now a developer!’. It makes as much sense as saying ‘anyone can now file our annual tax return’, and it misses the two big DSL wins – implementation hiding and communication.

Even seasoned IT professionals occasionally give blank stares when I tell them that we program in ruby, using ruby on rails.

What with a recent endorsement from Martin Fowler and this graph – spotted on Jason Huggins’ blog – it seems that ruby and rails are truly gaining the popularity they deserve.

James Edward Grey – of Ruby Quiz fame – asserts that unit testers get more chicks. (via yup.com).

Slow Tests are a coding smell, Gerard Meszaros says: “The single most common cause of Slow Tests is interacting with a database in many of the tests. Tests that have to write to a database to set up the fixture and read a database to verify the outcome (a form of Back Door Manipulation ) take about 50 times longer to run than the same test running against in-memory data structures. This is a special case of the more general problem of using slow components.”