The Citadel of Sun
Was Sun Microsystems the end of software engineering?
NOTE: Within this text, wherever gender is not key to the explanation, I am using the Elverson ey/em construction of the Spivak Pronouns.
I am a coder. I provide instructions to machines so as to elicit behaviors amenable to the desires of my human supervisors. I have done this since 2007. At each company where I’ve worked, since then, there are managers and sales people who provide specific instructions. As coders, my associates and I write the software that provides the requested capability. From time to time there is the occasional problem as we figure out how to use some new framework but, as a general rule, the request is easily provided and the resulting code takes a week or so to complete leaving the coder available to address some new request.
It’s a fairly routine job with few surprises. The resulting product is generally acceptable although we invariably discover that the sales people hadn’t really thought through what they wanted. We spend a fair portion of our time rewriting large swaths of our software as requirements change leading to routine releases of adjustments to the original requests. That is the process understood by the vast majority of workers we call developers.
My experience of this process began in 2007 after I was laid off from Sun Microsystems. It was a bizarre change from my previous vocation as a software engineer. The difference was so stark that I find it frustrating and disheartening. From time to time I will find myself in a situation wherein a complex problem needs to be solved and I will enjoy a brief time where I feel I am contributing something unique and interesting but once that is done I’m back to basic coding.
In chapter 3 of my recent book, Famine in the Bullpen, I explained working for Sun Microsystems. It was an attempt to describe the experience in a balanced fashion including both triumphs and failures. When I discussed the book at length with Erin, one of my early reviewers, she said that she simply couldn’t believe chapter 3. “You must be misremembering your experience,” she suggested, “You’ve described an engineer’s paradise.”
I had never thought of it that way and so I was concerned that my memory may be tainted. I turned to two engineers with whom I had worked at Sun. I asked them to review my initial draft. When I asked if chapter 3 needed any work, they responded that it described Sun the way they remembered it. So why did Erin, an experienced software engineer and engineering manager, respond with such confusion and doubt? What was so unique about Sun?
I suspect that the primary difference was Sun’s fundamental respect for engineering. Sun made it clear to all employees that there were two distinct career paths: one managerial and one technical. One could follow the managerial path to Vice-President or the technical path to Sun Fellow. You didn’t need to become a manager to enjoy the ultimate limits of respect and compensation available to an employee. James Gosling, inventor of the Java language, was promoted to Sun Fellow. At no point was he expected to give up his engineering vocation and join the management pool.
By encouraging engineers to continue to improve their skills and advance within the company, Sun retained a large cadre of skilled engineers with many years of experience. They had enough seasoned engineers to form an Architecture Review Committee (the ARC) well-suited to the review of all engineering projects within the company and well-suited to assure that such projects were sound and well-conceived. I was a member of the ARC for four years and shepherded numerous proposals through the process from concept to completed project.
For a time, engineering and the profit-motive held equal sway in shaping Sun’s long-term future, with business people demanding new capabilities and engineers tempering delivery times in order to assure that the new product was functional and sound. As profit became constrained at the disastrous conclusion to the ill-handled dot-com boom, business began to predominate over engineering. Sun solutions became more haphazard and less functional. Panicked enterprise followed hopeful marketing ploy until all engineering time was occupied and, in the end, there was nothing left to be done. Eventually, all Sun had was Java, which they had released to the market without a business plan, and the company failed, becoming a dysfunctional appendix to the Oracle corporate body.
So, I’m watching the episode of Doctor Who entitled The Sound of Drums and I hear the Doctor explaining how the supreme and ephemeral world of Gallifrey could produce a being so crippled and malignant as The Master. Those who occupied the planet known as The Citadel of the Time Lords, set out to understand but never to dominate. Their world was one of discipline and internal control. A world of creativity and quiet glory. Each youth, at the age of eight years, was required to look into the untempered skin of eternity. That comprised the initiation into the world of the time lord. Some took it in and became what was expected of the time lord. Some ran away and some few were driven mad by the sheer raw glory of untempered space-time. One such was the vile manipulator known as The Master. As I watched, I found myself reminiscing over a noble citadel of my own acquaintance. I was reminded of my time at Sun Microsystems: a company I respected and served with pride.
At Sun Microsystems, engineering was supreme. That meant research, analysis and discipline. Each engineer was writing code, of course, but everyone understood that code doesn’t resolve impossible problems. Impossible problems were recognized and resolved using engineering method. The Staff Engineer was expected to resolve problems that appeared impossible to the casual observer. That was, in no uncertain terms, what was expected of the engineer. In that company the term architect, so common in more primitive companies, was unknown. Any senior engineer would, of course, develop solutions that comprised complete and seamless systems: solutions that resolved the underlying problem without a gap — what many would call an architecture but what Sun engineers saw simply as problem-solving.
The Sun engineer was called upon to look into the unvarnished reality of the problem and take on the terrifying task of confronting it and resolving it as no mere coder could. I say terrifying because the job of analyzing the impossible and presenting its resolution to a crew of skilled and questioning engineers requires an Herculean level of confidence and control. Engineers on that panel will tear your solution apart. They will question every component. They will dissect and illuminate every error and criticize without mercy.
The skilled engineer will endure this ruthless confrontation and take in and assess every critique, suppressing the emotional response, in order to come to a solution that actually resolves the larger problem. In the end the solution is not the ingenious construction of an ultimate master of reality, it is, as always, the collaborative genius of people working in concert, revealing the amazing mystery of people in their natural state. The community understands what the individual may not.
The process is devastating and inspiring and it requires an understanding of self that goes beyond ego and puffery. Some survive and amplify the experience while some, as in the Gallifrey example, turn to a destructive parody of what is required in which they may prosper without contributing any value to the community. Actual engineering requires an individual of character who is confident in eir understanding of the world but also understands that eir understanding is not supreme. It requires a confidence that is combined with a humility that welcomes correction.
In modern coders, this is not a common trait. There is a tendency to see one’s code as sacrosanct. More importantly, if that code is associated with a larger architecture, that architecture is not to be documented, it is instead an ethereal and deeply spiritual thing that should not be subject to review by mere mortals. The young inexperienced engineer may confront the challenge of review and rebel, turning instead to the comforting refuge of Scrum and Agile wherein the simple process of coding would be respected as the ultimate manifestation of the engineering discipline.
Thank all that is holy for Scrum, a system that eschews the larger architecture in favor of the small incremental step-by-step procedure. With Scrum (often mistakenly called Agile) there are no large problems, only simple features to be tacked on to existing capabilities. Coders as the Lords of Software, pshaw! What insanity! Coders (often flattered with the title software engineer) are called upon to type in the required software without regard to the larger problem.
The terrifying gauntlet of the complete solution to the serious problem is forever banished to the wastes of engineering history. Yes there were once large problems that we were able to solve through a disciplined application of software and hardware but now we simply code stuff up in response to the demands of undisciplined managers. This is why your phone is continually updated but it doesn’t seem to work any better. Coders are constantly tasked with mediocre improvements to existing software without ever being confronted with real problems that people are actually facing.
At Sun, I was regularly confronted with problems that occupied me for days or weeks. I was allowed the time to assemble a team of skilled engineers and propose a complete solution. I brought that solution before the ARC and incorporated their disciplined critique into the overall solution. My team then implemented and proved the solution yielding a new product or product improvement.
We hear of companies that attract young developers with free massages and free lunches. I worked for a company that supplied free beer and wine and encouraged paint-ball competitions through the spacious open offices emphasizing pointless play as an impetus to irrelevant coding. These companies juvenilize the centuries-old discipline of engineering because true innovation is simply not required in order to assure the continued wealth of top corporate management. Simple-minded coding is entirely adequate to the goals of the ownership class. At Sun Microsystems (without free anything) the parking lot was full until 8:00 at night. Those engineers remained because they were fascinated with their projects. They were enthralled and obsessed. They were deeply engrossed in solutions that made them feel fulfilled, that reassured them they were making a difference.
At Sun, engineers felt respected and appreciated. We were criticized relentlessly when needed and consulted deferentially when appropriate. In short, we were treated as adults. I was not a fearless leader but instead a competent comrade playing an important role in a problem-solving community. My friend, Erin, has never had the joyous privilege of applying her unique skills to amazing real problems in our world. She has only been asked to code stuff up and supervise others who are merely coding stuff up. We look to Google as a singular bulwark of engineering acumen only to find that when its engineers begin to rebel against its traditional corporate culture, it made its parental dominance clear by dismissing the naughty developers. Supposed engineering companies demonstrate their control over their developers by assuring that free-thinking is not to be a real component of the process.
Did software engineering die with Sun? My personal experience with my Tesla Model 3 gives me hope that it is still alive somewhere; but, it is certainly not a requirement in any company with which I have interviewed. By adhering to the Sun view that there is an engineering career track I have found myself endlessly solving small problems for small companies with small and often irrelevant visions. My hope of making my mark in software engineering by trying to do it for various companies has proved supremely disappointing.
Sun, by respecting engineering as a process and engineers as a productive community, introduced numerous components of the modern networked world. We used tools within that company that eventually became fundamental staples of the Internet. We introduced the concepts that allowed us to understand the interconnected world in which we now live. It died because management predominated over engineering and, having no management influence, engineering lost. Sun had some great ideas and some stupid ideas, as a complete system, the stupid ideas predominated and it failed. Unfortunately, the good ideas died with the stupid ones. The idea of software engineering gave way to “Agile”, “Scrum” and trivial coding. What is the next citadel of software engineering? What company will conclude that innovation will provide more profit than simple coding? What company will incorporate engineering into its very identity in order to change the world for the better? That company will be the engineer’s paradise and by tapping the inconceivable power of engineering, it will transform the world.
Julian S. Taylor is the author of Famine in the Bullpen a book about bringing innovation back to software engineering.
Available at or orderable from your local bookstore.
Rediscover real browsing at your local bookstore.
Also available in ebook and audio formats at Sockwood Press.
This work represents the opinion of the author only.
