What is Software Development?

Introduction

Software development is the process by which source code is produced in order to create a program that fulfills some goal. For most organizations, this often means automating something that humans would do manually, though this is not always the case.

There are some basic principles to consider about software development. Some of the principles address misconceptions, while others address the counterintuitive nature of software development generally. Remember that software development, unlike physical engineering efforts like building bridges or ships, is not constrained by physical reality. There is a much higher level of complexity due to this decoupling from physical reality since software can reach unbounded levels of complexity without standard physical limitations.

Things to consider

Don’t use tools to solve people problems

Many people want to use software or tooling to solve problems that are fundamentally human problems. The right way to identify this is to ask yourself “Is the lack of tool X the reason we are having this problem?” This is true whether X is microservices, a particular group collaboration tool, or any number of other fashionable technological solutions. Most difficulties organizations face are not due to lack of a particular technology or tool, but due to lack of leadership clarity and ability, coupled with bloated middle management. If you are trying to solve an organizational or people problem with tooling, you will only find yourself with the same problem that has been exacerbated due to the introduction of said tooling.

Ask yourself “Is lack of software/tool X really the problem? If we had that, would we be better?” The likely answer is that the missing item is organizational/HR, and not technological, in nature.

Software is never done

Unlike physical engineering efforts, software is never done in the way that a building or a ship is done. However, much like a building or a ship, constant maintenance is required even if no new features are added to the software. The idea that software will be built and then shifted into maintenance mode or sustainment is both a misnomer and misguided. Software that is put into such a mode is rarely updated and often hated by users, not to mentioned often a target for those who would exploit outdated or unmaintained software containing security vulnerabilities.

Software is hard because it is unique

Most of the time software is created in order to solve a problem that has not been solved yet. Because of this, there is a low degree of repeatability and a high degree of error. In fact, the majority of software projects fail if a criteria for failure is staying on time and on budget. The reason for this is that most software solutions are solving a particular flavor of a business problem that has not been solved before. If it has been solved before, there is usually already an industry-standard solution available for solving that problem with something like Microsoft Office, Google G Suite, and so on. If you are trying to solve a software problem, that has not previously been solved in your enterprise, you should keep this in mind. You might know, generally, how to drive from New York City to San Francisco, but that does not mean that you know in advance all the traffic jams, rest stops, and other delays that will occur along the way. Every time that drive is made it will be a little bit different. Software development is the same.

Because software is unique, it’s hard to estimate

In the same way you can estimate your drive time on a maps app if you want to drive from New York City to San Francisco, you can estimate the time it takes to finish some piece of software. However, you are well aware that there are a variety of things that might cause your software project to take more or less time. Writing software is not like constructing a building wherein you can figure out, with a high degree of precision, the materials and time you will need before you start. Because software is unique, it is hard to estimate, and estimates for software project should never be used as commitments.

Build the smallest thing you can in order to deliver value to users that is also consistent with broader strategy

Because much software development is unique, and because it is hard to estimate, the best way to minimize risk and maximize efficient use of time and money is to deliver the smallest amount of value to users, that is also aligned with your organizational strategy, and then continue to iterate from there. Trying to work in larger increments invites larger risk.