System Evolution

Sort By:

Kode Vicious Plays in Traffic:
With increasing complexity comes increasing risk.

There is no single answer to the question of how to apply software to systems that can, literally, kill us, but there are models to follow that may help ameliorate the risk. The risks involved in these systems come from three major areas: marketing, accounting, and management. It is not that it is impossible to engineer such systems safely, but the history of automated systems shows us that it is difficult to do so cheaply and quickly.

by George Neville-Neil | April 8, 2020


The Best Place to Build a Subway:
Building projects despite (and because of) existing complex systems

Many engineering projects are big and complex. They require integrating into the existing environment to tie into stuff that precedes the new, big, complex thing. It is common to bemoan the challenges of dealing with the preexisting stuff. Many times, engineers don’t realize that their projects (and their paychecks) exist only because of the preexisting and complex systems that impose constraints on the new work. This column looks at some sophisticated urban redevelopment projects that are very much part of daily life in San Francisco and compares them with the challenges inherent in building software.

by Pat Helland | March 24, 2020


Borg, Omega, and Kubernetes:
Lessons learned from three container-management systems over a decade

Though widespread interest in software containers is a relatively recent phenomenon, at Google we have been managing Linux containers at scale for more than ten years and built three different container-management systems in that time. Each system was heavily influenced by its predecessors, even though they were developed for different reasons. This article describes the lessons we’ve learned from developing and operating them.

by Brendan Burns, Brian Grant, David Oppenheimer, Eric Brewer, John Wilkes | March 2, 2016


Abstraction in Hardware System Design:
Applying lessons from software languages to hardware languages using Bluespec SystemVerilog

The history of software engineering is one of continuing development of abstraction mechanisms designed to tackle ever-increasing complexity. Hardware design, however, is not as current. For example, the two most commonly used HDLs date back to the 1980s. Updates to the standards lag behind modern programming languages in structural abstractions such as types, encapsulation, and parameterization. Their behavioral semantics lag even further. They are specified in terms of event-driven simulators running on uniprocessor von Neumann machines.

by Rishiyur S. Nikhil | August 18, 2011


Custom Processing:
Today general-purpose processors from Intel and AMD dominate the landscape, but advances in processor designs such as the cell processor architecture overseen by IBM chief scientist Peter Hofstee promise to bring the costs of specialized system on a chip platforms in line with cost associated with general purpose computing platforms, and that just may change the art of system design forever.

Today we’re going to talk about system on a chip and some of the design issues that go with that, and more importantly, some of the newer trends, such as the work that IBM is doing around the cell processor to advance the whole system on a chip processor.

by Peter Hofstee, Michael Vizard | July 14, 2008


The Long Road to 64 Bits:
Double, double, toil and trouble

Shakespeare’s words often cover circumstances beyond his wildest dreams. Toil and trouble accompany major computing transitions, even when people plan ahead. To calibrate “tomorrow’s legacy today,” we should study “tomorrow’s legacy yesterday.” Much of tomorrow’s software will still be driven by decades-old decisions. Past decisions have unanticipated side effects that last decades and can be difficult to undo.

by John R. Mashey | October 10, 2006


A Conversation with David Brown:
The nondisruptive theory of system evolution

This month Queue tackles the problem of system evolution. One key question is: What do developers need to keep in mind while evolving a system, to ensure that the existing software that depends on it doesn’t break? It’s a tough problem, but there are few more qualified to discuss this subject than two industry veterans now at Sun Microsystems, David Brown and Bob Sproull. Both have witnessed what happens to systems over time and have thought a lot about the introduction of successive technological innovations to a software product without undermining its stability or the software that depends on it.

by Charlene O'Hanlon | October 10, 2006


Longhorn Ties Platform Apps to Core Operating System:
Will Microsoft’s New OS Be a Developer’s Dream-Come-True?

Call it all-tools-for-all-things-Microsoft. That’s the way I’m beginning to think about Longhorn, Microsoft’s next-generation operating system, expected in 2006. The operating system will herald more than just the transition of mainstream computing to 64 bits. It will mark the emergence of a new, multifaceted programming model. Breaking away from traditional computer science taxonomy, where operating systems stood barely removed from the hardware abstraction layer, Longhorn will be more like a multi-tentacled container for a wide range of administration and application tools.

by Alexander Wolfe | October 25, 2004


Silicon Superstitions:
Ask yourself if what you’re doing is based on fact, on observation, on a sound footing, or if there is something dodgy about it.

We live in a technological age. Even most individuals on this planet who do not have TV or cellular telephones know about such gadgets of technology. They are artifacts made by us and for us. You’d think, therefore, that it would be part of our common heritage to understand them. Their insides are open to inspection, their designers generally understand the principles behind them, and it is possible to communicate this knowledge - even though the "theory of operation" sections of manuals, once prevalent, seem no longer to be included.

by Jef Raskin | January 29, 2004


The Truth About Embedded Systems:
Embedded systems are different in several ways from other software environments.

Embedded systems are different in several ways from other software environments. The hardware they run on is often resource-constrained in terms of both memory and processor cycles, but still these systems must respond in realtime. They control the brakes of cars, the flaps of airplanes, traffic signaling systems, medical equipment, and other life-critical devices. Programming as if someone’s life depended on it is a new concept to many systems engineers.

by George Neville-Neil | April 1, 2003