New Architectural Models for Visibly Controllable Computing: The Relevance of Dynamic Object Oriented Architectures and Plan Based Computing Models

Traditionally, we've focussed on the question of how to make a system easy to code the first time, or perhaps on how to ease the system's continued evolution. But if we look at life cycle costs, then we must conclude that the important question is how to make a system easy to operate. To do this we need to make it easy for the operators to see what's going on and to then manipulate the system so that it does what it is supposed to. This is a radically different criterion for success. What makes a computer system visible and controllable? This is a difficult question, but it's clear that today's modern operating systems with nearly 50 million source lines of code are neither. Strikingly, the MIT Lisp Machine and its commercial successors provided almost the same functionality as today's mainstream sytsems, but with only 1 Million lines of code. This paper is a retrospective examination of the features of the Lisp Machine hardware and software system. Our key claim is that by building the Object Abstraction into the lowest tiers of the system, great synergy and clarity were obtained. It is our hope that this is a lesson that can impact tomorrow's designs. We also speculate on how the spirit of the Lisp Machine could be extended to include a comprehensive access control model and how new layers of abstraction could further enrich this model.

The Wrong Kind of Lean: Over-Commitment and Under-Represented Skills on Technology Teams

This paper reports on results from five companies in the aerospace and automotive industries to show that over-commitment of technical professionals and under-representation of key skills on technology development and transition teams seriously impairs team performance. The research finds that 40 percent of the projects studied were inadequately staffed, resulting in weaker team communications and alignment. Most importantly, the weak staffing on these teams is found to be associated with a doubling of project failure rate to reach full production. Those weakly staffed teams that did successfully insert technology into production systems were also much more likely than other teams to have development delays and late engineering changes. The conclusion suggests that the expense of project failure, delay and late engineering changes in these companies must greatly out-weigh the savings gained from reduced staffing costs, and that this problem is likely going to be found in other technology-intensive firms intent on seeing project budgets as a cost to be minimized rather than an investment to be maximized.