September 14, 2015, we launched a new ERP system, written in Smalltalk, running on GemStone and developed with VisualWorks. The system continues to grow, we keep adding features, and our users are mostly happy.
It got me thinking about my relationship with the company and the project.
Projects have tension between the technical and business needs. The person paying the bills makes the final call and they are being asked to take a leap of faith; they don't see what the developers see. It takes time to build up trust, yet most of the key decisions, like which technology to use, are made at the start of the project, long before the technical team is truly trusted.
In our case we got a lot right: use Smalltalk to deal with unique and complex business needs, use GemStone as the database to avoid the cost of object to relational mapping, use a web interface to avoid fat client issues, and use Seaside to allow for a single technology stack (we're Smalltalk all the way down).
We got a few things wrong. The worst was thinking that an old fat client framework was worth keeping. It wasn't, and I strongly argued against it. But that's a tough call for someone that is not familiar with the code. They see a sunk cost. How could it not have value?
Over time everyone realized just how bad the old framework was, but by then we had invested a lot of time and effort making the domain code run in a new web framework. We're still struggling to remove the last bad bits. But I can see the risk management decision on this: it was scary to agree to throw away the old code and move to something new and unproven. It's self evident now; it wasn't then.
But it made me think: just how relevant is the technology decision, like which language or framework to use? Our users don't care. They need tools to do their job. Management doesn't care. They want IT to provide services at minimal cost. As a Smalltalk team we're very efficient. But so what? A java team would be easier to staff. Development would take longer, but they could get temporary help up to speed quickly to help get over humps. Technical consultants would actually be helpful (virtually none of the ones we've worked with knew Smalltalk).
And it's a general problem to anyone advocating an unconventional technology. Business might invest in a Smalltalk project if they see a return on investment, and if the risk is acceptable. But selling that vision in a world of deafening silence about Smalltalk is tough.
I haven't lost faith. Using Smalltalk allows us to be flexible in ways other teams could only dream of. Things will get a lot better, once we've scraped off the last of the old framework and are able to focus all of our time on building new stuff. I see a future where the development team is seen as a partner is the business. Where our ability to see business patterns and user flows gives us a voice. Where we're not just a cost of doing business.
That's my vision: that Smalltalk projects allow the developers to be partners in the business, since they don't need to wallow in technical minutiae. They can stay in the business head space, so they can add value beyond the code. I see that happening in our project, and I think it's an important part of the story when advocating for Smalltalk.
I am looking forward to the next year.
Simple things should be simple. Complex things should be possible.
I work with VA Smalltalk, on an application that makes intensive uses of events. I don't think that Seaside/JavaScript can ever replicate that. How are you finding replicating the events on the fat client (I assume there are events being used) with Seaside/JavaScript?
ReplyDeleteWe get the 'liveliness' of fat client events with onClick and onBlur ajax callbacks. onClick / onChange trigger a div render that enables things like the Save / Cancel buttons. onBlur triggers a GS call to get domain changes based on the pending update (like when changing a start date adjusts the end date). Each call to GS is RESTful, with only the 'save' action doing a commit. Most of the onBlur interactions are under 50ms; the vast majority under 100ms.
DeleteBut we do have the occasional busy user conflict which we plan to correct with our next big change, which is to move the Seaside code from VW to GS. We didn't do that originally because we needed the VW web servers to support a hybrid web / fat client implementation. Things would have been so much simpler if we'd deployed fully on GS from the start.
That's the kind of refactoring I'd love to challenge a java team to do: move your web code from a web server to an active database. I figure it will take us about three months.
Big fan of VA... still the best looking dialect out there, next to Dolphin.
Interesting read. I am in a somewhat similar place, with s/Java/PHP/g
ReplyDeleteMy current take is to use Pharo for managing key business data areas and make a REST service in front of them.
Not perfect but moving all to GS is just too huge to swallow for some people.
Great story!
ReplyDelete"And it's a general problem to anyone advocating an unconventional technology."
This is true of anything that isn't Java, C#, Python, C++, R. Businesses are very conservative. They generally like to play it safe.
So it's not just Smalltalk that faces this problem but also Clojure, Elixir, Julia, Kotlin, Rust, etc. Every new technology must push whatever advantage it has in order to overcome management resistance.
Yes, I know, Smalltalk isn't "new" but the same narrative applies.
simple and useful Thanx...
ReplyDeleteoutsource invoice processing services