What is Software Engineering?
Summary
This article is about the “What is Software Engineering?” chapter in the Software Engineering at Google book. This article goes into more depth of discussion on the differences between software engineering (SE) and programming. This chapter of the book takes the main themes and ideas that we discussed last week — such as time and change, scale and growth, and trade-offs and costs — and develops them further. The chapter considers these topics with a greater focus in discussing how Google considers these topics, along with providing different examples about the importance of these topics from their own experience.
In the podcast interview SE Radio 609: Hyrum Wright on Software Engineering at Google, Hyrum gives us a picture for thinking about how programming differs from software engineering: he compares it with a carpenter and building a house. Different thoughts and considerations go into both. The book uses some different metaphors that might be helpful. For instance, the chapter explains that “software engineering is programming integrated over time,” and so the book expands on this idea of software engineering bringing programming into a new dimension. Intuitively, you can think of the relationship between a square and a cube or speed to velocity (i.e., speed over time).
Where do computer science and/or programming and software engineering overlap? The overlap in the area of software development. With that said, software engineering also considers not only development, but also modification and maintenance.Click to Expand for the Answer
Further Explorations
Time and Change
Time and change as discussed last week has to do with the life span as a project. Google says they work on their project with an indefinite view in mind. The span of a project is relevant because it relates to how much a software engineer can expect the underlying to change. Does all the underlying code need to change in an upgrade or just parts? Here is a graph that visualizes the relationship between the life span of a project and code changes and upgrades. Hyrum’s Law is something else that is considered in this section. Hyrum’s Law has to do with the difference between code working and it being maintainable. It also introduces the concept that — no matter what the project — all the code and functions of the project will be used and relied on in some way.
Scale and Efficiency
This section has a lot to do with considering code changes, aspects such as their impact, size, and how often that they should happen. For example, in 2006 Google needed to update their compiler. It had been years since that had happened. Which also meant Google’s code was only running through one compiler and had never been tested on another. Many of Google’s personnel were learning new tools and skills to make this change. In addition, they had to consider the correctness of the code generated by the compiler and how they would confirm it. It was hard and there was a large learning curve for many people in the organization. Since then Google has worked to make smaller changes more frequently even sometimes as often as every week or two.
Scale and efficiency also has to do with scale not only of code and the database but of people. Google considers the code people write for their codebase and then considers if one person will be able to maintain it and care for it over the years or if it will constantly require more people to maintain and at what rates. Google considers whether or not the amount of work scales up as the codebase does. One aspect that increases efficiency and effectiveness are having lots of expertise in your personnel so that it would only take one person to do multiple different jobs. Another aspect to consider in automation since, by automating different aspects of a process an organization may not need as many people to fill those roles.
The discussion of scale and efficiency relates to the topic of software sustainability. And what is software sustainability? Software sustainability is the idea of how manageable and how much will it cost to say run all the code or how many people does it take to maintain parts of the code and are these processes cost effective. This also relates to the idea of upgrading software and how that process will go. The book actually mentions that Google has come to their process of sustainability by mostly trail and error.
What is this graph depicting? The cost of finding bugs can vary based on when in the development process you find them. The goal is to find the bugs as early in the process as possible so the changes don’t cost as much as it would, after deploying your artifact.Click to Expand for the Answer
Trade-offs and Costs
Trade-offs are always present, but they are present in different ways. The are present in both decisions for the code base and in personal time and effort. One big idea that Google considers is not making decisions on a “because I said so” basis. Rather they would prefer to have a reason and well-thought-out decisions for different courses of action. In addition, there are many different types of costs that a software engineering team must consider!
What are some cost and examples of those costs relating to software engineering? Here are some of the costs to consider: financial, resource, personnel, transaction (i.e., taking action), opportunity (i.e., not taking action), and societal costs.Click to Expand for categories the book referenced
Takeaways
One major takeaway from this chapter was thinking about mistakes and decision making. It is important to tackle bugs and challenges as soon as they arise. Often if people wait to address different issues that will make them harder to fix in the long run. This was addressed when thinking about the compiler change at Google in 2006. If Google had waited longer to tackle the upgrading of the compiler because they knew it was going to be a hard job, that would have only made the job harder and more challenging. Addressing issues where they are and not shying away from them is important. In addition, as our team moves forward it is important to think about the impact that smaller, more frequent, changes can help prevent massive changes in computing tools.