The why lies buried in my youthful encounter with objects in the early eighties. Discovering objects was like an epiphany, suddenly a lot of the techniques I had found to work well were put in a framework and got names. The excitement of reading the 1981 Byte issue on Smalltalk was immense. Objects were exactly what I wanted for my software development! In that excited mode I convinced my manager that we should switch to objects as soon as possible because it would save us so much in the future. I painted a rosy picture in the sky about how software could be developed in the future of reusable classes. Developing an application would largely consist of picking the right classes, and voilá! I got the budget easily.
Objects did provide a significant benefit and 10-15 years after the Byte issue on Smalltalk they had therefore become mainstream. Though it is still easy to point out how out industry is struggling with complexity I do believe objects provided a significant value in allowing us to handle much more complex problems. However, the vision of assembling an application out of components never happened. What happened instead is that most large object oriented programs turn into a big ball of mud that is so entangled that it becomes impossible to find reusable components in the haystack.
Thirty years after the Byte issue on Smalltalk the world looks very different. Open source software has fundamentally changed the nature of software. Open source seems to have achieved the quest of reusable components because today these open source projects are reused on a grand scale.
However, when I struggle with integrating different software packages and their myriad of dependencies I am not so sure anymore. Badly documented, missing crucial metadata, extremely sensitive to their environment, complex configuration, incompatible versions, avalanches of logging, tons of XML, and mysterious crashes, then I know we're not there yet, it is still way too hard. There should be a better way! How can we better leverage open source projects so that these projects are easier to use together?
The model we envisioned in the eighties was plug an play, the way we can go to the department store and get drills, nuts, fasteners, and bolts from different vendors that work together because they use standards so they work together. This is the dream that kept me going for the past decade. OSGi is the only software standard that provides a substrate on which reusable components can flourish. Though OSGi has not reached the grail, it is arguably closer than anything else.
I am convinced that the next big step in software is the OSGi model: bundles collaborating through substitutable services. However, just like the mainstream procedural developers had to adjust their ways to take advantage of objects, today's mainstream developers have to adjust their software to take advantage of OSGi (and not run head first against the enforced module boundaries). Some developers reject OSGi because they deem it too complex but what is not too complex if you do not understand the why? Procedural developers also felt that objects were way too complex and wasteful. An investment in a technology is always required to get its benefits.
After thirty years the vision of reusable components has come tantalizing close with OSGi. However, to go that last mile we need your help to make OSGi the rock-solid foundation for the mainstream software developers.
Peter Kriens
P.S. As always, these are my personal opinions and are not necessarily aligned with the OSGi Alliance
Great post Peter! I was fortunate enough to be a student of the late 1980's and early 1990's, getting served a healthy diet of objects, classes and collaborations. I consumed everything to do with objects, from authors such as Tom Love, Rebecca Wirfs-Brock and Kent Beck. I was convinced that this was the next big thing! And it was.
ReplyDeleteI studied Smalltalk at university and then upon graduating, rode the Smalltalk wave that swept across the industry on both sides of the Atlantic in the 90's, cresting with Java and what we know today.
We were taught that foundries of objects would appear and reuse would be the rule rather than the exception. Of course it never really materialized and I have forever pondered the reasons why.
When I discovered OSGi in 1999 I was excited that this was the missing piece of the puzzle to make reusable objects a reality. But over ten years later I feel like I'm still waiting. I have many thoughts on why this next step in becoming an engineering discipline has remained just out of reach. Most importantly, it is not due to a lack of technical advancement; OSGi has proved that. But instead we are being held back my ourselves and our inability to realize and rationalize the economics of reuse.
Don't get me wrong, building reusable components is still very hard. It's much harder than building software for the proverbial ball of mud. But it's still far harder to convince a business to invest appropriately in objects, especially when the rewards are not realized, or even measureable, in the short term. We're so focused on the short term that we're holding ourselves back from ever digging ourselves out of the software tar pit. So hurrah for OSGi, since it's bringing us that much closer, but boo for us for not having the courage to invest sufficently such that reuable components can be a reality.
I guess I need to wait another ten years.
We need people to see what we try to achieve and do the investment. I hope we will be able to take advantage of the law of increasing returns and that adoption will attract adoption. I've been called an optimist but I think the goal is worth the effort ...
ReplyDeleteThanks ... Peter Kriens
I too am optimistic, Peter. We just need to: 1) Teach people how to build components, and 2) Teach organizations how to fund components. Developers are not that savvy when it comes to component development, for example, they fail to understand the importance of a component life-cycle, and how to write dynamic code. In fact dynamic scenarios are often described as too hard, or not necessary, both of which are untrue. The tougher issue is teaching organizations how to fund components since they are so myopic in terms of funding and rewarding people. People behave in accordance to how they are rewarded, and they're not rewarded for building components, sadly.
ReplyDelete