Looking back on my past blogs and other content, I’ve noted a number of recurring themes. While the blogs are tagged, I thought it might be useful to provide a one-stop index to the various themes.

• Past Predictions. I’ve made a lot of predictions over the years about what was likely to happen in the future. Enough time has passed that we can judge whether these were good or not!
  • Software, the Last Handmade Thing
  • The next thirty years (Predictions made in 2012)
  • IoT: What Happens when our Machines are Smarter than We Are? (#what-happens-machines-smarter)
• My Career. Interviews and presentations about my 40+ year career in Software Product Development, management philosophy, and related areas.
  • Agility, Leadership, and Innovation: The Journey of Globallogic CTO Jim Walsh (#Data-dojo-interview)
  • Career Presentation to National Leadership Youth Forum (#NYLF_career_overview)
  • Thirty Years in Software: Part I (Prehistory – before 1982)
  • Thirty Years in Software: Part II (August 1982 – July 1992)
  • Thirty Years in Software: Part III (August 1992 – July 2002)
• Digital Transformation
• GenAI
• Management & Team Building
• Agile and the Software Product Development Process
  • Scrum and Innovation, Part I
  • Scrum and Innovation, Part II
  • Scrum and Innovation, Part III & IV Outline

Early in the decade of the 2000’s, I was at a startup developing a predictive analytics solution. Our objective was to host the advanced “decision analytics” engine we developed as a SOAP-based web service using a business model that was then called “ASP” (not to be confused with the Microsoft technology of the same name). ASP, standing for “application service provider”, is what we would today SaaS (“Software as a Service”) or even by the rather unfortunate acronym AaaS (“Analytics as a Service”).

At the beginning of the decade words like “Agile”, “VoIP”, “WiFi”, “Open Source” and “Smart Phone” were just beginning to enter the engineering mainstream, while words like “Cloud Computing” had yet to be spoken—at least outside advanced R&D labs. Still, at this 2001 startup we used technologies that even today would be regarded as mainstream: Java, Struts, SOAP, Tomcat, SVG, and an XML decision model representation to name a few. Our server OS’s were Windows and (if memory serves correctly) Linux. Our development methodology was the then brand new Agile methodology, “Extreme Programming”. Even our telephone system was recognizably “modern”: the then-new Cisco VoIP Call Manager.

If I were to make the same technical choices today that we made back in the early 2000’s, I doubt if any but the more technically aggressive people would be very concerned. All the technologies we selected back in 2001/2002 are still very much with us and in widespread use ten years later.  However I would not get the kind of throughput, scale, flexibility and rapidity of development that the current technology choices make available to me. In choosing the older “proven” technologies, I would be making in some sense a “safer” choice, but at the same time I would not be leveraging the best technology that’s available to me today.

To implement a similar “Analytics as a Service” product concept in a similar business situation today, I’d make totally different choices. My guiding principal would be to build a product ready for the next decade, and to take maximum advantage of current technical advances to give me the “biggest bang for the buck”—the most benefit for the least engineering effort. Prominent among these technologies would be Cloud and bigdata technologies. These would give me massive scalability and reliability basically “for free” in terms of programming effort. 

My first step—as it was then—would be to gather together the smartest people I know and brainstorm our options. Today, these options would no doubt include an elastically scalable Cloud deployment model; a NoSQL distributed data store such as, for example, Amazon DynamoDB or Cassandra; RESTful interfaces; JSON; perhaps the “R” programming language (http://en.wikipedia.org/wiki/R_language) for some aspects of decision modeling; and maybe Python Pyramid or node.js for the interfaces and d3.js for the graphs. There are lots of good options, and I learned long ago that the best technology decisions are made by listening to the smartest people you know in the space.

This real-life example is a good illustration of how I’ve experienced technology evolution in general over the last thirty years. In 2012, Java, Open Source, XML, SOAP, VoIP and the other technologies we selected a decade ago seem like good, solid, well-validated choices. However when we made these selections back in 2001, they were seen as “cutting edge” and risky. In fact some people in that startup were acutely uncomfortable with these choices at the time.  And they had some valid reasons. Operationally, you could not go out and easily hire people in 2001 that already knew SOAP, for example—this was brand new technology. Even Java was still fairly cutting edge in the early 2000’s compared to, for example, the C++ language that I’d worked with a decade before at Borland and Rational. And because it was newer, Java programmers tended to be harder to recruit and more expensive—another argument that was used against the “new” language.

It’s a similar situation today with the more “modern” Cloud-centric technologies I mentioned above. While each of the technologies I would consider today is well proven by highly successful companies in large-scale deployments, the mainstream is still uncomfortable with many of these choices.  Even where the “modern” choices solve a real need, whether or not a given team designing a new product can and should embrace the latest technologies will end up depending heavily on the non-technical factors of the project. In some situations, the skills and inclinations of the current development team may limit the options that can be realistically employed. Schedules, politics and other non-technical considerations may also limit a team’s ability to try a new approach, however much they would like to.

In cases, though, where the advantages are compelling and create real value for the product, my advice is that you should embrace the newly proven paradigms wherever possible—even if it’s a little scary and the team needs to stretch. This is not to say that it’s a good idea to embrace every new idea that comes along—that’s more a question of “fashion” than of substance. But where a new idea emerges that offers real value, and where other serious and thoughtful people are using it to successfully solve real-life problems, then it’s worth your while to learn about it and take advantage of it. I can predict with some confidence that a product making appropriate use of the new best-of-breed Cloud technologies has a much better chance of still being “current” when I write my 40^th anniversary blog in 2022 than one written using technology that was cutting edge in 2002.

We certainly did see language and tools evolution in the last decade: Java grew “fatter” with J2EE / JEE and then got “thinner” again as the Spring / POJO paradigm grew dominant. Ruby on Rails emerged as a popular and highly productive choice for web applications.  Python—though with us since long before the 2000’s—rose to prominence as a first-class product development language. And perhaps most surprisingly to those of us who have been around a while, javascript—once considered by engineering snobs as a second-class language for HTML hackers—has emerged as a first-class language both on the client side and the server side. Though not novel conceptually, the emergence of distributed NoSQL databases to store unstructured data (text, for example) and non-relationally structured data (such as graphs, trees and key-value pairs), together with the tools to take advantage of them, is also of incredible importance. And the SOA / ESB (Service Oriented Architecture / Enterprise Services Bus) / Service Orchestration paradigm rose to prominence in various industries and is still widely used in the Enterprise Software space (though no longer very frequently in the ISV space).

While in no way minimizing them, from my own personal perspective in product development I would classify the changes on the language and tools front in the decade of the 2000’s as more evolutionary than revolutionary in nature, compared to past decades. There are other recent changes, however, that have been very much revolutions. In terms of disruptive changes that have occurred in the software industry over the last decade, my short list would include:

1. Outsourcing
2. The move to browser-based systems and ubiquitous mobile service, leading to a “flattened” planet 
3. Hosting and the elastic scalability paradigms of the Cloud (Big Data, compute elasticity) and the democratization of massively parallel compute paradigms like Map/Reduce to take advantage of it
4. The Agile software development paradigm and the widespread availability of powerful, ubiquitous and free (or nearly free) software and people who know how to use it
5. Smart devices, tablets and “physical world” aware devices (location-based services, etc.)
6. Self-authoring and publishing of content on the world-wide web (facebook, twitter, blogging, “web 2.0”)

Outsourcing

By the beginning of the 2000’s, I had already worked on several distributed development projects—a memorable one being the Japanese Kanji version of NeXT’s Software’s NeXTSTEP Operating System (3.1j). I’d also worked with outsourced providers of specialized services such as software CD-ROM duplication and distribution. Still I had never done actual software product development outsourcing, and indeed was very skeptical of the whole concept. From my point of view at the time, software development was challenging enough when everyone was in the same building. Putting the barrier of timezones and oceans between teams seemed like a recipe for failure in the late 1990’s.

I had encountered outsourcing as a concept in software development back in the 1990’s in two contexts. One was the use of specialized firms that focused on a particular and usually highly technical task—for example, Intel / Windows video device driver development. These companies tended to be US based (or later in the decade Eastern-Europe based) and small—maybe 20 people or so. The other type of outsourcing was generally done for IT departments of large companies. They used staff in low-cost geographies—with India being the most popular—to augment in-house programming staff for some relatively low-end (technically speaking) special-purpose work—for example, for “Y2K” conversion. 

(For those of you not familiar with “Y2K”, there was an issue around date arithmetic with the turn of the century from 1999 to the year 2000, the year otherwise known as “Y2K”. Many programs that represented the year as a two-digit string or integer such as “95” assumed that the numerical value of the last two digits of a later year (for example, “99”) was always greater than the numerical value of an earlier year (for example, “93”). This assumption was no longer true across the century boundary since year “00” occurred after year “99”, not before. Uncorrected, this assumption would cause accounting and other date-dependent systems to fail spectacularly on New Year’s Day, 2000. Writing at a short distance of just over 12 years after this event, it’s hard for me now to imagine that the world could ever had developed so much software with this fatally flawed and short-sited assumption—but we sure did!)

The Y2K problem led to the explosive growth of the India IT outsourcing industry because once the tools were in place, the inherently date-critical nature of the problem offered only one solution to compress implementation timelines: add staff. While plowing through millions and millions of lines of mostly COBOL code was an enormous undertaking, the fix to each individual instance of non-compliant code, once found, was generally straightforward. This allowed large numbers of relatively low-skilled programmers to be effective at finding and fixing Y2K problems. As a side effect, the India outsourcing industry was launched.

Where there are large numbers of relatively low-skilled programmers, some fraction of these people will prove to be very smart and, over time, become high-skilled. Other high-skilled, smart and generally more senior people are needed all along to supervise and guide the lower-skilled ones, and educational systems were put in place to produce and grow more talent. While outsourcing remained mostly an IT-centric phenomena in the early 2000’s, the capability also rapidly developed to the point where some Indian outsourcing companies were able to field Silicon Valley caliber resources—first in the testing, support and maintenance areas, and later in product development.

This era is where my own involvement with outsourcing began. By 2002, I had left the “AaaS” startup I described above and was working at an enterprise software company that had already made the decision, before I joined, to try outsourcing. My team was selected for the trial. I did not mind this at all since it would grow my team—in fact, nearly double it in time. I was on the vendor selection committee—quite interesting in itself—and we picked a vendor based in Hyderabad, India. I recall asking one of my Indian colleagues at the time which major Indian city Hyderabad was closest to; I had never heard of it before. My colleague looked at me rather strangely, saying: “Hyderabad is a major city—it’s the forth largest city in India and has about six million people.” So I got a map and looked it up: Hyderabad is in the south of India, about 550 km north of Bangalore by road.

I don’t think my general lack of knowledge about India was unusual in the US at the time—I think it was fairly typical. Certainly we in the software industry had worked side-by-side with Indian immigrants to the US for many years—but we talked about software, not so much about India the country. For me, one of the first experiences I remember with an Indian colleague was in the early 1990’s. One of my fellow managers was an older (than me at the time) Indian gentleman who had been in the US for about 5 years when I met him. I remember one day he took me aside and said “Jim, may I make a personal statement?” I was rather puzzled, but told him to go ahead. He said “You know, I think you are the most “American” person I have ever encountered.” I didn’t know how to react to this statement, but chose to take it as a compliment and thanked him. My Indian colleague continued: “You know, just a few years ago, I would have had no idea how to deal with someone like you; I would have run screaming from the room. I take it as a real success and it shows me how much I’ve grown that we can work together so well.” After this I really didn’t know what to say, so I mumbled something vaguely positive and quickly changed the subject.

My ignorance of India in the early 2000’s was such that given the surprisingly low cost per head (relative to Silicon Valley at the time) I had real and (as it turned out) totally unfounded concerns about whether or not the people on my outsourced India team were exploited workers. This bothered me so much that I got on a plane and went over to Hyderabad to check. As it turns out, I need not have worried. I found happy, well-treated people whose physical working conditions were actually better—literally—than those I had experienced at the San Francisco-based AaaS startup I had recently left. I found out that the wages that were paid to them permitted them to live comfortably middle-class lifestyles by the local standards—far better, in many cases, than their parents. Their jobs were considered prestigious and offered a great deal of upward mobility.

As for the caliber of the people, with one or two exceptions (which I fixed), I found myself thinking that if they were in the US, I would hire these people.

Fortunately I was not in a situation where I was ramping up in India in order to lay off in Silicon Valley—this time. But in Hyderabad I found myself thinking: Would it be the right thing to do to deny these great, hard-working people employment for the sole reason that they live in India and not the US? To me, at that moment, that seemed like the most “un-American” thing I could possibly do. 

A few years later, I joined another Enterprise Software company specifically to help them establish an offshore development center in India.  Looking back on it I actually did not have a lot of practical experience with outsourcing at the time I joined. However with my one success I still had far more experience than anyone around me—and more than most in the industry at that time. This time our center was to be in Bangalore—which I had heard of. Over time, it grew to about 180 people and ended up “owning” the development, end-to-end, of two core product lines with only a limited on-shore presence in both areas. We also later opened a second development center in Eastern Europe that was highly successful in developing portions of our highly technical analytics product line.

Today it is almost unthinkable for a software product company to NOT have an offshore development component. Even startups often begin with an outsourced team, either immediately or shortly after creating their first prototype and getting funding to develop a product. This reliance on outsourcing is because the demand for speed of development has grown higher while spending on engineering is capped by the expense ratios of the best-performing companies—who generally all use outsourcing.

Another key driver of outsourcing is the relative lack of availability of skilled local resources. In 2012 I learned of a job posting in the Silicon Valley area that offered a salary of $160k per annum for an iPhone iOS developer with 2 years experience. While you need to wonder how long such a job would actually last (Days? Weeks?), at the same time no sane company would make such a posting if the skillsets they needed were readily available. Shortage of talented, skilled engineering labor is a huge limiting factor for technology companies in the US—and an important driver for outsourcing. If experience has taught me one thing, it’s that there are smart people everywhere, throughout the world. As long as that’s true, and as long as economic growth is not uniform globally, there will clearly be a need for outsourcing.

One side effect of outsourcing is that in the 2000’s I became a frequent global traveler. I had always done some degree of business travel, some of it international, but nothing like what I experienced in that decade. Our youngest child turned 18 in 2003 and soon after left for University. While we missed her enormously of course, not having children at home enabled me to travel extensively, sometimes bringing or meeting my wife along the way. In the early 2000’s I traveled first as a relatively early customer of outsourced product development services; later in the decade I was traveling because I had switched to the provider side. There were several years during the decade when I spent more time traveling overseas than I did at home.

I actually don’t know how many international trips I took and how many miles I travelled in that decade, but it was a rare year in the 2000’s when I didn’t fly the equivalent of multiple times around the globe. My frequent flyer balances on more than one carrier range up into the high hundreds of thousands—and those are just the miles I haven’t yet used.

Technology flattens the world

One of the most striking facets of traveling around the world in the 2000’s was how easy it was, in historical terms. There’s nothing technology can do about timezones, which are built into the shape and size of the earth. There’s also no way of changing the fact that even traveling near the speed of sound, it’s a long way from my home near San Francisco International Airport to Bangalore, Delhi, or Eastern Europe. But short of that, international travel in the 2000’s imposed relatively few inconveniences beyond the long plane rides and the fact that, when I got there, my colleagues and family tended to be asleep while I was awake, and vice versa.

By 2012 many of the technologies that made convenient travel feasible became so commonplace as to seem mundane, but they very much changed the face of business travel over the last decade, mine included.

On the everyday living side, browser-based banking and bill paying services meant that I did not have to come home anymore just to pay bills—which, prior to the early 2000’s I would have had to do for a few bills at least. This, together with direct deposit of my paycheck into my bank account, enabled me to be away from home for literally months at a time, which I sometimes was. The global interconnection of Cash Machines (known in the US and some other places as Automated Teller Machines or ATM’s) meant that my normal debit card from my bank “at home” could be easily used to get local currency from any cash machine in the world. My Visa, MasterCard and American Express cards were accepted world-wide, meaning I did not need traveler’s checks to pay for food or other living expenses while traveling. While we aren’t conscious of it very often, all of these are enabled by software and telecommunications technologies.

Similarly, all my work could be done over the internet. I actually don’t need to “be” in any specific place to do work—I can work as effectively and with the same access to tools and information in a café in Vienna Austria as I can in my office in San Jose California. Even my office landline automatically forwards calls to the mobile phone in my pocket. Other than to be in physical proximity to the colleagues who at any given moment happen to be in GlobalLogic’s San Jose office, there is absolutely no reason I can’t be halfway around the world and do the same work.

This has not been true for very long, by the way. If you’ve been following this series you may recall that as advanced as Rational, NeXT Software and Apple were, in the 1990’s I had to be physically or logically plugged into the corporate network to access certain tools and files. I needed a dedicated ISDN connection to “work from home” on my X-terminal at Rational, and a VPN connection over dial-up or ISDN modem to remotely mount my home directory when working from home at NeXT (theoretically possible but painfully slow—it was easier to work offline and email files back and forth). Today, every corporate tool I use is either browser-based or installed on my laptop, tablet and in some cases on my smartphone as well. Even my work email and file storage is browser-based (Google Apps). I don’t need to use VPN or any other network connection technology, enabling me to work exactly the same way—with the same access to tools and information—from the garden of my Silicon Valley home or a hotel in Bangalore as I do in from my office in San Jose. In fact I don’t even need to use the same machine or type of device—the bulk of my files are either stored on-line or automatically replicated between my devices.

Of course the bigger picture is that what is true for me as a business traveler is the same thing that has enabled product development outsourcing to be effective: With current technologies, it literally does not matter where you do your work. We will always need to account for the impact of timezones on real-time communications and the human imperatives behind face-to-face communication and relationships, I believe. But my original concerns about outsourcing back in the 1990’s are addressed by today’s technology: Even if we’re in the same building or campus, unless you and I are literally face-to-face, we’re now using exactly the same technologies and communication mechanisms as we would use if we were on opposite sides of the planet. In the latter case, the corridor between our offices is just really, really long. That’s how I’ve come to think of it.

Another technology that was essential for my international business travel is the email-enabled mobile phone. The fact that my business associates or family members could always dial the same number and my mobile device would ring wherever I was in the world, without my caller having to know where I am geographically, makes today’s flexible styles of travel possible. My associates and I may be in the same building today and on different continents tomorrow. Yet we can consistently receive our messages and make our calls as we travel, without having to explicitly alert any centralized system to re-route these communications. We take this for granted today, but the amount of infrastructure, standardization and legal / financial agreements that were required in the industry to accomplish this seemingly simple task is mind-boggling.

Not to say that mobile devices are perfect for travel, even today. For a number of years in the 2000’s I was a Blackberry user. Even when more advanced phones became available, the Blackberry had a compelling advantage: international data roaming was cheap and unlimited—a flat rate of $50/month, as I recall. For someone who was mobile as much as I was—and pre-iPad, mind you—being “always connected” anywhere in the world and being able to read and respond to my email on a pocket-sized device was a compelling advantage.

Voice roaming rates were not standardized, however, and in fact they were quite expensive. I recall that on my first visit to India with my new Blackberry, the data roaming was indeed cheap, but the voice roaming charges came to nearly $2,000 USD over a three-week trip! On my next trip, I acquired an Indian mobile phone with an India-based carrier for use when I travelled there, and thereafter avoided the roaming charged entirely. I still used my Blackberry for email, though!

Hosting and the Cloud

My previous decade’s extensive business travel was made possible—or at least much more effective—by the technologies that provide location-independent services for banking, cash, communications and on-line applications. Outsourcing, too, was also made effective by location-independent delivery of services and information over the internet.

This same location-independence trend—when applied to compute resources—gave us first hosted services and then (quite different) the Cloud.

The wish to co-locate compute resources with high bandwidth internet connectivity gave rise first to the “co-location” center, and then the concept of hosted services. People gradually realized that they did not have to have computing resources literally within the walls of a building they owned in order to control those resources. With virtualization providing the means to do it, a further step was taken when people realized they did not even need to own the physical hardware their applications were running on. The ownership of “virtual” machines that ran on top of the hardware gave nearly as much control, and with infinitely greater flexibility, than owning the machines themselves. Out of this realization, the cloud was born.

Invented in 2006^[1], the cloud made possible a new style of programming and a new scale of applications that can address the needs of the whole planet. That sounds like hyperbole, but with roughly a billion users—about half a billion of which use it daily—facebook alone touches roughly one seventh of the world’s population. And that’s just one site. About one third of the world’s population has internet access.  When we talking about developing applications at “internet scale”, the cloud and it’s accompanying “big data” technology is a necessity.

Equally remarkable to the development of cloud technologies themselves is the fact that so many of these technologies have been made available for free as “open source” products. Giant companies like vmware, HP, IBM and many others are practically falling over each other to give us powerful, free software to create and enhance our own cloud infrastructures. Other giants such as Twitter, Yahoo! and Google are inventing and giving us powerful “big data” (10 TB up to many petabytes and beyond) analytics services such as Hadoop and Storm to process extremely large data sets, unstructured information, and streaming data. 

While not entirely altruistic—improvements are for mutual benefit, including (and sometimes especially) that of the giver—there is no question that these gifts of software to the development community are far-sighted and extremely beneficial. Their benefit is not just to developers but to everyone who buys or uses software. The availability of free technology of this power and scope is completely unprecedented in my experience and, I believe, in the history of computer science. The effects of free cloud and big data analytics software will be extremely far-reaching, beyond what we can currently foresee.

One thing I am pretty sure of: We are currently in a “golden age” of software development. I’m not predicting that things will get worse—in fact, I think they will continue to improve—but there is no question that as developers and as users we have never had it so good in terms of choices and price. What is possible and practical now is so immense it’s hard to convey. But the convergence of mobile technology, big data, cloud and new software development and interpersonal communication paradigms are propelling us forward to a very exciting future.

Self-authoring and Publishing

The fact that you’re reading this “blog” shows that you are well aware the world has changed profoundly over the last ten years through the ubiquity of self-published media. At the beginning of the decade, technical people were able to author and post web pages with personalized content with relative ease and at relatively low cost. What we couldn’t have done, though, is read the musings of approximately 31 million fellow bloggers—that is the number of people blogging (that is creating content like this) in the United States alone. Blog readership is even larger—over 300 million individuals read the blogs hosted on just one popular site (wordpress)^[2]; there are many other sites which host blogs as well.

We are all encountering similar explosions in self-published content in videos, social networks, e-books and everywhere we turn.

Many of us saw the technical feasibility and value of “browser-based authoring” of Web content very early. For example, my team made remote authoring a key feature of the “Web Catalog” system we developed at NeXT and Apple way back in the mid to late 1990’s. In that system, a user could remotely create, merchandise and deploy a new Web Catalog entirely through a Web Browser—which was very cool for the time.

Many saw the technical possibilities for user-generated content almost as soon as the browser was invented. In fact, Tim Berners-Lee created the original web browser so that people could easily share their technical papers and discoveries with each other. Still most of us—and certainly I myself—ended up being very much surprised by the intensity with which the world embraced the opportunity for self-expression provided by social media. I’m still stunned that over 30 million people in the US alone author blogs—that’s one in every ten people! And even more than that number produce other forms of internet content, such as facebook posts and tweets.

From my perspective and from a somewhat technical standpoint, the key aspects of social media that give it tremendous power are ubiquitous access and the asynchronous nature of the communication. 

• By ubiquitous, I mean that anyone with appropriate permissions can see social media posts. This offers a potential audience to the authors of content, large or small, which motivates them to produce it in the first place. For content consumers, ubiquitous access gives them the possibility that they will discover material that is relevant and meaningful to them, however specific their interest. Specific interests may include the activities of your friends and family. Or perhaps it may be some rather specialized field of interest, like lace-making or folk dancing, which may only be shared by a small to microscopic percentage of the population. Ubiquitous access (plus good search capabilities) offers at least a possibility that people with very specific interests can find each other and perhaps widen their circle of knowledge, friends and interests. Among other things, this has enabled marketplaces and businesses to flourish even if they cater to a very limited and distributed population—pipe smokers, handcrafters, or historical re-enactors, for example.  The ability to bring like-minded people together to share information and form a market has implications for the products and services we buy in the physical world as well as the virtual one—mostly, to my mind, for the better.
• Asynchronous access means that content which is authored at one point in time may be read at a completely different point in time. Dialogs can last days, months or years between responses while still retaining context. The impact of this asynchronous access means that you and I don’t need to schedule a time and place to meet to communicate ideas—I can do it when it works for me, and you can do it when it works for you. This has the effect, among other things, of erasing time and distance. The fact that I am in California’s Silicon Valley in the year 2012 as I write these words does not mean my potential audience is local, or that it needs to be in same room or be on-line at the same time. Once I post this you can read it (or not) at your convenience in your timezone, and neither one of us needs to care about where we are and when we are posting or reading.

I see social media as one of the more profound phenomena affecting global society today. By connecting people who previously thought they were alone with a particular experience, social media is both re-invigorating specialized interests and allowing people to make common cause around social issues that trouble them. One recent example of social issues is “bullying”—that is, a set of children teasing or physically harming another child because he or she is different in some way. According to a recent report I heard on the news, bullied children and their parents previously felt very isolated, but with the advent of social media they have realized other children have the same experience. This realization has led these children and parents to get media attention focused on this problem, and to address it by school reforms and legislation.

There are many such examples of social movements arising from the connections made through social media. A profound one, of course, is the downfall of various regimes in the Middle East by individuals connected through social media such as Twitter.

1. The Agile software development paradigm 
2. Smart devices, tablets and “physical world” aware devices (location-based services, etc.)
3. Self-authoring and publishing of content on the world-wide web (facebook, twitter, blogging, “web 2.0”)

Agile

Another trend that began in the early 2000’s and has continued is “Agile” software development. Certainly the speed at which new software is being produced has grown many-fold over the last decade.  

^[1] While just about everyone now takes credit for the invention of the cloud—I’ve seen claims dating back to the 1960’s—I date it here to the launch of Amazon Web Services with EC2. AWS and EC2 clearly define what we mean today when we speak of “the cloud”.

^[2] http://www.jeffbullas.com/2012/08/02/blogging-statistics-facts-and-figures-in-2012-infographic/

NOTE FROM 2025: I didn’t complete the section on Agile back in 2012, but distributed Agile development has proven itself to me to be the most effective way to do distributed development at scale. The “trick” is that individual teams of, typically, 6-8 people need to be either co-located or in compatible enough timezones to allow real-time collaboration. Depending on people’s sleep patterns and means of communication, that may or may not require geographical proximity. But real-time contact for the bulk of the working day is key to the success of a given team. Within that constraint, different teams can be located anywhere, with collaboration between teams co-ordinated through mechanisms like scrum-of-scrums, SAFe, and so on. I have found this to be effective across continents for teams up to many hundreds of people in size. I expect that even though GenAI will radically transform software development, the essence of the Agile process will still drive development in this next GenAI-driven development era; see my Whitepaper on the subject in the Media section.

This series, written for my then-30th Anniversary as a professional software developer in 2012, consists of the following parts: “pre-history” (before I began working professionally in 1982), 1982-1992, 1992-2002, this blog (2002-2012), and my predictions for the next 30 years, from 2012 through 2042.

From a computing perspective, the 1990s were recognizably more “modern” than the 1980s. Much of the technology we as software engineers use every day today—Ethernet, C++, the Java programming language, the Windows operating system, email and the internet, graphically rich interactive development environments (IDEs), hand-held smart devices—all entered widespread use in the 1990s.

In this next installment of my blog series, I will touch on the evolution of mobile phones and personal digital assistants; email and the world-wide web; operating systems; and languages, processes and object orientation during this decade. You can find my previous blogs on technology from the 1980s and earlier at their respective links.

Mobile Phones & Personal Digital Assistants

Mobile phones actually did exist prior to the 1990s, but they were so expensive to purchase and to use that few people had one. In 1989, a Motorola MicroTac phone cost $2,495 (about $5,000 today), and the monthly service charge was about $500/month ($1,000 today). CEOs, stock traders and the very wealthy used these devices, but not the common person—or even engineers. It was very unusual in the USA to have a mobile phone until the late 90s.

It wasn’t until around 1997 that I acquired my first mobile phone, a Motorola StarTac with carrier Cingular (now AT&T). This is only fifteen years ago, which seems pretty recent to be obtaining such a fundamental technology—but again, I was actually a pretty early adopter. Few of my colleagues at Apple had a cell phone at this time, and this one was seen as pretty cool. As I recall, my StarTac was a TDMA phone and cost about $250 ($350 or so today)—not so very different from a topquality phone today.

There was no fixed price rate plan, either; everything was charged per minute of use. The minutes were fairly costly, maybe $0.10 or $0.20 per minute of “talk time.” Still, being a parent with young teenage children at the time, it was well worth it to be constantly reachable by them when I was at work, or vice versa. I saw this device as a huge benefit, even though its only “feature” was voice conversations. SMS soon became available with later generations of digital devices, though with my original phone it was not an option.

I am not sure if world-wide roaming was available at any price. If it was, it must have been enormously expensive—it’s not cheap even today. When travelling overseas, the common practice at that time was to rent a physical phone specifically for the country you were going to visit. I remember doing just that on a trip to the Czech Republic as late as 2002. Nowadays, most countries —including the US— generally (though not exclusively) use GSM, which enables you to localize your device with a simple switch of the SIM card.

When thinking of today’s “smartphones,” it’s surprising to note that the “smart” part actually preceded the “phone” part historically, not the other way around. What we would today call “smart” devices were, in the early 1990s, called “personal digital assistants” or “PDAs.”

Among the first of the PDAs was Apple’s “Newton MessagePad.” The Newton was a recognizably modern device that, though larger and noticeably heavier than today’s smartphones, was easily hand-carried. It performed many of the same functions that we today take for granted on our smartphones, such as calendars, contacts, email, calculator and so on.

However, it lacked any integrated communications capability, except for an infrared port that only communicated Newton-toNewton. In practice, it synched with a computer via a cable.

The initial version of the Newton shipped in 1993, the same year I joined NeXT software. The first version I purchased, however, was the “MessagePad 120,” which became available in 1995. I was inseparable from my Newton, and I carried it with me to meetings and (to a lesser extent) at home, like I carry my iPad today.

In 1996, Palm Computing shipped a competing PDA called the “Palm Pilot.” Neither the Newton nor the Palm system had a keyboard; data entry was done through a touchscreen interface using a stylus (a pen with a rounded tip and no ink). However, the difference between the two systems was that Apple’s Newton recognized your natural handwriting in a full-page format, wheres the Palm required you to enter a single character at a time in a small rectangular data entry area, using a stylized type of writing. For example, the letter “T” was entered as a sort of inverted, mirror-image “L.”

While the Apple system may have had a theoretically more appealing approach, it was obvious from the time the Palm shipped that there was a key difference between the two systems: the Palm’s mechanism was reliable and worked, whereas the Newton’s mechanism was unreliable and frequently did not work. The Newton’s handwriting recognition was so erratic that it literally became a joke. You needed to double-check every word you entered to make sure it was not translated into total nonsense. The Palm’s character recognition mechanism—though it had a learning curve (you needed to practice for a couple of hours)—was surprisingly easy to master and was thereafter quick and accurate.

This is an instance of another recurring situation in software that has many names: “The perfect is the enemy of the good” or, as Steve Jobs used to say it, “Real artists ship.” Often 80% of the product value can be delivered simply and quickly, with the remaining 20% taking nearly all the effort. Generally—though not always—the right decision is to complete the simple part that delivers 80% of the value immediately and get the product in front of end users. You then listen to what the customers say and respond to their feedback. The part you thought was important—and that takes nearly all the effort—may turn out to be totally unnecessary.  That’s the essence of Agile and the foundation of most currently successful companies.

My speculation is that someone at Apple insisted that free-form handwriting recognition was the most important feature of the product and that customers could not live without it. Therefore a huge amount of the implementation effort went into that very difficult problem. In the meantime, someone with a simpler solution that was “good enough” for customers—and, more to the point, actually worked—came and took away the PDA market.

It’s a real art to decide what’s important and must be right, and what will be less important to customers. On this decision, whole enterprises rise and fall. Generally the best way to find out is to try something and ask—that’s the Agile way. In my opinion, Steve Job’s best talent was knowing what a customer would accept and what they would not. He was not necessarily reliable in this, but when he was right, he was spectacularly right. For the rest of us, I firmly believe that the Agile approach of “try, get input and adjust” is the right one.

I remember having my Newton with me at a company meeting at NeXT Software, where I was sitting in the front row to make a presentation. Suddenly Steve Jobs, the NeXT CEO, sat down next to me. He gestured to my Newton and asked, “Can I see that?” I handed it to him, and — somewhat to my surprise — he pretty much took it apart. He flexed the cover’s hinges, removed it and put it back on; checked the battery compartment; looked at every mechanical button and weighed the device in his hands. I said to him, a little awkwardly, “You know, some day these handheld devices are going to change the world.” He gave me a little half-smile, and as he handed my Newton back to me said, “Not that one.”

I remained loyal to the Newton for a few more years, until Apple canceled production. I then switched to the market leader, adopting a series of Palm Pilots as my PDA.

Email & the World-Wide Web

In addition to laying the foundations of the smartphone revolution that would come in the next decade, the 1990s saw the launch of the world-wide web. When I joined NeXT software in 1993, email was somewhat novel—though I’d already been using it at work for several years—and the world-wide web did not yet exist.

The lack of the web made it challenging to do some of the things we take for granted today—for example, supplying customers with updated release notes and technical information in between releases. NeXT actually shipped its software to customers on CD-ROMs and bundled the release notes and support tips (called “NeXTAnswers”) with each version. If any new information was discovered in between releases, it was provided to customers over the telephone case-by-case—a slow and expensive process.

Shortly after I joined NeXT, I was in a staff meeting where the topic was improving customer support. I spoke up and said, “At my last company, we had an automated FAX-back system where customers could use an IVR (interactive voice response) system to have the latest support notes FAXed to them in between releases. It worked pretty well.” Steve, who was running the meeting, turned to me and said, “Great idea. Make it happen.”

Support was not my functional area, and I was already quite busy recruiting and organizing my team. Still, when the CEO tells you to make something happen, that’s what you do—especially if it’s Steve Jobs! I remembered a very bright young IT guy / developer who had been in the new employee orientation meeting with me a few weeks before, and I went to go see him. I explained what I wanted to do with NeXTAnswers, and he said, “Sure, we can do that. But why not make it an automated email response system, as well?”

Remember, in 1993 email was brand new as a widespread technology. AOL had only started offering email to the public two years earlier. Many technology businesses had it, and I’d used it for several years. But it was clearly the coming thing. So I said, “Great idea. Let’s do it!” We pulled together a small team, got the necessary servers and equipment, and got the system up and running. In addition to being a big success with our clients, we were able to charge extra for a premium service, and we set up the team as a separate department within NeXT.

About a year later, the same guy came back to me and said, “You know, the world-wide web is getting to be a big thing. Would you help me pitch creating a website to host NeXTAnswers? A website would be much better than either FAX or email.” At that point (1994), I’m not sure I’d ever seen a website. Still, I said, “Great idea. Let’s do it!” I helped him make the pitch, and we got the support for creating what later developed into the NeXT corporate website. At the time of its launch, http://www.next.com was one of relatively few commercial websites on the world-wide web.

The web evolved extremely quickly, and websites rapidly evolved from static pages to dynamic sites, with e-commerce being a leading driver. Around 1995, NeXT developed a technology called “WebObjects” that originally took advantage of Objective C’s remote proxy mechanism. This was initially developed as a test automation tool, but the inventors rapidly realized its value as what we would today call an application server. WebObjects was used to power a number of early ecommerce sites, including (in 1997) the online Apple Store. Even today, the WebObjects application server is used for iTunes and other Apple offerings.

It’s astonishing to think back on how rapidly technology evolved during the 90s. From 1991 to 1996, we went from email being a relative novelty to deploying recognizably modern shopping sites on the world-wide web.

Operating Systems

In terms of operating systems, the 1980s were a CP/M and MS-DOS decade for me, whereas in the 1990s I did a lot of my work on Unix. I began using Unix at a startup in the late 1990s, where I actually ported part of the BSD “curses” cursorcontrol library to System V. At Rational, I had a Sun SPARC workstation that ran SunOS 4 (later relabeled as Solaris 1) with a Motif/X-Windows GUI. And of course NeXT ran on a BSD implementation on top of the Mach microkernel (as does its descendent, Apple’s OS X).

Ironically enough, my first work on Microsoft Windows happened while I was at Apple in 1997. I was leading the development of a “Web catalog” application based on the Java API version of WebObjects. This system supported the remote authoring of web catalogs using a web browser to upload images; it also performed merchandising and other e-commerce related tasks. Obviously we needed to support the Windows browser systems since they dominated the market, so I was one of relatively few people at Apple with a Windows desktop machine on my desk. This was, of course, dual-boot so that I could also run “NeXTSTEP for Intel!”

While at Apple, I also had a Mac PowerBook Duo that, I think, was my first laptop ever. Laptops had been around for several years already, but since none supported the NeXTSTEP operating system, I never bothered to get one while at NeXT. Apple did, however, have some beautiful hardware running MacOS. I chose a slightly older model that was “subcompact” and had a docking station for when you were working at your desk. That machine was definitely one of my all-time favorites, and I still have it in my garage (my wife, as you’ve probably guessed by now, is long-suffering).

Languages, Processes and Object Orientation

When I joined Rational (now part of IBM) in 1991, it was an island of object-oriented, iterative software development in a sea of procedural languages and waterfall development. Rational was a boutique firm specializing in the Ada development language and associated development tools. The company’s primary focus before 1991 had been architecture, consulting, process, and tools development for government customers. I joined the new “Commercial” business unit that would focus on the more commercially-oriented C++ language and on products for business customers.

I did have home computers at this point—several Apple Macintosh’s that my children and I used. These were networked over AppleTalk via twisted-pair telephone wire. The connecting wires were initially strung from the ceiling, giving the appearance of a kind of literal “home-wide web”—something my wife was not at all pleased about. These machines were for fun (and the kids’ homework), not really for work. My work from home was done on an “X-terminal,” a physical machine that connected over a dedicated ISDN line to my Sun / Solaris / Motif desktop at the office. Photo courtesy of Jim Walsh (all rights reserved).

Grady Booch, later co-inventor of UML, was one of the two architects on our team. Grady was already famous in the software community as the developer of “Booch Notation” for the architecture and design of object-oriented systems. He was also the author of the “round-trip iterative gestalt” methodology for software development. The development of our initial product, Rational Rose 1.0, was to be a showcase for both Booch Notation (which the tool supported) and Grady’s methodology.

When it first shipped in 1992, Rational Rose was, at 250,000 lines of code, one of the largest “pure” C++ programs that had been developed up to that point. We used early iterations of Rose to design later iterations as an embodiment of Grady’s “round trip” methodology—and a foreshadowing of the Agile practice of continuous integration and deployment that would be introduced about a decade later. The process we used to develop Rational Rose served as an important input to the Rational Booch Method development process, which was a precursor to the later Rational Unified Process, or “RUP.”

RUP and its Booch Method predecessor were more concurrent, iterative software development models that began to displace the waterfall methodology in the 1990s. While they still had distinct project phases as in the waterfall approach, these methodologies also advocated timeboxed iterations and concurrent development and testing throughout the project. In fact, Iseult White, author of the original Booch Method books, interviewed me and other Rose project participants to help document this new approach to software development.

Similarly, we used a weekly build and deploy cycle at NeXT that today we would call “Sprints.” We incorporated the new check-ins and built the entire 5.5 million lines of the NeXTSTEP operating system weekly, and then deployed the latest build onto every engineer’s desk. If someone broke the email system, we found out very quickly! Not every weekly build went out companywide, but toward the end of the release they did, and the entire company ran on the pre-released version. As you can imagine, Steve was not shy in his feedback, so we had an additional (and very strong) quality filter before the first customer saw it.

In the early 1990s, Steve Jobs liked to describe NeXTSTEP as an “Object Oriented Operating System.” While I’m not sure an operating system fits the strict technical definition for object orientation, this description did have merit. Each component in the operating system—for example, the “print” dialog—had a declared and well-defined set of inputs and outputs, and encapsulated behavior. Steve was proud of pointing out that while virtually every program in Microsoft Windows had its own implementation of the “print” dialog (and still does today), every program in NeXTSTEP—regardless of authorship— shared the common OS-provided dialog.

Like any “object oriented” system, a program could override or augment the default behavior it inherited; but unless the programmer did something extreme, the dialog the user saw was recognizably the same for every application. This degree of reuse and commonality made the system easy for end users to learn, and it made programming far more productive because you did not need to re-invent the wheel.

Probably the culmination of the object-oriented revolution of the 1990s was the widespread adoption of the Java language (around 1996). It was pretty clear to everyone—even to us at NeXT—that Java, not Objective C, was the wave of the future. At NeXT, we began migrating to Java and away from Objective C even prior to becoming part of Apple, and this trend continued thereafter. It is one of the ironies of the computer software field that Objective C has again come into prominence by being the programming language of the iPhone.

It is indeed true, by the way, that Java borrowed many concepts from Objective C. I once had the opportunity to meet James Gosling, original inventor of the Java language, and he confirmed to me that Objective C was in fact an influence. While we’re on the topic, Tim Berners-Lee, inventor of the first web browser, also credits NeXTSTEP’s ease of programming as the reason he was able to create the first web browser. I don’t have this statement personally from him, but I do believe it.

Finally, to close off this language section, I must confess that my on-again / off-again love affair with Perl began in the late 1990s. Whenever I do system control or text processing, my go-to language is Perl. I’ve been told that I’m old fashioned and should be using Python, but I must admit that I do keep coming back to Perl when I have a quick task to get done.

In Conclusion

Looking back, I’m struck by how the seeds of Agile, the smartphone and object-orientation all grew out of the 1990s—and from the early 1990s, at that. Next week we’ll take a look at the 2000s to current day, exploring how they led to both a high Velocity and truly “flattened” world.

NOTE FROM 2025: This series, written for my then-30th Anniversary as a professional software developer in 2012, consists of the following parts: “pre-history” (before I began working professionally in 1982), 1982-1992, this blog (1992-2002), 2002-2012, and my predictions for the next 30 years, from 2012 through 2042.

This blog is Part II of a multi-part series that explores my thirty years in software engineering and how the industry and technologies have evolved over three decades. To read Part I of the series (focusing on the years prior to 1982), click here.

A Full-Time Software Engineer

In late 1982 I got a very happy and life-changing surprise: we learned that my wife was expecting our first child! My daughter Anna’s impending arrival motivated me to shift from being a full-time graduate student in physics to a full-time software engineering professional, finishing my Ph.D. thesis write-up in my spare time.

Not incidentally, my new job came with a computer, the “Durango F-85.”  I was looking forward to using the computer (during off hours and with client approval, of course) as a word processor to type up my thesis.

The F-85 was an 8-bit Intel 8085 computer with an integrated printer, “green-screen” display device, and “high density” (480Kb) dual 5.25 inch floppy drives. The version I used ran an operating system called CP/M. The pre-Windows Microsoft operating system MS-DOS (which ran on similar Intel hardware) first shipped in 1982 and conceptually borrowed much from CP/M.

The Durango was a loaner from my client and their choice of hardware, not my own.  A full-featured Durango F-85, including a 40Mb hard drive, retailed for $13k in 1982 dollars—roughly the equivalent of a mid-range luxury car (about $40k today). As my business grew, I would eventually have several of these machines. In fact, one currently sits in a box in my storage unit, much to my wife’s chagrin. I know I should get rid of it, but thinking about how much money these computers cost, I could not stand to part with them all.

Lessons in Market Dominance: Part I

The early 1980s were extremely fluid times for what we then called the “PC” (personal computer) industry, and it was extremely unclear what standards would emerge and who would be the winners. I’ve seen this pattern recur many times since then around different technologies — Cloud/BigData being an analogous area today. However, when IBM entered the PC market in 1981, it was obvious that they—together with the newly introduced operating system MS-DOS—would be the market-maker and define the standards.

As my first MS-DOS machine, however, I did not pick the IBM PC but instead chose a cheaper one with better graphics called a “Victor 9000.” I’ve learned a lot from that decision, which turned out to be the wrong one for both myself and my client—who on my recommendation bought lots of them, circulating them to their offices worldwide. Though the Victor machine was arguably “better” from a technical and price standpoint, it was completely trounced in the marketplace by IBM.

The lesson I learned, which I carry with me to this day, 30 years later is: the best product does not always win. Many factors affect market success, and technical superiority is not always—or even usually—the most important factor (a hard lesson to accept for a technical guy).

An Early Adopter

Another recurring situation that started for me in the 1980s has been the attention I sometimes get on airplanes when I bring the latest cutting-edge device on-board with me. Since I travel frequently and am also an early adopter of new technology, the new devices I carry with me often attract curiosity and appreciative looks from my fellow business travelers. I’m not intentionally trying to show off, but I have to admit I enjoy it when a cabin attendant drops by and asks breathlessly, “Is that a new XYZ?!”

The first time I remember this happening to me was in the early 1980s, when I traveled with one of the first “portable computers” ever invented, the Osborne 1. The Osborne was portable in the sense that it could be hand-carried, but it was not what we would today call a laptop or notebook. The machine weighed 24 pounds (11 kilos), the weight of an average toddler (18 month-old child). Today’s “portable” machines are five to ten times lighter: a typical laptop might weigh about 5 pounds (2.3 kilos), with a lightweight machine like a MacBook Air weighing less than three pounds (1.4 kilos).

When I first carried my Osborne 1 onto an airplane for a business trip, the heads turned and the necks swiveled the way they would today for someone carrying the very latest just-released smartphone. I remember my fellow business travelers shooting admiring glances at my new “portable computer” as I walked down the aisle of the plane, carrying it in one hand. I hadn’t expected this reaction, but it was fun.

Adventures in Word Processing

The Osborne 1 also ended up playing an important role in helping me complete my Ph.D. thesis. The word processing features of the Durango were indeed great for text processing—much superior to the manual typewriter I would have used just a few years earlier. However, the Durango’s high-quality embedded and proprietary printer did not have software that could produce the mathematical symbols I needed for my thesis.

The Osborne 1 was more “open” and came bundled with a word processing package called WordStar. In one of the (hardcopy) computer magazines I regularly read, I saw an advertisement for an add-on package that allowed WordStar to print mathematical symbols. I sent away for this—by snail-mail and with a paper check enclosed—and it arrived by mail some time later on floppy disk.

Since I already had a popular Epson dot-matrix printer, my thesis production problem was almost solved now—except for the logistics. All the formulae for my thesis were hand-written. Getting them all into the computer was a huge undertaking. Fortunately, my then very pregnant wife came to the rescue and typed the literally hundreds of equations for me on my Osborne 1, while I was transcribing the text into the Durango’s word processor. We then literally cut-and-paste, with glue and scissors, all the equations into the proper place in the separately typed text. As the final step, I Xeroxed the pasted-up pages onto the mandated thesis paper supplied by my University, and the result came out looking pretty good.

When I wrote some additional scientific papers later in the 1980s, the state-of-the-art had evolved considerably. I was able to use the “LaTeX” markup language, which allowed you to embed equations into the text itself, thereby avoiding the need for cut-and-paste. LaTeX was available as a stand-alone postprocessor for text files, rendering postscript pages that you could then print. LaTeX and the typesetting language “TeX” from which it inherits were in many ways parallels to SGML and later, of course, HTML. Their separation of content from layout and rendering was especially intriguing to me, and it has proved itself to be a very useful paradigm in many contexts.

Lessons in Market Dominance: Part II

After completing and defending my thesis and receiving my degree, I got on-board the market trend and became a confirmed IBM PC user, using Microsoft operating systems and languages. The shakeout in the computer industry was fairly quick, and I had learned an important lesson: market dominance tops technical superiority almost every time.

The only hope a new technology has to prevail, in my experience, is to create or define a new market segment where it can achieve market dominance. Otherwise, someone whohasachieved dominance with a previous or a worse technology will gobble the new one up—hopefully for a large sum of money, but sometimes not. If none of these things happen and the new technology never achieves market dominance, it will languish and/or die. A grim picture, perhaps, for those of us who focus on creating these new technologies!

My advice to overcome the cycle is to find the best marketing and business people you can and make them your allies. And if it’s open source, find a way to publicize it! But in any event, technology success is much more about achieving recognition and dominance in the market than it is about the technology. It is a bitter truth, but the best technology does not always win, not even in the long run.

I do see this situation improving with the more overtly Darwinian model of open source, where technically better packages sometimes do win out. Even so, given at least an acceptable level of technology, judging the winners is much more often a matter of how much market share and popularity they can gather quickly, rather than pure technical superiority.

Introducing Email

It wasn’t until the late 1980s that email started being widely used as a communication mechanism. Can you even imagine having no email or other electronic communications available to you other than voice telephone calls? Even fax machines did not become popular until the late 1980s.

At a startup where I worked in the late 1980s/early 1990s, as an off-hours project I set up the company’s first email system using uucp. To do this, I manually strung cable between the serial ports (RS-232; USB ports did not exist yet) of selected machines and the multiple serial ports on a Unix machine that I designated as our inhouse mail server. The in-house mail server made a timed dial-up serial connection to a central mail server to send and receive external messages.

It’s hard to imagine today, but like most companies at the time, we did not have Ethernet. Other than for electricity and land-line telephones, there was no cabling in the building except for an occasional point-topoint serial connection between physically adjacent machines. Ethernet had been invented, but it was not in widespread commercial use until the 1990s. Ethernet hubs were invented along with Ethernet itself in the 1970s, but the first commercial Ethernet switch did not ship until 1990, and routers were generally implemented in software on a multi-port computer. And, of course, there was no world-wide web to connect to yet!

I believe that creating the cross-over cables for these connections was the last time I used a soldering iron at work. Starting in the early 1990ʹs, email and internal networks became commonplace in the high-tech community, and I have used them ever since.

The Evolution of Programming Languages

The first programming language I used commercially was, I’m embarrassed to say, a rather primitive form of Compiled BASIC (“Bascom”). I used this language not because it was a good one, but because in 1982 it was the ONLY affordably priced compiled language available for the CP/M operating system. A compiled language was essential for commercial software because otherwise you’d be distributing the source code— there was no way to obfuscate it. Incidentally, Bill Gates personally helped write the code for the BASCOM compiler in the late 1970s.

My first compiler arrived from Microsoft on an 8” floppy disk. It shipped in a three-ring loose-leaf binder with mimeographed (a pre-Xerox copying technology) instructions. This format was obsolete technology even in 1982, and I had to have a service migrate the binaries to the more modern 5-1/4” floppy drives I had on my Durango.

The 1980s were an innovative time for language development, and I had heard of a language called “C. Unfortunately, the only available commercial-quality C compiler for the CP/M operating system on Intel (called Whitesmith’s C) cost $600 per CPU (about $1,800 in 2012 dollars), plus a per-client distribution license of, I believe, about $30 per seat. This was definitely prohibitive, especially the client-side cost.

With its lack of structure, BASIC was not suitable for the type of larger-scale applications we were beginning to build, so I had a talk with one of my close friends from college who had worked as a developer on the US east coast at several national laboratories. He advised me to migrate to C, which I did as soon as the more affordable Manx Aztec C compiler came out (around 1983). I subsequently migrated to the Microsoft C compiler after 1985, when it became available. I learned C by reading the Kernighan & Richie book and all the related “white cover” C and Unix books, and I never looked back.

The fact that I am self-taught in computer languages may be shocking to the current generation of developers who consider a Masters in computer science to be a minimum entry-level credential. But keep in mind that in 1982, the people who had computer science degrees were primarily mainframe developers working in large corporate IT departments or for the government developing accounting and back-office applications with Cobol; or else they were researchers at computer companies and academic institutions working on operating systems and compiler development. No credential or even training existed for developing on the personal computer. The people who developed PC software in those days were much like me: interested in technology, but with a math, science or other type of engineering background. In fact, Bill Gates and Steve Jobs did not even finish college—they had no academic credentials whatsoever! Nonetheless, they did pretty well.

My choice of the C language proved a good one. Essentially every production (as opposed to scripting) language I have used since (C++, Objective-C, Java) has derived from C—so this was clearly the right choice versus, say, Pascal. This choice also taught me something else that has stuck with me: When you’re making a big technology decision, talk it over with the smartest people you know. Even Steve Jobs himself followed this principal. When I later worked at NeXT, it was routine for Steve to drop by engineers’ and managers’ offices and say “I’m thinking of doing XYZ—what do you think?” He wouldn’t always (or even usually) take your advice, but we felt listened to, and he got a variety of perspectives on his decision. Occasionally, he may even have learned something that changed his mind. Smart.

Late in the 1980s, I had the opportunity as a consultant to help Borland develop the compiler validation suite for a then brand-new language for microcomputers called C++. When it shipped in 1990, Borland’s Turbo C++ became the first version of C++ for MS-DOS to achieve widespread developer popularity, and it helped pave the way for that language’s emergence in the developer community. It came with an integrated IDE and had available a closely coupled debugger, setting a pattern for many languages to come.

By this time I had become a strong advocate of what was called “structured programming” and a “software tools” componentization approach for development using procedural languages. Once I encountered the new object oriented paradigm, I immediately understood the value of the encapsulation and potential re-use that C++ provided. It clearly solved what until then had been a real problem. Little did I realize, though, that this language would set the tone for the entire next decade, with Object Oriented programming having a huge impact both on the industry and on me personally.

Looking Forward

Next week, I will talk about the decade from 1992 – 2002. This was a pivotal time in software evolution, where in many ways the current software engineering era was created. To read my previous blog about technology in the years prior to 1982, click here.

This month, August 2012, is my 30-year anniversary as a software engineering professional, receiving my first official paycheck in August 1982. By both inclination and profession, my tendency is to look ahead, not back. As I think about this milestone, though, I can’t help but remember what it was like “way back when.”

I thought it might be fun to share my personal experience of how the software industry has evolved over the past three decades, including some of the gadgets and technologies I have loved—and sometimes lost—along the way. I invite you to come with me on this journey, looking backward for a change, instead of thinking about what’s next!

In the Beginning

I started working with electronic computers when I was about 14 years old. Today, that would not be unusual, but back then “personal computers” did not yet exist. However, through a strong interest in science and technology—and some fortunate circumstances—I was able to begin working with mainframes at a fairly early age.

I was spared having to program using punch cards; I was just young enough to avoid the “batch processing” era entirely. My first programming experiences were with “timesharing systems.” Though we still needed to drive to the building where the enormous computer was physically located, once we got there each user had an individual terminal (screen and keyboard—no mice yet!) that provided what we would now call interactive on-line access.

My first high-level programming language was APL. This is a truly bizarre array-oriented language that uses specialized symbols, rather than words, as commands. The language was extremely dense and efficient; you could invert a matrix with a single character and write a complex program in one line of code (which at the time I loved to do). For example, this program identifies all prime numbers between 1 and R:

As you can see, APL makes Perl syntax look verbose and obvious. Why anyone thought it was a good idea to teach this particular language to high school students (ages 13 to 17-years-old) is beyond me. Nonetheless, I loved it and spent many happy nights and weekends figuring out clever things to do on my next visit to the computer. I especially enjoyed hacking through the timesharing system to take over my friend’s terminals and insert timebombs and other little presents. Ah, youth!

I kept using computers and various languages throughout my high school, college and grad school careers. However, I never even considered studying computer science. (I was a physics major with a strong interest in mathematics.) At that time, computer science was a discipline in its infancy. The people who studied it planned to work for IBM, a large bank or the government—none of which I aspired to do. My interest at that time was in computers as tools, not as ends themselves.  I also had an interest in electronics, both as a hobby and as a study, and learned about logic circuitry and computer internals—which turned out to be pretty handy for programming, as well.

My First Computer

Until the mid 1970s, I had not owned a computing device other than mechanical computers. The first “computer” I ever owned was a slide rule, which I inherited from my grandfather and learned to use when I was about 12. This is a mechanical device consisting of wooden parts that uses logarithms to multiply, divide, compute powers of numbers, and perform trigonometric computations. It did not add or subtract (you were expected to be able to do that mentally). A slide rule is an instance of an “analog” computer, as opposed to a “digital” computer; the numerical values along the slide and other parts make a continuous number line, not discrete values. A knowledgeable person using a slide rule could generally achieve a precision of two and sometimes three significant digits.

For college I saved up to buy what I considered the best slide rule available for physics, the Keuffel & Esser Log Log Duplex Decitrig. I had to visit the MIT bookstore to get one since they were considered quite advanced and only sold at engineering-oriented schools. Slide rules were still widely used by my fellow physics majors when I started college, though I was among the first to switch to an electronic pocket calculator when they became affordable. I cringe to think of it now, but I did indeed sometimes wear my slide rule on my belt in its foot-long orange case. Thankfully I never got any trouble for this because the other kids thought it was cool (or I was so “uncool” that I just thought they did…).

The first digital computer I ever owned was a mechanical device called a “digicomp.” It was built from a kit and made out of plastic, believe it or not, and could be programmed to perform three-bit binary addition and logical operations (AND, OR) through the placement of a series of hollow plastic pegs. This was not a practical device—it was a toy—but it was indeed a real (albeit very primitive) programmable digital computer.

Electronic computers simply did not exist for home use before 1976. Even the idea of owning your own computer in the early 1970s was like aspiring to buy a jet airplane today. Similar to today’s jet airplanes, computers in the early 1970s were expensive (millions or tens of millions of dollars), and they required special facilities and staff for maintenance. Owning your own electronic computer was firmly in the realm of science fiction when I was in high school.

Programming for Calculators

A watershed moment in my relationship with computers was the introduction of programmable scientific pocket calculators by Hewlett Packard in the mid 1970s. Hewlett Packard had produced a series of desktop programmable calculators in the 1970s that I had used in school. However, these were physically large (covering most of a desk) and quite expensive. The ones I used were owned by the school. HP also introduced the first “pocket calculator” in the early 1970s (the HP-35), but it was not programmable and was quite expensive—about $3,000 in today’s currency.

In the mid 1970s, however, HP introduced the very first programmable electronic device I ever owned: the HP-25C pocket calculator. It was priced at $200 (about $1,000 in today’s currency). My father paid the lion’s share, and I excitedly made up the difference with earnings from a part-time job. This calculator was truly programmable, with conditionals and loops (using GOTO statements), though programs were limited to a maximum of 49 steps. The programming language was quite low level, analogous to modern-day assembly language, though with the addition of pre-programmed mathematical functions such as the trigonometric functions “sin” and “cos.”

As a grad student, I later acquired an even more sophisticated calculator, the HP41C. Personal computers had been introduced by the late 70s (the first Apple computer shipped in 1976), but the Apple computer was quite primitive in terms of its scientific capabilities, which is what I was interested in at the time.  Though they were rapidly added, floating point operations were not even supported in the initial languages available for the Apple computer. IBM PCs, DOS and Windows did not yet exist. If you were interested in mathematics, the HP41C calculator was the apex of the programmable calculator world, offering extensibility through plug-in modules and a magnetic card reader for extra storage.

Because my family situation required me to relocate away from the university while I was finishing up my research, the bulk of the mathematical calculations for my Ph.D. thesis were performed on an HP41C calculator that I programmed. I suspect that the program I wrote (testing certain quantum chromodynamic assumptions by calculating a range of hadron masses) may be one of the largest ever written on that device. Certainly if I’d had access to a university computer, I would have written in a higher-level language than the near-Assembler available on this device.

Still, because of the size and complexity of my program, I learned a lot about structuring code for readability and maintainability. In particular, I learned that it’s possible even on a pocket calculator!

Here’s an example of an HP41C program to compute the factorial of an input integer:

Imagine writing thousands of lines of code like this, and then debugging and maintaining it! On the plus side, you could call functions to do numerical integration and other rather sophisticated mathematical operations. Well, you learn to work with the tools you have available, and I completed the numerical processing needed for my thesis using my HP41C.

Looking Forward

My next blog post, which can be found here, explores my first decade in the computer industry, from 1982 through 1992. If you have questions about my experiences or would like to share your own stories, please feel free to leave a comment below.

NOTE FROM 2025: I wrote down a few thoughts at the time of my 30th Anniversary as a software professional, in August of 2012. I didn’t publish it on the company blog, given that some of these thoughts here are more personal and ‘political’. A number of the ideas here informed the series I did publish, though. The 30th Anniversary series itself consists of the following parts: “pre-history” (before I began working professionally in 1982), 1982-1992, 1992-2002, 2002-2012, and my predictions for the next 30 years (as of 2012) from 2012 through 2042.

A flatter world

One of the most profound and significant changes brought on by computer technology has been the “flattening” of the world.

The biggest significance of this to my mind is that people of ability—no matter where in the world they live—now have the opportunity to prosper in a global marketplace, and can reasonably aspire within their or their children’s lifetimes to achieving a globally high standard of living. This certainly applies to software engineers, but because of the affects of technology, also to many less technical folks. By creating a global marketplace, people producing exceptional or unique products can now readily present and sell those products to a global audience, accepting payment and shipping them expeditiously at a reasonable price using software-enabled payment and logistics services. 

This global flattening trend has created winners and losers, but on the whole I think it has been a very good thing for the world. In 1982 whole industries and fortunes were made by identifying the producers of goods at point A, and moving and selling those goods to point B. The producers at point A could rather easily be underpaid and exploited, because their own ability to get the goods they made to point B—where they had value—was limited or non-existent, giving the intermediary all the power. This era is over. Fortunes can still made by scouring the world to carefully select the producers, “curating” the products to insure quality, and then delivering those products to consumers, insuring their satisfaction in the target market. This much has not and—I believe—will not change. However the producers and consumers may now directly connect with an ease that was literally unthinkable 30 years ago. While not producing a utopia, the possibility of a direct connect at least helps keep things more fair, making winners of both the producers and suppliers.

Like many US software engineering managers of my generation, I was opposed to outsourcing work to developing countries when it first started to become widespread in the 1990s, in the run-up to “y2k”. I suppose, in some part of my brain, I was afraid of the impact outsourcing would have on my job and my team. My conscious thinking at the time was that it was challenging enough to create great software with everyone in the same building, without adding communications, timezones and cultural barriers into the mix. This was before the full impact of the internet and affordable mobile telephony—also products of the software revolution—had effectively erased many of the barriers of geography.

Though I had done geographically distributed projects earlier in my career, 2003 marked my first experience with true outsourced product development.  I arranged an on-site visit to my first offshore team in Hyderabad India with the primary—though unspoken—purpose of making sure the workers were not being exploited, fully intending to find another job rather than be part of any exploitation if that’s what I found. I had only had phone contact with India before, and had no idea what to expect—and what I found really was unexpected. I found happy, energetic and intelligent people just like those I worked with in the US, working in conditions very much like those in the US. In fact, their working conditions were considerably nicer than a San Francisco startup I had recently worked at!

Working alongside this team, I also got over any qualms I might have had about “taking American jobs” and “moving them overseas”. To me, the whole point of being an American is that you can rise to the level of your ability. These people in Hyderabad were doing exactly that. Standing in India and figuratively looking back at the US, I felt strongly that the least patriotic thing I could possibly do would be to deny jobs to these great people simply because they lived in India—when these are exactly the same people we would have hired if they were in the US. America has never been an ethnicity or even a geography, but an idea. Hiring or not hiring a person simply because of where they were born or where they lived seemed to me like the least patriotic, most un-American thing I could do.

Since that time, I have always held my Indian—and later Belarussian, Ukrainian, Argentinian and other “offshore-based” employees—to exactly the same standards as I would hold a US employee in the same role. I expect my offshore teams to be as good, person-for-person, as my on-shore teams—and I have found that they can be and are. I feel I owe that to all concerned: the offshore people I am hiring; the US-based people I’m not hiring for that job; and myself and the other stakeholders involved. I don’t think I’d be honest or fair to any one of these stakeholders by expecting that just because someone works in India, China or another “offshore” location they are inherently less capable than an onshore person in the same role—to me that’s simply wrong.

This is not to say that thirty years on, in year 2012, the American-based programmer is dead—far from it. While census bureau statistics show that about a third of US-based software engineers are immigrants, that implies two-thirds were born in the US! That’s a fact that is somewhat surprising to me from my perspective in Silicon Valley, where nearly all the engineers seem to be from other countries! [[need some demographic info here]]

Dangers

The dark side of the information age lurks in the possibility of using the technology to control people’s lives rather than to empower them. I think most of us—even the technically literate—are only dimly and occasionally aware of the vast potential for misuse of the information infrastructure that surrounds us. Using this technology, it is an easy matter to track who we know, what we say and do, where we are and have been—and even what our values, aspirations and private fantasies may be. It’s all in the traces we leave on the internet, in our social networks, through our mobile devices, and in our spending patterns. And that is just the information we “control”! Much more information is passively tracked through cameras and other means in our increasingly connected world.

In the wrong hands, this information could result in the grimmest tyranny known to man—one where not only our activities could be tracked and controlled, but even our private thoughts could be discovered and used against us.

As a young man studying physics, I was fascinated by the Manhattan project—the secret initiative during World War II where scientists and engineers working in the US created the atomic bomb for the war effort. The most engrossing aspect of that effort to me was not just the physics, but the human dynamic. Even the most idealistic of the scientists involved got so caught up in the intellectual adventure of creating this new technology that they forgot about the horror of unleashing a terrible new weapon on the world. For many participants, the original motivation for creating the bomb was the fear that Nazi Germany—where much of the pioneering work in nuclear physics had originally been done—would develop such a weapon first. Even when it became clear that Germany had no such effort, the American engineers and scientists continued working on the bomb. In most cases this was not because they believed it was still necessary to win the war. Instead, many had become so excited about the intellectual challenge of creating this new technology that they never stopped to re-assess whether it was still the right thing to do.

In introspective moments, I have sometimes wondered if our generation has been part of a sort of inverted Manhattan project that, instead of creating the destructive aspects of our technology first, instead created the benign and positive ones. This would be as if the original Manhattan project had focused instead on the positive uses of nuclear fission—say, medical radioisotopes—rather than building the bomb. In this alternate universe, the Manhattan project would still have discovered the means to create a devastating weapon, but chosen not to do so. In some ways, by building positive uses of information technology first, that is what our generation has done.

While this sounds great and very enlightened of us, the problem is that any technology with the power to profoundly change the world for good also has the potential for great destruction. History shows us that technologies with the potential to be used as weapons or tools of oppression eventually will be, in some places and at some times. Much as our parents and grandparents left future generations to address the challenge of nuclear technology, we leave to our descendents the challenge of responsible use of information technology.

Summary

Thirty years is a long time, and at times I succumb to nostalgia over projects, products and day-to-day working relationships that are no more.  Some people I admire have passed away; others have been felled by the “golden bullet” which enriches people to the point they are no longer active in the software community. Some great ideas, products and companies have come and gone, never to be replaced or repeated.

But my overall feeling looking back on the last 30 years is great satisfaction. I’m not sure that many of us set out with the conscious goal of transforming the world and making it a better place—I think many of us were just excited by the possibilities and happened to be in the right place at the right time with the right skills. 

Lessons learned:

• Listen to the people just graduating (or still in) University. Having experience is great in many ways, but in other ways it’s a handicap. It’s easy to develop a closed mind. I’m sure you’ve seen this many times—a person who responds to every new idea with “we tried that x years ago and it didn’t work.” This is why it’s important to listen to recent graduates, and learn through their still open minds. The new generation of developers does not come with the same preconceptions and prejudices that all of us develop over time; they start “fresh” and you can always learn something from the way they see the world if you stay open to it. One recent example would be the javascript language. The people of “my generation” tend to view javascript as a total kludge. We tend to see it as the way that encapsulation in web applications has been violated and hard-to-maintain business logic has found itself executing on the client. We see javascript programs as web pages using cut-and-paste code, with no re-use. Things have changed profoundly, and javascript is developing—or, arguably, has developed (it’s still hard for me to say that)—into a first-class language, both client-side and server-side. This is just one example. It’s not always easy to unlearn what you thought you knew and learn something else. But if you stick with your prejudices instead of being open to what the new joinees are learning and doing, you will rapidly grow stale and loose effectiveness as a developer or a technical manager.
• Be curious and evaluate whether a new technology is a good solution to a real problem. The reason I was an early adopter of “winning” technologies like C and object orientation was not because I had precognition—it was simply that I recognized these technologies were good solutions to a real problem that I actually had. They turned out to be long-lived in the industry because they solved other people’s problems well too. When choosing a technology, the best approach is to ask yourself if it’s the best solution you’ve seen to a problem that you really have. If the answer is “yes”, and if the solution is simple and elegant, that technology will often be a winner—because more often than not, if it solves your problem it will solve other people’s problems too. Note that “technology” means, literally, the “technique” or method of solving a problem—it doesn’t mean a particular product or a particular company. For example, “C”, “distributed caching” and “AMQP messaging” are, in this sense, technologies. However there are many embodiments of each of these technologies, supplied by many vendors and open source suppliers. It generally is NOT a good idea to compromise on your selection of a technology—except in special circumstances (for example, no one understands how to use it; or it’s clearly headed for obsolescence) you want to choose the technology best-suited for the job at hand.
• When choosing an implementation or vendor for a particular technology, you are often better off following the leader. For example, memcached is a currently-popular distributed caching mechanism. If you’re choosing to use a specific distributed cache, then the “market leader” or “most popular” is generally your best choice. Only if the leader genuinely does not suit your most important needs would I choose a less-popular system. That is because—just like teenage boys and girls—the most popular gets the most attention. This means the most popular (software, not boys and girls) will evolve the most rapidly, have bug fixed more quickly, have more active user groups who can answer your questions, have more people available to hire who already know about it, etc. The rule is not always true—there are some fantastic niche players sometimes—but in general the most popular implementation of the technology you’ve selected will your best choice.
• While it’s always best to meet end-user needs—real or anticipated—keep in mind that it’s generally (though not always) better to ship than not to ship. The “perfect” can be the enemy of the “good”—and often the way to ship something great is to ship something good and constantly make it better.  The early days of the Blackberry are a great example of this. The Blackberry started out meeting a real need (mobile email) in a minimalist way and kept improving over time until the feature set became very rich. (Their mistake in my opinion was not throwing it out and starting over with another minimalist offering when they needed to—but that’s a different discussion). Starting with a simple beginning and growing isn’t always the best approach. If your initial offering doesn’t solve a real problem or if it doesn’t meet minimal user expectations or minimum standards, your product is dead with little hope of recovery. But before you hold on until it’s perfect or “complete” remember that “real artists ship”. It’s surprising the degree to which end users will adapt their behavior to take advantage of your product IF they see sufficient benefit to them (for example—the stylized alphabet used for data entry on Palm Pilots; the cryptic symbols, typing patterns and acronyms used for text messages (LMAO, etc.)).
• Achieving excellence requires a focus on maximizing strengths rather than on minimizing weakness. The tendency of many companies and individuals is to try to fix what’s wrong, rather than to pursue excellence by building on what they already do well. For a software company, this generally takes the form of attempting to fill the “gaps” in their offerings, by either adding features, or by making an acquisition that covers some perceived hole. In individuals, it generally takes the form of addressing “areas of improvement” rather than building on the “strengths” you already have. The alternative for both is to learn to live with their imperfections and instead focus on taking their unique differentiators to the next level. Few actually do this because it entails a lot of risk to leave a known fault in place. If a flaw is going to literally put a company out of business—or will make you as an individual lose a job you want to keep—you need to address the flaw. There’s really no choice. However I think most companies and individuals have more choices than they realize. A strategy of fixing weakness certainly raises the average, but it does not maximize the upside. I think that’s why so many companies—and individuals—muddle along but never achieve excellence. For these people and companies, fear of failure is a stronger driver than seizing an opportunity for success. I think in some situations, this is rational behavior: If we can’t afford to risk losing our job—or having our business temporarily decrease—then maybe it makes sense to forget about “excellence” and instead focus our energies on avoiding disaster. But when we make this choice, we should realize precisely what we are doing: We are forfeiting the chance to achieve the best that we might be capable of. Companies and individuals that achieve excellence generally do so in spite of big flaws. They focus entirely on what they do or want to do well, rather than on being “pretty good” at everything. Like Achilles, companies and individuals have a choice: “A short life filled with glory, or a long life filled with obscurity.” The more we realize we have a choice, and are up-front about making it, the happier we will be as companies and individuals. 

So, the final question in looking back: Did it matter? I’m not planning to retire anytime in the near future—in fact my father is still an active guy.  I firmly believe my best working years are still ahead of me. But the biological fact of life is that I now have more working years behind me than I have in front of me. At this milestone, with the bulk of my career in my past, I have to ask: Did it make a difference? Did it mean anything more than collecting a paycheck?

Of course the relationships we have, and have had, with the people we work with are probably the most important aspects of any career, software or otherwise. There’s nothing quite like being part of a great team; it’s a satisfaction all its own. And the software industry has had no shortage of extraordinary characters, some of whom I had a chance to meet along the way—from true geniuses to a guy who regularly came to work with a parrot on his shoulder to a woman who had her hair dyed in the colors of the Apple logo (actually I didn’t meet her—but she had only recently left Apple when I joined). And those are just a few. Just thinking about some of these and the other characters puts a grin on my face.  I’ve also had the great satisfaction of helping people to advance their careers and skills, as others have helped me. The people have definitely made a difference—them to me and, I hope, I to them. That matters. But did the work itself make any difference?

Certainly over the last 30 years, the industry of which I—and probably you—are a part has changed almost every aspect of how about three-quarters of the world lives (that’s the percentage of people the World Bank estimates now have access to a mobile device). The convergent information, telecom and computer revolution has changed how we work and how we play; how we spend money and how we make it; how we interact with those we care about and how young people date; how we spend our leisure hours, and how we learn in school. In fact, it has changed the shape of the world in every way, geo-politically, socially and financially, more profoundly than any war or revolution in history.

If we can say that a soldier in an army helped to win a war, or that a revolutionary in a society helped to create a new form of government, then you and I as software engineering professionals can be said to have transformed the world in these profound ways. I and my colleagues; my competitors and friends; my bosses and subordinates; the leaders of our industry and the “freshers” just out of University—we have together changed the world, and mostly for the better. And I, for one, think that matters.

Note from 2025: Steve Jobs passed away on October 5, 2011. This blog was written and posted the following day.

I am finding the strong and world-wide reaction to the passing of Steve Jobs intensely moving. That so many people were touched by Steve and what he stood for in people’s minds speaks well for the human race. 

Steve was a vital and vibrant human being. He was the kind of guy who was excited to come to work in the morning—not every morning (he was very human)—but the vast majority of them. When I worked at NeXT back in the 1990’s, I had a meeting scheduled with Steve at 8:00am the morning after his other company, Pixar, went public. This was an event that netted Steve a profit of close to a billion dollars, at a time when he really needed it. I hustled to make it to the meeting on time, all the while thinking that there was no way Steve would be there after what must have been quite a celebration the night before. He was not only there, but after responding to my congratulations with a brief “thanks”, we went right to work like nothing had happened.

By the way, when people refer to Steve Jobs as “Steve”, it does not mean they are trying to imply a close and familiar relationship with him—as it would, for example, if I referred to the current President of the United States as “Barack”! Everyone at NeXT called Steve Jobs “Steve”, as did everyone at Apple when I was there. I never heard anyone, from his direct reports to the security guards, ever call him “Mr. Jobs”. 

On the other side, there was only one “Steve”. If there was another person in the company whose first name happened to be “Steve”, we renamed them. Steve Naroff, for example, who headed the Development Tools group at NeXT and is even today still at Apple, was never referred to as “Steve”, but as “snaroff”, his email name. This was not at Steve’s urging or by some corporate policy, by the way—we, the team, did it without really thinking about it, I guess as a form of respect. There could of course be only one Steve.

So why was Steve Jobs so admired, respected and—seems strange to apply to a guy I actually knew, but I guess it’s the right word–beloved?

I’ve given a lot of thought to this, and clearly his amazing success at Apple over the last ten years has a lot to do with it. People love a winner, and Steve helped take Apple from near-extinction to one of the most valuable companies and brands on the planet. No small feat, and worthy of admiration in itself. 

Steve had that doubly-rare gift of not only being superb at what he did, but also of getting rewarded and recognized for it.  There are many people who do great things and are never recognized for them. There are others who would do great things if they were in the right position, but they don’t have the political and other skills needed to get to those positions in the first place.  Steve not only had the ability to recognize and help create great products, he also had the political and other skills needed to move himself to a position where he could cause these things to happen, and get recognized and rewarded for them. This is exceedingly rare. Most people with the skills to rise to the top of a multi-billion dollar company are demonstrably not the right people to actually run the company—at least in terms of consistently producing great products. I think many people’s admiration stems from the fact Steve could do it all.

However, I think a lot of it—and certainly the foundation of my own admiration—is Steve’s mantra of “Insanely Great”. I took and still take this to mean that products should be as good as they can be—as good as you know how to make them. They should not just be “differentiated enough to beat (or neutralize) the competition”, but rather they should serve the end-user’s needs as well as you possibly know how to do that. There are of course pragmatic considerations—like the cost to the end user (it’s not “great” if the customer can’t afford it), the time to market (it’s not “great” if it never ships) and the need to fund the growth of a healthy business that can create more great products. If you don’t take those into account—and there were times when Steve did not, and paid for it—you won’t be able to continue to produce great products. But within those constraints, “insanely great” means the product should be better than it needs to be. In fact, it should be as good as it can be.

The foundation of “insanely great” is a refusal to accept anything less than excellent. This was Steve’s best gift, in my mind. While Steve was personally a fountain of creative ideas (some good, some bad), even moreso Steve was able to recognize the great ideas of others and know instantly when it wasn’t quite right. When you met with him—as we all did at NeXT—he would give you a big job to do, and when it didn’t measure up to his standards he would say “You can do better than this”. While disheartening sometimes, this was really a vote of confidence—because Steve knew you had it in you to do better. And chances are, you did. By setting a high bar and refusing to accept anything less, we ended up rising to levels of excellence and to learn to work together as a team in ways I have never seen before or since.

It must be said, though, that “insanely great” really is “insane” in the sense of not being fully rational. It truly does NOT make business sense to invest more in the quality of your product than you have to in order to beat your competition and win in the market. Also, keep in mind that Steve championed the development of many products that were so far ahead of their time or the technology of the day that almost no one bought them.  “Insanely great” is more a matter of faith and philosophy than it is a bankable business strategy. You have to believe. Still, this is what inspires me about Steve Jobs, and I think it is a key reason why so many of us around the world mourn for him today. 

To me, Steve’s gift to the world is to show us that “insanely great” can not only exist, but win. This attitude builds the kind of products people are thrilled to buy, and the kind of companies we are excited to work for. Pragmatists will probably never understand why doing something better than you need to do it can make any sense.  These voices are temporarily silenced by Apple’s business success, but many of us—myself included—fear to lose Apples’ shining example of “insanely great” products with Steve’s passing if the pragmatists again win the day. 

Looking back on it, if I had to choose—and putting financial considerations aside—I would have chosen to work for Steve during the NeXT days rather than be part of his more recent Apple success story. At NeXT we knew we were developing something insanely great—and the NEXTStep operating system and other products we developed did indeed lay the foundations for Apple’s later success technically, in many ways. But at the time, there were few customers (relatively) and all we had was our belief in the value of what we were producing. We had the admiration of people we respected in the industry—which is no small thing—but at that time, not a lot of validation from the market. Our satisfaction and the excitement we took in our work had to come from inside.

But that’s a lot. Knowing that what you do—your work—has intrinsic value because it’s good, truly good, is almost certainly the greatest gift you can receive in life. Creating and appreciating something of value, whether it’s raising a child, taking a great photograph, or helping develop a new software tool, is probably the best experience life has to offer. I think Steve Jobs has touched a chord in so many of us because he gave us that experience of excellence beyond reason: certainly to those who worked with him, but most of all he gave it to those who got a product better than merely “differentiated”. Customers got a product better than they could have ever expected.

So, my farewell to Steve Jobs. Steve, you were an insanely great individual, and you lived an insanely great life. You set out to change the world, and you did. We are privileged to have been your contemporaries, and to enjoy the benefits of all you brought to the world. May you not only rest in peace, but in the satisfaction of a job unreasonably and irrationally well done.