Introduction to Sustainability

Why do we need sustainability?

Rails has many features, and we may not need them all. Or, we may need to take some care in how we use them. Rails also leaves gaps in our application’s architecture that we’ll have to fill (which makes sense because Rails can’t possibly provide everything our app will need). This course will help us navigate all of that.

Before we begin, we want to be clear about what sustainability means and why it’s important. We also want to state the assumptions we are making in writing this because there is no such thing as universal advice. There are only recommendations that apply in a given context.

What is sustainability?

The literal interpretation of sustainable web development is web development that can be sustained.

To sustain the development of our software is to ensure that it can continue to meet its needs. A sustainable web app can easily suffer new requirements, increased demand for its resources, and an increasing (or changing) team of developers to maintain it.

A system that is hard to change is hard to sustain. A system that can’t avail itself of the resources it needs to function is hard to sustain. A system that only some developers can work on is hard to sustain. Thus, a sustainable application is one in which changes we make tomorrow are as easy as changes we make today, for whatever the application might need to do and whoever might be tasked with working on it. So, this defines sustainability. Let’s now discuss why it is important.

Why care about sustainability?

Most software exists to meet some need, and if that need persists over time, so must the software. Needs are subjective and vague, while software must be objective and specific. Thus, building software is often a matter of continued refinement as the needs are slowly clarified. Of course, needs have a habit of changing along the way.

Software is expensive

Software is expensive means the significant costs associated with building and maintaining software. This expense primarily stems from the high level of expertise required to develop and sustain software systems. People who can write software find their skills to be in high demand, garnering some of the highest wages in the world, even at entry levels. It stands to reason that if a piece of software requires more effort to enhance and maintain over time, it will cost more and more and deliver less and less.

In an economic sense, sustainable software minimizes the cost of the software over time. However, there is a human cost to working on software. Working on sustainable software is more enjoyable. They say employees quit because of managers, but there are developers that quit because of codebases.

Of course, it’s one thing to care about sustainability in the abstract, but how does that translate into action?

If we are a hired consultant, this is excellent advice. It gives us a framework to be successful and manage change when we are in a situation where we have very little access to information. The strategy—build for only what you 100% know you need—works great to get software shipped with confidence, but it doesn’t necessarily lead to a sustainable outcome.

For example, no business person is going to ask us to write the log statements so we may understand our code in production. No product owner is going to ask us to create a design system to facilitate building user interfaces more quickly. No one is going to require that our database have referential integrity.

The features of the software are merely one input into what software gets built. They are a significant reason, but not the only reason. To make better technical decisions, we need access to more information than simply what someone wants the software to do.

Do we know for what economic or behavioral output the software exists to produce? In other words:

• How does the software make money for the people paying us to write it?
• What improvements to the business is it expected to make?
• What is the medium or long-term plan for the business?
• Does it need to grow significantly?
• Will there be a need to increase the traffic?
• Will there be an influx of engineers?
• Will they be very senior, very junior, or a mix?
• When will they be hired, and when will they start?

The more information we can get access to, the better because all of this feeds into our technical decision-making and can tell us just how sustainable our app needs to be. If there is an influx of less experienced developers, we might make different decisions than if the team is only hiring one or two experienced specialists.

Armed with this sort of information, we can make technical decisions as part of an overall strategy. For example, we may want to spend several days setting up a more sustainable development environment. By pointing to the company’s growth projections and our team’s hiring plans, that work can be easily justified.

If we don’t have information about the business, the team, or anything other than what some user wants the software to do, we aren’t set up to do sustainable development. But it doesn’t mean we shouldn’t ask anyway.

People who don’t have experience writing software won’t necessarily intuit that such information is relevant, so they might not be forthcoming. But we might be surprised at how much information we can get from someone just by asking.

Whatever the answers are, we can use this as part of an overall technical strategy, of which sustainability is a part. As we go through this course, we’ll talk about the considerations around the various recommendations and techniques. They might not all apply to our situations, but many of them will.

This brings us to the set of assumptions that this course is based on. In other words, what is the situation in which sustainability is important and in what scenarios does this course’s recommendations apply?