Developing software can be compared to an organic process like planting a garden. With the right conditions, something will grow, but it may not be what we want or indeed grow the way we want it. We might end up with a garden of roses or a jungle of weeds. Any experienced gardener will tell us that what our garden needs most is planning and tending, and the same is true for software development.
Of course, we can just start writing the code and we will get something—maybe even something that works!—but if we invest a little time and effort in planning before we write a single line, and in ensuring we tend the code we write, then we are far more likely to achieve an end result that bears some resemblance to our initial vision.
We need to manage our software development.
Before we dive deep into knowing what managing software development is, we need to understand that, in essence, it is just a specific form of 'project management'—two words that send most developers running for the hills! A lot has been written about project management and the various styles and techniques thereof, which to the initiated make it live up to its common portrayal as a highly confusing and specialized field. The truth is that usable project management is within our grasp, and we don't need expensive software or a certification to be able to put it into practice. In essence it exercises two distinct, yet complementary skills—task management and communication.
Therefore, I would like you to take a lengthy look at project management and in particular how it applies to software development.
This is one of those things that is easy to say, but not as easy to do—especially for a novice. While we do need to keep a view of the overall project, a project is nothing more than a collection of tasks, and it is the management of these tasks that will help us to successfully complete our project. To help us to understand task management better we will not look at it as a whole, but rather as the sum of its parts. By looking at the specific activities involved in managing tasks it will become clear that it is an iterative process that is driven by logic—something we as developers are meant to be good at! Demonstrating with the help of an example is the easiest way to learn so let us consider a hypothetical project to build a wall for our garden.
Note
Wait, we are supposed to be developers. If we are to remain true to our stereotypes then we would avoid manual labor and possibly even leaving the office. Instead we would just hire a contractor to build the wall for us and get back to writing code. However, even if we do take this approach, does not prevent us from viewing it as a project. Although our contractor will do most of the work for us, we still need to find good contractors, hire them, schedule the work, and pay them. Although it is much easier than the example that follows, we still have a collection of related tasks, and as such is considered a project.
Having decided to defy convention and build the wall ourselves, let's look at the activities that allow us to manage our tasks and complete our project:
Task Determination: Obviously we need tasks to manage, and although our first instinct may be to determine every single possible task at the outset, we need to remember that this is an iterative process so tasks can (and will) be added, changed, or removed later on. We will also find that we do not have to think too hard to determine our tasks—as the saying goes "one thing leads to another"; likewise as one task comes to mind others will become apparent.
Dependency Management: Some tasks can be completed in isolation; others may have prerequisites—other tasks that need to be fulfilled before they can be started. As with determining our tasks, we will find that the dependencies come naturally.
Resource Management: Resources can cover a number of things; unless we have a specific requirement to cater for, it is simpler, and therefore easier, to limit our scope to people. We may only have one resource (ourselves) to worry about or we may have a team, but as long as we include this activity when managing our tasks then we will always be prepared if we need to manage additional resources later.
Scheduling: Once these activities have been completed for the first time (or iteration) we can look at understanding and deciding when a given task needs to be completed. A simple due date will suffice, although we can include a start date if we desire.
Task Execution: Getting it done. There is no point managing our tasks and projects if we never complete them!
Reviewing: As with task execution above, reviewing is an essential part of task management. Just marking a task as completed is part of the reviewing process, but when doing so we can take the opportunity to see how our progress is affecting the list. Are we behind schedule? Has the task we have just completed brought new tasks or dependencies to mind? Always take time to review your tasks, even if doing so is a task in itself.
By now project management practitioners will be complaining about the exclusion of priorities and timescales for tasks, but including these is purely down to your personal preference.
With regards to priorities, if we choose to incorporate them we need a method of representing the priority of a given task. While assigning numerical or alphabetical labels is common practice, it is far easier and more accessible to think of them simply in terms of low, normal (or medium), and high. As part of task determination and dependency management activities, it will also be apparent which tasks are of a higher or lower priority compared to others. A simple rule of thumb would be that if a task is of high priority then, it will most likely have a number of dependencies and hence top our task list.
As for timescales, these will either be so fine grained (task a will take x minutes) or broad (1 week to complete three dependent tasks) that they will just make things complicated for us. If the due dates we choose during task determination are insufficient for our planning purposes then we need to understand why that is before we start incorporating timescales into our task management process.
Getting back to our example of building a wall, let's have a look at the activities in action.
We know we want to build a wall, which is our project goal. The first obvious activity is to decide where we want to build the wall, so we have determined the task of "Choose Location". We also need to prepare the site so "Clear Location" and "Lay Foundation" can be included. Of course for the foundation we need "Dig Foundation". For building the wall we need materials—"Buy Materials", which leads us to "Price Materials" and "Arrange Delivery Date" (if we are not picking them up ourselves). Our site is prepared, and we have our materials so we can now think about "Laying Bricks", which leads to both "Mixing Mortar" and "Cleaning Up".
We have determined ten tasks that need to be completed to achieve our goal from a simple objective. Next we need to think about dependencies—choosing and clearing the location can be carried out while we price and buy the materials, but digging the foundation and mixing the mortar need to be completed before we lay any bricks, and of course we also need the materials before we mix the mortar or lay the bricks.
Managing resources does not require too much effort for this project as we will be doing all the work ourselves, but we may choose our partner to take care of purchasing the materials or a friend may offer to help out with the actual labor, so we must not skip this step.
Now can we begin to schedule the work. The independent tasks such as choosing and preparing the location can be scheduled as we desire. For the other tasks though, we may not be able to make those decisions yet. We may have a rough idea of when we want the wall completed, and if a friend has offered to help then we will know when they are available, but until we have arranged the delivery of the materials we cannot confirm when we will build the wall.
No that we have figured all our tasks, we can focus on task execution—in this case purchasing the materials and arranging their delivery.
Once these have been completed we can go back and review our tasks. We can now mark some as complete, while others will now need to be scheduled. We may even think of more tasks that could be included.
Following this simple example, we can see that with least efforts we now know exactly what tasks we need to do and when we need to do them, so that we can concentrate on getting them done.