This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: The Value of Smalltalk
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
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 come up with such an answer - this presentation is his latest attempt at an answer - why it is that Smalltalk gives business value.
Like to become more convincing
Would like to see other become more convincing as well
So, he's trying to put together a set of examples that justify the arguemnt that Smalltalk is more productive. The presentation was delayed though - Niall's system suddenly decided that it was not, under any circumstances, going to run Acrobat :) An audience volunteer provided a notebook, USB flash drives were used, and things proceeded. provided some light amusement for us.
Static languages? Stiffly typed languages - this is abuse, but it's pointed abuse. So some notions that seem to be popular:
CMMI: Coding from a spec is like walking on water - it's easier when it's frozen - works for those who think that they are clever enough to get it right the first time
Agile - First make it run, then make it right, then make it fast
Accept that we are unlikely to be correct right off
First make it run (i.e., wrong
Last, make it fast - often makes 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 - it's hard to get them to do anything at all. The type system is the ultimate in up front optimization - it reverses the agile idea - fast first, run last.
an example - an insurance system. So 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 huge thing.
The second system is a value and risk management system. This is a very hard problem. The value is in getting the system to actually arrive on the market first. You don't dare sell what you can't price - you can't hold risk that you can't manage. How well your system does this determines the volume of products you can actually manage. The goal:
The ease of a spreadsheet, the scalability of a system
It runs in three modes:
Batch, overnight - comes up with data for analysts to use the next day
Interactively during the day to allow traders to price/sell things
Over weekends, lots of housekeeping to keep things straight
This enables rather large revenues for the bank - you can look at this success story to get more details, and at this link for an earlier talk by Niall about this
So what's the value of Smalltalk? These are domains that change. It was clear that the system would have to deal with dynamic domain models. The infrastructure is hidden from the financial developers:
They don't worry about persistence
All objects can walk their graph to assure data integrity, audit (etc)
Behavior is in VisualWorks and Gemstone
All financial objects can value themselves
All financial objects can walk their graphs to explain their values
Domain behavior is in VisualWorks only. Gemstone is a memory extension
It took 1.5 years to get the meta-models correct. It enabled the traders to make lots (and lots) of money. The thing that really enabled this is that Smalltalk exposes it's meta-model - everything is an object, there are few reserved words. The type system does not stand in the way - the developers can simply do what needs to be done. This worked because it evolved over that first year and a half - it simply was not possible to get right the first time.
The insurance system - the rate of change drove them to build a meta-data system. It grew to handle hundreds of insurance products. Once it wa sin place, it was easy to add new ones. It was handled by a team of about 10 developers. After a merger, they were faced with another team that had 700 hand coded forms that dealt with only 9 insurance products. In theory, the merger was in patrt to acquire the leading edge advantage of the Smalltalk insurance products. Politically, the larger team won and forced a re-write in C# (a political compromise).
What they discovered was that Smalltalk's pure object model makes it far easier to deal with meta-models. C# and Java stand in the way. It's very hard to come up with patterns that would map the existing design onto C#. C# and Java are physically designed against meta approaches. The upshot - if you need to deliver a meta-model driven system, then expect to fail in C# or Java.
Rapid delivery - The risk management system survived the entire ParcPlace fiasco because of the value that it delivered. The system let its users do things that could not be done otherwise. The traders recognized value, and would not allow that value to be removed from them - and in fact, they continued to get new value delievered to them.
A while back, a new financial object appeared on the market. Evrey client of every bank wanted it in volume. For a decently long interval of time, only one system could deliver it - this one. This increased market share and gave them relationships with new clients. For a period of time, the bank was a monopoly player in the space. The competitors got there far, far later with spreadsheets and large numbers of staff.
Likewise, the insurance system ensured rapid delivery. With the existing system, changes were delivered immediately - the replacement C# system delivered them much more slowly - and it also required a larger team. The Smalltalk system was also faster...
Scalability - this (risk management) system consists of 10,000+ classes. The entire system is delivered - including development tools - to the traders. The system has been able to overcome performance issues by being able to examine issues in production with the development tools. The production images are actually development images, and allow developers to work on the live production systems when critical performance issues arise.
Fixed a problem where things slowed down on Fridays only by being able to work on the production systems - impossible to reproduce in test
Brought new products online ahead of other businesses
Since Smalltalk is cross platform, they were able to move to new platforms quickly
What about the need to redesign/refactor? Any complex system will need this over time. The refactoring/rewrite tools available in Smalltalk enabled something that is much, much more difficult to do in a stiffly typed system.
I've just refactored the stuff above, cut out the duplications, removed the unnecessary comments, changed specifics to generalities, improved the structure, etc. Here's the result:
> I've just refactored the stuff above, cut out the > duplications, removed the unnecessary comments, changed > specifics to generalities, improved the structure, etc. > Here's the result: > > "My language is better than your language." > > Vince.
Of course that is impossible.
Java is the one true language, destined to last forever. No other language can come anywhere close to it. So why bother reading about other languages.
In fact, since Java is the one true language, why not outlaw all other languages? Make it illegal to use them since they are inferior.
The text above appears to summarise two talks I've given this quarter, one at ESUG in Kothen and one at the CST User Conference in Frankfurt. Each talk used a (different) real commercial system to illustrate how certain languages features feed into business value. The even briefer summary offered in Vincent's post ('My language is better than your language') seems just a bit too brief to be of any use. For those who like really short summaries I offer the following as the shortest that has any actual content:
---- 1) If you need to deliver a meta-data-driven system, certain OO languages give you a lower risk of failure than other OO languages.
2) If your concerns are simply rapid delivery, scalability and/or the ability to reengineer, these same languages offer advantages over others.
3) The 'certain OO languages' are those with dynamic typing, late binding, a fully-exposed meta-model, few reserved words and classes as first-class objects. ----
I speak of 'OO languages' above; Paul Graham's excellent article making similar points about LISP is at http://lib1.store.vip.sc5.yahoo.com/lib/paulgraham/sec.txt (and could also be rather too briefy summarised as 'My language is better than your language').
I also happen to believe that, with the debatable exception of certain scripting domains, the more mature Smalltalk is generally a better commercial choice than Python, Ruby and other languages with similar features (other things being equal), but that's by the way (and might have an element of 'the language I know very well is better than the languages I don't know as well' :-)). Certainly, the points are relevant to the whole dynamic v. static debate, the language chosen being a (particularly good) example.
For anyone who wants more than the above summaries, lengthy notes for the first talk are on page 33 of http://www.whysmalltalk.com/events/nfrESUG2004report.pdf. Notes for the second talk will appear on the www.whysmalltalk.com events pages shortly as part of the CST User Conference report.