Joel Spolsky: Abstraction Level for Developers

April 11, 2006

A young man arrives in the city. He looks good and has some money in his pocket, it is easy for him to find a common language with women.

He speaks little of his past, but it is obvious that he spent a lot of time in a soulless big company.

He is certainly friendly and sociable, calm and confident, not arrogant. Therefore, it can easily take a little work from the bulletin board in the local Cafe for programmers. But quickly losing interest in insurance database projects, web pages for housewives and financial settlement engines.

A year later, he calculated that he had accumulated enough money to pay his modest expenses for the year. Therefore, after consulting with his faithful German shepherd, he puts the computer in a sun-drenched room, a rented apartment and installs carefully selected tools for work.

And he sits down to write code.

And what code is it. Impeccable, artistic, elegant, no bugs. The user interface imitates the thinking process of a person so well that people to whom he shows the code in the Cafe for programmers hardly notice the user interface. This is a brilliant job.

Inspired by the feedback of his colleagues, he begins to engage in business and is preparing to take orders. His modesty rules out any claims, and after a month the situation on his bank account does not look so encouraging. So far, only three orders have been accepted: one from the mother, one from the anonymous benefactor in the Cafe of Programmers, and one submitted by him to test the commerce system.

In the second month, orders no longer arrive.

It surprises and upsets him. In a large company, new products were created on a regular basis, and even if they were rude and inconspicuous, they were still sold in reasonable quantities. One product he worked on there was a big hit.

After several months, his financial situation begins to look a little shaky. The dog looks at him sadly. Not quite understanding what was happening, but seeing that his face looks worse than usual and he seems unable to gain strength to go out with friends, or go shopping to replenish supplies, or even swim.

One morning, a local seller refused to extend his debt, and his banker had not picked up the phone for a long time.

A large company is not revengeful. They recognize a talented employee and are happy to hire him back with a higher salary. He soon looks better, he has new clothes, and he regained his old self-confidence. But something is missing. A spark in his eyes. The hope that he could become the master of his fate was gone.

Why didn’t he succeed? He sure knows. “Marketing,” he says. Like many young technical experts, he is inclined to say things like: “Microsoft has products worse, but better marketing.”

The term “marketing”, uttered by a software developer, simply means all these business troubles: all that they really do not understand in creating software and selling it.

In fact, this is not exactly what marketing means. Microsoft has pretty terrible marketing. Can you imagine that after this dinosaur advertisement someone really wants to buy Microsoft Office?

Software is a conversation between a software developer and a user. But in order for this conversation to take place, it takes a lot of work that goes beyond software development. This requires not only marketing, but also sales, and public relations, and office, and network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

But what do software developers do? They design and write code, they mock up screens, they debug, they integrate, and they test things in the source control repository.

The level at which a programmer works (say Emacs) is too abstract to support a business. Developers working at the abstraction level need an implementation layer — an organization that takes their code and turns it into products. Dolly Parton, working at the “singing a good song” level, also needs a huge implementation layer to record and book concert halls, take tickets and set up audio equipment, as well as promote records and collect fees.

Any successful software company will consist of a thin layer of software developers distributed over the top of a large abstract administrative structure.

Abstraction exists solely to create the illusion that the daily activities of a programmer (designing and writing code, checking code, debugging, etc.) are all that is required to create software products and bring them to the market. Which brings me to the most important point of this essay:

Your first step as a manager of the software development team is to build an abstract development layer.

Most new software managers skip this point. They continue to think about the traditional, command-and-conquest management model that they learned in Hollywood films.

According to Command-and-Conquer (General Staff), executives find out where the business will go, and then give the appropriate orders to their lieutenants to move the business in this direction. Their lieutenants, in turn, divide the tasks into smaller pieces and give orders for their implementation. This continues down the org chart until, in the end, someone below does some work. In this model, the programmer is a tooth in the car: the driver who performs one part of the orders of the manual.

Some businesses actually go this route. You can always find out when you are dealing with such a business, because the person you are talking to is doing something meaningless and he knows this, he can even worry about it, but they can do nothing about it. It is an airline that loses a million miles of a customer forever, because they refuse to change his irrevocable ticket, because he could not fly away due to family circumstances. This is an Internet service provider whose work service is worse and worse, and when you cancel your account, they continue to bill you, when you call to complain, you need to call a paid number and wait an hour, and then they still refuse to return you money until you start a blog about how much they suck. This is a Detroit automaker who long forgot how to make cars that people might want to buy, and instead switched from a market strategy to an advertising strategy, as if the only reason we don’t buy their crappy cars is because the discount not big enough.

Enough

Forget it. A hierarchical command and control system was tested, and it worked for some time in the 1920s, competing with pushing carts, but it is not good enough for the 21st century. Software manufacturers must use a different model.

At a software company, first priority Guides should be the creation of this abstraction for programmers.

If somewhere a programmer is worried about a broken chair or is waiting for a response from Dell to order a new computer, then the abstraction has leaked.

Think of the abstract layer of your development as a big, beautiful yacht with insanely powerful motors. It is impeccably maintained. Gourmet dishes are always served like a clockwork. Maids work twice a day in cabins. Navigation charts are always up to date. GPS and radar always work, and if they break, there is a spare below the deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether there is tuna or salmon for lunch. Meanwhile, a large team of professionals in a starched white uniform tiptoe spinning beneath the deck, keeping everything in working order, filling gas cylinders, scraping seashells, and smoothing napkins on the table. The support staff knows what to do, but they take their signals from their salted old man, who nods slightly in certain directions to coordinate the entire symphony so that programmers can abstract from everything that concerns the yacht, except speed, direction and what they want for lunch.

The management of a software company is primarily responsible for creating abstractions for programmers. We build a yacht, we serve a yacht, we are a yacht, but we do not operate a yacht. All that we do is to provide abstraction to programmers, so that they can create excellent code, and so that this code can fall into the hands of customers who benefit from it.

Programmers need a Subversion repository. Obtaining a Subversion repository means that you need a network and a server that must be purchased, installed, reserved and provided with uninterrupted power, and that the server generates a lot of heat and that it must be in a room with additional air conditioning, and that the air conditioner must have access to the outside buildings, which means installing an 80-pound fan unit on the wall outside the building, which makes the owners of the building nervous, so they need to bring their builder to agree on where to install the unit to conditioner (decision): (on the external wall, here, on the 18th floor, in the most uncomfortable place), and the owners call their lawyer, because we have to sign so that they are allowed to do this, and then the air conditioning installation guys with rigging appear, which is not convenient, which makes the foreman nervous, and it doesn’t allow them to get out of the 18th floor window in a Mattel belt made of 1/2 ″ pink plastic, I swear to God, it could be a Barbie Disco belt, and someone should call the construction worker again agent and find out what the hell they suddenly understood after 12 weeks in a construction project that you will need another amendment to the contract for this damn air conditioning, which they knew before Christmas, and they only guessed that if your programmers spend at least one minute thinking about it, then this is already too much.

For the software developers on your team, this should all be abstracted as input svn commit on the command line.

That’s why you have it should be management.

This is for those things that no company can avoid, but if you have programmers who are worried about this, the management has failed, just like a 100-foot yacht will fail if the millionaire owner has to go down to the engine room and fix the engine.

Your typical company was founded by former software vendors, where everything is sales, and we all exist to increase sales. These companies cannot take control of their own because they build software version 1.0 (one way or another), and then completely lose interest in developing new software. Their development team is starving or does not exist, because it never occurred to anyone to build version 2.0 … all that management can do is increase sales.

On the other hand, you have companies created by former programmers. These companies are harder to find, because in most cases they behave quietly, write code somewhere in the basement that no one ever finds, and therefore they quietly fade into oblivion immediately after the Great Ruby Rewrite.

Both of these examples can be easily destroyed by a company that controlled programmers and organized by in order to put the programmers in the driver’s seat, but which has an excellent abstraction, doing all the hard work of converting code into products.

The programmer is most productive with a quiet personal account, an excellent computer, an unlimited number of drinks, an ambient temperature of 20 to 23 degrees Celsius, no glare on the screen, a chair that is so comfortable that you don’t feel it, an administrator who brings mail and orders manuals and books, by a system administrator who makes the Internet as accessible as oxygen, by a tester to find errors that they simply cannot see, by a graphic designer to make their screen beautiful, by a team of marketers so that the masses would like to get their products, by a team of sellers to make sure that the masses can get these products, technical support that helps customers get the product to work and helps programmers understand what problems are causing technical support calls, and about a dozen other functions support and administration, which in a typical company, add up to about 80% of the salary. It is no accident that the Roman army had a ratio of four servants per soldier. This was not decadence. Modern armies probably operate at a 7: 1 ratio. (This is what Pradeep Singh taught me today: if only 20% of your staff are programmers, you can save 50% on salaries by outsourcing them to India, how much competitive advantage do you actually get from this 10% savings? )

The main responsibility of management is to create the illusion that a company that deals with software can be started by writing code, because that is what programmers do. And although it would be great to have programmers who are also well versed in sales, graphic design, system administration and cooking – this is unrealistic. Like teaching a pig to sing, it takes your time and annoys the pig.

Microsoft is doing such a good job at creating this abstraction that Microsoft graduates are notoriously difficult to create companies. They simply cannot believe how much has passed without their knowledge, and they have no idea how to recreate it.

No one expects Dolly Parton to know how to plug in a microphone. Behind her is an incredible network of managers, musicians, record technicians, record companies, visiting artists, hairdressers and publicists who exist to create an abstraction which, when she sings, is all that millions of people need to hear her song . All the support staff and management that make Dolly Parton’s work possible can do their job in the best way, providing the most perfect abstraction: the most perfect illusion that Dolly sings for us. This is her song. When you listen to it on your iPod, there is a huge infrastructure that makes this possible, but the best thing that the infrastructure can do is completely disappear. Provide the abstraction that Dolly Parton uses for us personally.