I Perspective🔗

What does the life of a software system look like?

The shortest lie in software is “it works,” where “it” referes to code. Although the point of this sentence is that real software is hard to get really right, the implicit message is that “even if it works, you’re not done yet.” Software systems once deployed need a lot of attention and a lot of additional work. Software engineering researchers label this second phase maintenance. For all kinds of reasons, this word has acquired a negative connotation in the developer community. In the end, though, only permanently maintained software is truly relevant and important.

Maintenance is hard. People dislike maintaining software because they have to read and comprehend old code before they get to do anything. Sometimes this reading-and-comprehending phase confronts them with the results of their own inadequate programming skills from their early days on the job. Sometimes they don’t even know who created this code decades ago, and they just wish they could rewrite it all from scratch.

All of this brings us to the crux of the matter, namely, our perception of software as “something that works” but also “something that communicates complex thoughts across potentially long periods of time.” From this formulation, it also becomes clear that social responsibility has two sides: on one hand there is the end-user of the software; on the other, we find the software developers themselves and how they relate to each other. While both are important, this book focuses on the second aspect, the software developers’ responsibility to each other. In the end, such code also tends to serve end-users better than the code “that works.”

Let’s investigate these arguments slowly and carefully next.

1 The Death of Software, The Life of Software🔗

Most software dies an early death, without anyone ever laying eyes on it.

College majors in computer science know this fact well, too well. In most courses with a programming component, they spend hours writing programs, struggle to get them right, turn them in on time, and then get back the output of an auto-grading system. The professor certainly didn’t look at their program; the teaching assistants didn’t. And when the task is done, the students won’t ever look at their code again.

Professional software developers have similar experiences throughout their career. Someone has a great idea for a new product or feature. The team toils day and night to get it finished. Until eventually some “guy in a suit,” also known as a manager, tells them that the marketing department no longer believes in the idea. And then it’s all over.

Even after the launch of some software, chances are that it fails. It just doesn’t attract enough users. It doesn’t make enough money. It’s a failure, so there is no need to keep it around and invest in its maintenance.

When software survives, it is likely to survive for a very long time. In all likelihood, it will survive its creator. Consider the simple example of a credit card. If you have never heard of these programming languages, look them up. It’s educational. Even though you may pay for your espresso with a mobile app that combines Objective C with HTML and CSS, the transaction is probably going to invoke some COBOL or RPG code from the 1960s. On its way, it may trigger some JavaScript scripts; run Java on the server; poke a C/C++ routine or even some old Pascal; and then land on the old COBOL code base—a code base that is 50+ years old.

In the 1990s, when your parents first started paying for things on the web with credit cards, the banks were panicking. Everyone knew that the year 2000 was coming and that the COBOL developers in the 1960s and 1970s had never imagined their software to be in service beyond 1999. They represented every date with two digits per day, per month, and per year. Memory was in scarce supply and therefore expensive. But what does 11 mean in the real world? 1911? 2011? This choice of representing dates as two-digit data became known as the “Year 2000” problem.

See this WSJ article for details.—More generally, the data representation of amounts poses a problem that most interviewees for developer positions flunked for decades. If it ever comes up in your interviews, remember that no built-in data type is good enough.

Dates aren’t the only one form of information that poses such problems. In 2021, the stock price of Berkshire Hathaway reached a price of close to $429,496.7295, which as an integer (price in 1/1000th of a dollar) is the largest integer certain languages can represent. At that point, the software developers got worried and rushed to fix the problem so consumers would be protected—which ironically caused a serious problem the next trading day. Indeed, there are many other systemic glitches that made it into software systems and that some developers eventually had to fix. And the problem never disappears, So imagine yourself be tasked with reading such badly aged software and spending just enough effort to eliminate such problems—because your company’s well-being and your high salary depend on it.

So what is software?

Surviving software systems are messages across time—weeks, months, years, decades—from one software developer to another. Initially, the message may go from one software developer to the same one, just an older version. Or one team member may hand it over to another member of the team. As time goes by, the software may need less and less attention. Everyone involved in its initial creation may move on. Yet, on occasion, someone needs to take a look at it. And every so often, an entire team may have to comb through all its details because the software needs a major overhaul.

Why does software need attention?

During the “birth phase” of a software system, developers may focus on adding features, fixing basic bugs, and making the user interface convenient for customers. After the launch, customers may use the software in unforeseen ways and discover problems; the user interface may need tune-ups for people with less exposure to modern software; some may wish for an additional feature; or they may request a fast response in scenarios that the original developers didn’t anticipate. Even after a product has been stable for a while, it is never truly finished. Software is the most malleable material with which humanity has built amazing artifacts, and we all—end-users, managers, developers—think that because of this malleability, we can turn software into something new and better at any point in time.

In summary, a surviving software system is a continuously evolving product. At different points in time, the evolution speeds up or slows down. But the system evolves. Evolution means changes, and changes affect both end-users and the system’s developers. The burden on the latter is immense: they must ensure that end-users are safe and secure, all while helping future developers understand how the product functions. In other words, software developers have an obligation to many parties—that is, an obligation of social responsibility.

2 Are You Socially Responsible?🔗

What is social responsibility?

One intepretation of “social responsibility” focuses on the users and their satisfaction. End-users of software deserve (at least) the same quality service as the users of grocery bags, bridges, coffee cups, elevators, and so on. After all, our software ends up in mobile games, nuclear reactors, point-of-sales systems, X-ray machines, or airplanes. Some of those systems are life-critical; some are irrelevant to life but a good source of amusement.

Think of the pilots of a Boeing 737; they want the control software to work correctly. Consider “friends” on social media; they might be less concerned with correctness than privacy. In both cases, the convenience of the graphical user interface plays a large role. So making software work properly and well is a many-faceted problem, and it definitely connects developers to other people—end-users as they are called here.

Exercise 1. Can you think of other properties an end-user may expect from software? For example, we could weaken “correct” to “fail-safe,” which means “the code should never perform any harmful actions.”

Although there is no denying the importance of this form of social responsibility, software developers rarely get directly involved with these concerns about end-users. In many companies, managers develop functionality criteria, perhaps in conjunction with customer and/or end-user representatives but usually without much input from developers. The marketing guys may make promises about how safe user data is, and developers have to live up to those as well as they can. Finally, companies also often employ people who study the interactions between end-users and the software, and these people then turn those studies into feedback for developer teams. The point is, social responsibility to end-users is always expressed in terms of specifications that software developers must simply accept.

The other interpretation of “social responsibility” concerns a developer’s responsibility to other developers. If developers are somewhat insulated from end-users, they are closely connected to their teammates. A common and good practice is to rotate pieces of a code base among the members of a team, meaning one close colleague receives code from another. Consider the reaction of the second if the code from the first is difficult or impossible to understand. “This colleague just robbed me of hours of my time, my evening with my wife/boyfriend/son with this bad code.” That’s the best reaction to expect. Even if a team doesn’t rotate responsibilities, a new colleague may encounter this reaction. Or, months and years later, a maintainer newly assigned to this old code may get a shock looking at it—and chase down the original creator to share some thoughts.

At this point, everyone will want to respond with a resounding “yes” to the titular question. Most of you might think “socially responsible” means being nice to a pair programming partner and getting along with the team. But that’s easy. You see those people every day, they see you, and a violation of a social protocol has immediate, unpleasant repercussions. In the software business “being nice” to teammates isn’t even remotely enough; indeed, it might be counter-productive.

True social responsibility includes caring about the people who take on the team’s code base down the line, whether we know them or not. For the sake of these future colleagues, it is necessary—socially resonsible—to critique what our immediate colleagues produce and to ask them to critique our work. This mutual critiquing must substitute for the reaction maintainers will have when they take on our code base, in a year or ten years from now.

The goal of this book is to make you aware of this form of responsibility, both in terms of working with others and working on software. The expectation is that this training prepares you to understand the immensely difficult trade-off involved in developing software. It may mean being a little bit “less nice” to people you meet on a daily basis and to trade their feelings for the welfare of yourself (taking over their code in a few weeks); for the welfare of other team members; and for an uncountable number of others in the future. This trade-off isn’t easy, because we all prefer to “get along.” Getting this trade-off right requires following basic development and interaction techniques. Practicing these techniques on a daily basis turns them into second nature, which makes them useful—and acceptable—in the long run.

Reading

Kent Beck. Extreme Programming Explained. Addison-Wesley. 1999.—In this book, Beck repeatedly argues for eight-hour days, 40-hour weeks, vacation time, and time for family. His key argument is that a software developer needs time to recover from thinking intensively. It is occasionally worth re-reading such passages, such as the one near the end of in his book. Many software developers experience the opposite, however. They are confronted with an impenetrable code base, without means of navigating it, without a systematic approach. They spent endless hours understanding relationships that the original creator had in mind and left undocumented; they spend nights figuring out spaghetti codeLook up the term “spaghetti code”. and the thinking behind it, which again, the original creator had a chance to express clearly. All these hours could be spend on a spouse, children, a vacation, hobbies, etc. From this perspective, the original creator is a “thief,” a person who steals these hours from the maintainer.