The Story of Software Commercialization

This post describes the collision of the software industry with capitalism. As the software community shifts from its technology-focused innovative mindset to consumer-focused production motivation, a great danger to upcoming engineering quality keeps growing, which aspiring software developers should be aware of.

The Textbook Era

Counterintuitive to many, the great generation of software developers in the 80s and 90s emerged when educational resources were scarce. This generation had time to think and experiment to innovate. Their directive was to shape, not build.

The word "dinosaur" has a meaning in the tech industry. Dinarours are reputable technologists who are very big in their areas. We also call them dinosaurs because they mostly used past technologies and are about to get extinct. So if you see one, do not mess up your chance.

How did they emerge in the first place? Let's have a look.

My professors talk about how it took hours, sometimes days, to compile a C++ program in the 80s. Making a typo in the code sometimes required a recompilation from scratch. This is how a generation of superb engineers was born, with the motherly care of every line they coded. Today, we consider ourselves lucky if we write good-to-go code for ten minutes.

This was not the only difference. At the time, Silicon Valley was primarily focused on hardware to speed up processor performance. Software engineers were mostly computer engineers, and they were more proficient in the low-level principles of computers. Open source was not very popular, but some activist computer scientists demanded all software to be made open source (never worked). Most importantly, people learned computer engineering from textbooks. Reading was the only way to learn at college or at your desk. I call this the Textbook Era.

How a Generation Succeeded

Working in the 80s as a software developer was not fun. Is it today? It's a matter of opinion.

Yet, as software developers, we often look at things with a particular focus: whether it works well or not. Software development in the 80s worked very well, leading to outstanding global successes in the software industry. People of this generation turned out to be very productive for others and themselves. As a result, many developments happened, especially starting in the 90s.

It was 1991 when Linus Torvalds came up with Linux as a demo project. Then, all of a sudden, developers worldwide started fixing bugs, adding features, and preparing Linux to be the industry standard operating system. I call this the Textbook Era because Torvalds built Linux following the textbook Operating Systems: Design and Implementation by Tanenbaum and Woodhall. Overall, Linux was not only a spectacular collaborative achievement but also an emphasis on the globally disruptive power of the open source.

There are other things. Hard work on hardware started giving good results. This led to the emergence of Google and its two founders. Marc Andreessen's Mosaic Browser was released in 1993 and later became the first publicly available web browser. In 1995, many things happened. I will only talk about three.

  • release of Apache HTTP Server
  • release of JavaScript
  • commercial release of the Internet.

Starting with the Apache HTTP Server, I think it had the most negligible impact - only because the two below are very big. Apache server was released as an open-source project. It let anyone host a server from a local computer, simplified DevOps, and brought more people to web programming.

Among the other two, JavaScript and commercial Internet, it's your choice to decide which one had the more significant impact. If you are not a software developer, you may think it is the Internet. If you are, then you might tend to choose the other.

In my opinion - and I don't think I'm alone here - JavaScript is the main reason the Internet rapidly became very popular. It transformed the Internet into an advertisement monopoly we all hate, right? But, at the same time, this was why many websites were up there. They made money out of the ads. I will add the link to a talk by Brendan Eich, creator of JavaScript, in the resources section below, where he describes this ad issue. If you wonder what the Internet looked like during those days, you have a way to see it. Have a look at web.archive.org. You can enter website names in the search bar, like "amazon.com," and search. You can see what Amazon's website looks like whenever you choose.

About all these technologies and more, there are many things to consider. Many of these resources were not built for monetary purposes but to architect an isolated, well-functioning digital environment for communication. Before the Internet became commercially accessible, who do you think used it? Government, military, intelligence, and perhaps other divisions had access to the then-semi-practical environment, all working to make it a better place for communication and accessibility - and maybe some different motivations I avoid questioning. It was not only about the Internet, though. The Mosaic Browser had a similar philosophy in its early years, valuing research and experimentation. For example, it was the first browser to support images on the Internet! At the time, there were the firsts of many technological tools and ideas, increasing the significance of research and good architecture. However, third-party resources were scarce, and software engineers had to know what they were doing. This is how these software developers became today's dinosaurs - knowing everything relevant to their work.

The Blow

I am coming back to 1995. The rise of an add-based World Wide Web paved the path for great commercial potential. For many software engineers, now was the time to make extreme money. So they founded many software companies, causing the dot-com bubble. This was going to lose its path once they deprioritized the technology. Technology-focused innovation mentality was gone.

Well, whoever thought this business makes money was right. Dot-com bubble companies emerged quickly. It had a peculiar hype, something no one had experienced before, and big money was there. Corporate valuations were primarily inflated. Software companies aimed at rapid expansion, and they hired more and more developers. Software engineering pay was getting better and better.

Everything looked suitable for software people, except something - which some neither noticed nor cared about. The definition of software development had started to shift. The new expectation was:

  • forget about the hardware side
  • manage software servers
  • focus on a very specific area in the codebase

In other words, making this much money had never been easier. "If so, why should I read textbooks" mentality was coming. The Textbook Era was over.

A Collapsed Philosophy

Many things followed as software engineering mutated to maintaining production-ready codebases in the application layer. Probably the most important one was the learning resources, which now appealed to a commercial customer base.

The Dot-com bubble went on until the late 90s, some even say the early 2000s. Many software companies that were founded during this bubble faded away in the later years. Some survived, though, like Amazon. The software proved its potential but not with this kind of hype. In addition, much of the capital put into the bubble was melting. Why did all these happen?

There are financial reasons, but I will focus on philosophical and technological reasons. First, let's get a bit philosophical.

Changing Design Philosophy

Ads then were not as powerful as the ads today. In many cases, they did not blend into the product well. Even if they did, they were still adds, and our impression to them is obvious.

Ken Kocienda, previously the principal software engineer of iPhone at Apple, discusses how a design-oriented Apple had a significant impact in the early 2000s. According to him, its design orientation had already differentiated Apple when he first joined in 2001. After he joined, Apple kept moving in the same customer-first design approach under the leadership of Steve Jobs. Kocienda was not actually a software engineer but more of a designer. He describes the work climate at Apple and its Diplomacy (the exec room where Jobs accepted product demos) as client-facing and user-focused. For example, when developing the touchscreen keyboard for the first iPhone, Kocienda mentioned that they were given plenty of time to ship the product as pleasant as possible. In his book Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs, he talks about all these.

Unfortunately, such an environment was Apple-specific. Apple was an older company; it dated long before the dot-com bubble. It had enough experience in shipping unsatisfactory products. Also, it had a design genius like Jobs. These are highly significant in its long-term success.

Newer companies, children of the dot-com bubble, were focused on growing and money-making. It is unlikely that they ever put in the time to think precisely about UX. Imagine how the cryptocosm is today; there are tens of L1 blockchains we read about, and many of them will fail. Nevertheless, their presence is still essential because they create competition and a system of complete isolation. I believe how UX will affect blockchain is still to be seen. It may not be the user interface as much but more usability, wallet integration, security, scalability, etc. We are still in the early days of blockchain, so it is easy to answer which blockchain protocol will win the race: the one that comes up with the most fluent experience. It may be more than one.

In the long term, users stay wherever is better for them. Once the hype and excitement are over, this is the common fate of tech products. This is what happened in the dot-com bubble. Once the dot-com bubble balloon was over, the user base polarized.

Tech Sacrificed

If there is one thing that technology should never collide with, that is greed. During the dot-com bubble, commercialization happened so fast that engineers turned into business owners, focused on securing cash and increasing corporate valuation.

Open source contributions became highly popular, and hence an third parties became abundant. Programming-wise, the speed of this shift was hard to adapt to. Just learning how to build open source tools and frameworks started to be okay for some companies. Engineering quality naturally decreased. We are talking about the Valley, so a reduction in rate does not necessarily mean bad quality. Yet, it was lower quality at a time when quality was precious.

Eventually, the hype died, and the dot-com bubble collapsed. Often a challenging thing to accept, dead is dead. It would be unwise to be sad about this, especially when dot-com bubble caused some unstoppable chaos in the education industry.

Despite being one of the biggest hypes of the last century, the dot-com bubble also had benefits to the industry. I would say that it is the reason software became the major thing today. It is the bubble that lets us use our computers easily. Still, simply because its motivation was big capital, I believe it would appear somewhere else if the Valley missed the chance. Would it be this big? It might have depended on the capital. The issue with the bubble was not using existing technology to innovate. This was a great thing. The issue was the many misunderstood and misrepresented this process, changing the definition of actual engineering.

Upcoming Changes

New changes are on the way, many things. Flying cars, holograms, environment-friendly and anonymous blockchains, perhaps compact fusion... Some software engineers will make these possible. But what will they need to know?

20 years ago, a developer needed to know Linux well to succeed. Now, it is not the case anymore, as cloud services platforms automate Linux (and more) tasks for us. Now, what one needs to know well is Amazon Web Services. Yet, AWS depends heavily on Linux. So, we do not need to know the very foundations to succeed. This is a thumbs down, not only for technocracy but simply technological improvements.

Likewise, a game developer does not need to be an OpenGL expert today. Knowing tools like Unity, Unreal, or Oculus is more than enough. 40 years ago, peer-to-peer (p2p) networks were a topic of idealist academic research. Now, there are 15-year-old Ethereum developers that I see on Twitter. They know nothing about the point of p2p networks - this also applies to older developers.

There has been a change in technical domains.

Disruption

Inventing technology and using it have always been different things. Yet, today, their difference is becoming disruptively big and dangerous.

Will online resources successfully teach the infrastructure of new technology? Unfortunately, there is not much data in hand to guess. Right now, it is only instinct.

There is one thing for sure, though. Newer generations who grew up with online resources never understood how to question and experiment. They were a part of an impatient world dominated by instantly accessible technology.

So, who will innovate? Not the dead, obviously. It will still be our generation and the upcoming ones. Yet, in a capitalist-driven economy where builders get most of the praise, inventors might diminish.

Will we need the fundamentals of what 90s people did so we can build holograms? In my mother language, there is a term "there is no need to rediscover America." This means that we should build upon what is already built. Yet, technology is disruptive. Who knows? Maybe the days without Amazon Web Services are coming, and we should be technically prepared.

Resources

  1. Linus Torvalds Remembers the Days Before ‘Open Source’.

  2. How to fix the web | Brendan Eich | TEDxVienna

  3. IT employment prospects: beyond the dotcom bubble

  4. Linus Torvalds and Linux as James Surowiecki describes

  5. Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

  6. Twenty years after the dotcom crash, is tech’s bubble about to burst again?

  7. Web Archive