What is software made of? What are the components? Ask software engineers of various disciplines and language expertise, and you’ll likely receive a fairly predictable set of responses: Software is comprised of source files, a build system and, if you’re lucky, documentation.
Digging a little deeper, one might ask: What are source files comprised of? Source files are made up of classes, methods, functions, variables, statements, etc. These are the components that make software work, but they are only sufficient descriptors when describing software at a single point in time (just barely).
Let’s expand the requirements of a software project to include the development process, release management, support and maintenance. Would that change the answer? As a maintainer of a Linux kernel subsystem, I work on one of the largest and most collaborative open source software projects in the world. In order to manage the rate of change, resolve code conflicts from independent contributors and identify where bugs are introduced, I rely heavily on strong change control management. If you were to ask me what software is made of, my answer would be, “commits.”
When I consider a software package, I am interested in its history, as well as its current functionality. I want to know how it became what it is. The commit log provides the origin and history of every line of code. It tells me much more about a function than just a snapshot of the statements making up that function in the latest release. A review of a snapshot of code may create a false perception that the section of code was developed intentionally all at once. In reality, it’s most likely the result of an initial implementation followed by a series of changes, possibly by multiple contributors.
Strong change control management is just as important for small, single developer projects as it is for large projects with thousands of contributors. If you’ve ever read a piece of code and thought, “Why did they do it that way?” it is very possible that they didn’t. Bugs are often introduced by changes that miss the broader context of the code developers are changing. In these cases, having the history available to compare against the current snapshot can prove enlightening for why a piece of code was written the way it was. It’s worth pointing out that this applies equally to the question, “Why did I write it that way?” After all, every developer has asked themselves that question at some point.
Consider the changes we create to be integral components to the software we are developing, and not as transient objects to be discarded once the change is incorporated. The change must justify its value; its description must match its implementation. If the change is the deliverable, it becomes more tangible, and we begin to think and talk about software with emphasis on commits as the fundamental building block. This, in turn, leads to considerably more maintainable software.
Learn more about open source software and hardware:
- What to Expect from an Open Source Project
- Hard(ware) Lessons Learned: Getting Started with Open Source Hardware
- Introducing vSphere Integrated Containers Open Source Software
For more news on VMware’s open source contributions, stay tuned to the VMware Open Source Blog and follow us on Twitter @vmwopensource.
