Niall: "I find it hard to explain things that I've learned from experience, rather than via theory". The first time he was faced with a manager who was pitching Java as the new end all, be all, he needed to explain why Smalltalk had value. This presentation is his latest attempt at an answer - why it is that Smalltalk gives business value. He gives these talks because he would like to become more convincing, and he would like to help others become more convincing. So, he's trying to put together a set of examples that show why Smalltalk is more productive. He gave his last 'Value of Smalltalk' presentation at ESUG (PDF) three months ago, using a real commercial system as example. Now here is another, with a second real commercial example system.
The presentation was delayed when Niall's system suddenly decided that bringing the presentation window back up from the taskbar didn't mean the audience would get to see it :) An audience volunteer provided a notebook, USB flash drives were used, and things proceeded; provided some light amusement for us.
Smalltalkers often call statically-typed languages, 'Stiffly typed languages'. This is not just abuse. (Yes it is abuse but it is abuse with a point - pointed abuse.) When Niall started in IT he bought into CMMI notions like 'Coding from a spec is like walking on water - it's easier when it's frozen'. This is for those who think that they are clever enough to get it right first time. Painful experience taught Niall he wasn't. And that his team mates and managers weren't either.
Agile says, First make it run, then make it right, last make it fast. Accept that we are unlikely to be correct right off. First make it run (i.e., wrong). Last, make it fast is just the same point. Making it fast often means making it stiff - you want to introduce hard to change things late (if at all).
Back to languages - C#, Java (etc) - stiffly typed. They are like a bad employee - hard to get them to do anything at all, harder still to make them do the right thing. The type system is the ultimate up front optimization - it reverses the agile idea - first make it fast, then make it right, last make it run last. Super process if humans could do it but they can't.
An example - an insurance system. The system had to handle personal insurance products throughout their life-cycle. Used by sales people, back office staff, analysts, and others. There were frequent changes in business logic (to improve, to deal with new law/regulations, etc). The cost of change is a key issue.
The rate of change drove them to build a meta-data system. It grew to handle hundreds of insurance products. Once it was in place, it was easy to add new ones. It was handled by a team of about 10 developers. After a merger, they saw other teams with other approaches. One (larger) team had 700 hand-coded forms that dealt with only 9 insurance products and the rest were not much different. In theory, the merger was eager to acquire the recognised IT efficiency of the Smalltalk-using team. When the teams met to decide how, the political compromise solution was to reuse the design, but rewritten in C#: let us all be equal(ly ignorant of the language, as we've none of us written a line of C# before). (Niall said it a bit more tactfully and stressed this was just for background; he was here to talk about the positive value of Smalltalk, not the negative value of many mergers.) However it did provide language comparison experience.
Niall talked through why Smalltalk's pure object model makes it far easier to build meta-data systems. C# and Java stand in the way. It was very hard to come up with patterns that mapped the existing design onto C#. C# and Java are designed against meta approaches. But the harder problem was psychological. "You can take the developer out of Smalltalk but you can't take the Smalltalk out of a developer". Unfortunately, the converse is also true; none of the non-Smalltalkers could resist the static-typed language saying 'don't do this' about the meta-patterns. The upshot - if you need to deliver a meta-data-driven system, then expect to fail in C# or Java.
As well as getting delivered in the first place, the insurance system gave rapid delivery of new products. In the Smalltalk system, changes were delivered fast, in the others much more slowly - and it also required a larger team. As for scalability - low hundreds of products versus 9 was the worst case comparison but not unrepresentative !!
Lastly, Smalltalk lets you reengineer. Any complex system will need this over time. Niall talked through what happened when the system's chief engineer suddenly realised he could use the meta-system to show the user visually what data in the UI was impacting a selected business logic rule. He knew the users would love it but the system hadn't been written for it and key data wasn't captured together. It took him just one week to complete a complicated custom refactoring that rewrote code scattered through the 5000 class, 100,000 method system.
(Smalltalk is also better when you need to refactor, i.e. migrate, data; any complex system needs that too. Niall had no time to talk through the example on that thanks to the computer problems at the start; catch it in Orlando).