If you’ve missed the VA Smalltalk Forum Europe 2010 in Stuttgart last week, there is at least a chance to take a look at the presentation slides. While we’re still working on an “official” central version location for all the material, I’ve put up some files to our company website, where you can look at them.
My talk was mainly about improving your working style in legacy Smalltalk Projects. Truth be told, there are much more Legacy Smalltalk Projects out there than greenfield projects, even though the Seaside Frameworkl has attracted quite a few Developers into the Smalltalk community.
Legacy here is not a negative term. Many Smalltalk projects are legacy projects, because they’ve been running for more than a decade, fulfilling their business needs and making their users happy. Since there has been a lot of pressure in big corporations towards a “unified platform” (the name may vary in your company), the projects had to survive under really unpleasant circumstances:
- fluctuation of key developers to newer projects
- shrinking budgets
- an aura of being unwanted, old technology
- neverending wishes for new features
In some organizations, this has lead to a very “pragmatic” (this is not the “pragmatic” of the pragmatic programmers movement!) approach to implementing new features and bug fixes:
- touch as little code as necessary
- forget about how it should be done
- ignore all the new techniques like unit testing, refactoring, build automation etc.
A few years ago, this sounded like a good idea, because people would never have to touch the code again, when the system would be switched off a few months later.
Things went different (as they usually do):
- The new projects failed completely or in part, so that they were cancelled or reduced in scope
- The new projects were so expensive that it was decided to couple the old and new systems and keeping the core logic in the Smalltalk system
- The new projects didn’t really stay within their timeline (surpise!) and so the old one is still the only thing the users have. The result is feature creep in both projects, which may possibly lead to one of the above-mentioned consquences in the future. The difference for the end users is very relevant: they never see the new system anyways, but they get the new features in the old one.
At the end of the day, all of this means the Smalltalk projects in this situation are faced with a few problems:
- Bad code stuffed into a once good and clean system (Smalltalk Projects were generally well-staffed and budgeted back in the early to mid nineties)
- Techniques that are common sense today (and, ironically, were invented in the Smalltalk world, like Refactoring and unit testing or automated builds) never got adopted in these projects
- The once highly-skilled team has lost a lot of talent (Most organizations have shot themselves into their knees by forcing good people out of the projects and scaring everybody away from them by officially calling them a dead-end)
- Lots of features need to be implemented and the all the ugly crimes of Software Maintenance that have been committed “for the good” need to be cleaned up now. The reason for this is that the systems have returned to an “open end of life” phase, meaning there is no question that these projects will continue to run for another 5 or ten years or “forever”. This, of course, means you need to handle existing code with a lot more respect than people have done for quite a while
My talk is a short summary of findings around all this. I’ve been helping a number of projects to cope with exactly this situation over the last few years by teaching or coaching and by introducing technigques and tools to make the developers’ lives easier. I demoed a few of the little helpers for coping with typical problems like artefacts that are not under version control and tried to motivate people to use the refactoring browser as a tool for reading into existing code (I’d say Smalltalk is one of the best environments for software archeology).
Another area in which projects have serious problems is configuration management with Envy/Developer and the build process. This is not so much a technical problem but more a problem of fear and misunderstanding as well as a question of complete lack of tools and automation in that area. I’ve shown some of the stuff I’ve implemented for customers to overcome these problems. We’ve implemented a complete set of tools and helpers for code management in Streams and automating builds for a Continuous Integration Environment.
Once the video of my talk is available, you’ll probably get an impression of how much I enjoy working with such project teams. There’s a lot you can achieve with little steps and it’s really motivating to see project teams gaining self confidence back that was lost in-between a lot of frustration and sadness about the ignorance of their own management. And, even more important, it’s a lot of fun pairing with a programmer who discovers the power of the Refactoring Browser and Unit Tests.
So if you like my talk and think your project could use some of the tools and techniques to get back to speed again and if you need someone to scratch the rust from your code and make your project shine again, don’t be shy and contact me.