This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Learning about Smalltalk programming Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

Boy do I feel sorry for Richard Demers right now!

The poor guy has slaved away at a fantastic new domain model for Bottom Feeder with a heap of tests to back up the functionality. But likely he's starting to realise that that isn't what a Smalltalk program is made up of.

It's the whole thing, not just the model. It's how it interacts together, not what it represents. "Living Objects" comes with a cost, and that is to evolve, you must do that - evolve the code, not replace it.

I like to call my work farming. I plant some seeds, water them, let them grow. If I want to change it, I prune it, or if I'm feeling really wild, I'll dig it up and plant it somewhere else. But, to start again you have to cut the tree down.

If you don't cut the tree down and try to plant some seeds right next to the tree, the tree will hog all the sunlight and the new plant will not grow.

Now I'm not saying what he's done is a complete waste of time. No, in this time Rich has become very knowledgeable in the domain and has probably learnt much of what I said above. He's done some recategorisation work previously too, which helps others get involved. What he's doing is migrating behaviour from the view to the model - this makes it easier to plug in a new model later.

But rich applications have a very large API set. So what really needs to be done is a lot of pruning. Prune away branches that are about to touch the power lines and grow them in a new manageable direction. In other words, evolve the current system in to the shape you want the new system to look.

This isn't the sort of lesson that is taught at schools. Most schools teach you to write programs from scratch. This is so unrealistic in the industry that it's a joke! But any way, when you introduce a programmer to your system, his first instinct is likely to re-write it. The may not tackle the whole system, they'll pick something that is reasonably well understood - then do it in a way that isn't quite in sync with what the application needs. I know this well as I did it when I was learning Smalltalk.

So! There, my first bit of sage advice.. I think.