Throughout my career in software I have observed what I’ll call “naturally occurring” distinctions people make of themselves and of others when it comes to their perceived proficiency with modern technology. I remember back in the 80s where it was fashionable to not be able to program the VCR. People would make this remark nonchalantly with a smile and a gentle laugh as if it was somehow socially admirable to be ignorant. In these times strangely it seems that it was.
Fast forward to contemporary times where everyone who is anyone is using digital computerized technology of some sort. Not only are they using it, but it has become a staple of fashion to be “in the know” about the latest apps, social networks and the like. In many cases this modern social ethos has elevated individuals and companies who in the past would be labeled as nerds, geeks or “too technical” to cultural hero status. Today’s hipster web developer is in the heights of fashion and can now claim membership as one of the “cool kids”.
While fashion and trends come and go there remains some continuity about the activities of the developer that do remain. I believe that these elements of continuity are somewhat abstracted from the action of typing in the code. It is these items that I would like to draw attention to in this particular article.
To begin to expand the idea, let us consider what is involved in creating software. Most software development endeavors large or small involve the following high level activities:
- Architectural Segmentation and Componentization
- Execution Planning
- Resourcing (People, Process, Tools)
- Quality Assurance
Regardless of the type of methodology used, whether that be an iterative/agile type or something else, all of these activities should be attended to in some form or fashion in order to produce a quality product.
Now let us zoom in a bit on what someone in the role of Developer is customarily involved in. In many cases all of the activities above impact development however they are not primary activities of the developer. Generally, the developer is focused on creating the software by entering the necessary software code to instruct the computer as to what is needed to be done. That last statement is important to understand. Let us examine it closer.
“…the developer is focused on creating the software by entering the necessary software code to instruct the computer as to what is needed to be done.”
So the developer is telling the computer what to do. The developer is providing the instructions to the computer. So how does the developer know what to tell the computer to do? There are several elements of understanding involved here. First, the developer must speak the computer’s language. Of course, ultimately the computer speaks in binary numbers and luckily for most of us today we do not need to speak in that language to the computer very often. Second, the developer must know what to tell the computer to do.
Knowing what to tell the computer to do is the epicenter of the art of software development and a critical competency area for any productive developer. While the high level of what will be experienced by the end users has been designed and the coarse structural elements of software architecture have been prescribed and articulated there are still many decisions which are left to the developer that will be made in the course of creating the software.
In my experience in developer roles I begun to see this activity differently as my opportunities begun to accumulate. One of the benefits of many years in the field is exposure to a variety of tools, technologies and business subject areas. After some time, software begins to look different. Software is no longer instructions for the computer. Well, it is but, it is more than that.
Software is a plan.
When a developer sits down to create software, that developer must understand the business problem, the data, the languages being used, the function libraries available and the environment in which the software will run. The developer must know how to get the computer to do what is needed and also how to respond to undesirable conditions of which there are many.
A project manager is in a very similar role. Project managers must know the goals, objectives, resources, schedules and budgets. They must know the vocabulary of the business and of the developers. They must be able to recognize, articulate and mitigate risks and manage issues. When a project manager sits down to develop a project plan the project manager must be able to communicate to the project resources what needs to be done. This of course is not in minute detail however, it is at enough of a level of detail so the the project can be monitored and controlled and so that any resource is not prematurely consumed.
Developers go through similar activities when making decisions about algorithms, what error codes to check, how to handle the errors and exceptions, how to make sure that good input data is received, how to make the best use of system resources like CPU, memory and IO. How to fail gracefully should an expected dependency fail or go missing. Software developers must anticipate all possible scenarios that the software they are creating may need to handle and create the instructions for the computer to execute when those conditions occur. Most if not all of these activities have an analog with project planning and management.
Based on this terse treatment of project management and development my hope is that what becomes visible is that a good software developer is also a good planner. Unfortunately, just knowing how to code is not nearly enough. Also, if one dares to look beyond, one may even begin to approach a conclusion that software is no longer instructions to the computer. Software is the plan for the computer to know how to detect conditions and how to respond to those conditions. Software is a plan.