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. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

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.