We have seen that effective project management consists of managing tasks and maintaining communication. We need to apply this fundamental approach to software development as well. While there are additional considerations, as there are with any other special field, it is the core capabilities of determining what needs to be done and communicating with all interested parties (i.e. team members and customers) that distinguish the successful projects from the unsuccessful ones. The good news is that due to the nature of software development, and the environment in which it is performed, both of these will be much easier that the actual development itself.
The determination of tasks will be as natural a process as it was in our example of building a wall. There are obvious activities that need to be carried out and they will have an obvious sequence in which they need to be completed. Unless we are running an open‑source project where developers can come and go, our resources need to be clearly defined (even if it is just ourselves!). Scheduling will be driven by the deadlines we have been set, have agreed to, or have set for ourselves.
Since we are working on, and with, computers we have two ready methods of communication available to us—email and the web browser. The former allows us to participate in a two way dialog with others, while the latter was designed for disseminating information—with the right infrastructure of course.
With the basics of project management covered, we need to consider additional features that benefit software development:
Documentation: For the developers this could take the form of requirements, best practices, or API documentation. For the users we have installation, usage, and troubleshooting guides as well as the ever-present Frequently Asked Questions (FAQ).
Roadmaps: Software development is rarely a single project with a set goal. More often the software itself goes through a series of versions or releases, which can be translated to a series of connected projects (for each release) or an open-ended one. Roadmaps allow us to share—communicate—these plans with both our developers and users.
Error Reports: No software is perfect—no matter how much its developer likes to claims it is! —and so we need a mechanism for our testers and users to report faults and errors to us so that they can be managed. Capturing error reports is not the end result though. We must also ensure that they are managed so they can be resolved to both our and the reporter's satisfaction.
Requirements: These could come directly from a user in the form of a feature request, or we could determine that a particular error report requires us to change our software. Irrespective of how we receive or capture them, they need to be managed in the same manner as error reports.
Revision Control: Revision control allows us to store all files related to a particular software development project. In addition to storing the files, it also stores versions of each file, so that changes can be tracked. This allows us to see who has done what with each file, and if necessary, roll back (reverse) those changes. A well-managed software project has the ability to have the code reviewed at any point during its life cycle. Whether we are checking for bugs in the currently released version while a new one is being actively developed, or re-creating a previous version to see why something was changed, revision control is a mainstay of software development these days, which no serious project is without, especially when development is handled by a team, particularly a geographically distributed one.
Releases: To allow our software to be used we need to release it—either as an installation package or a bundle of files—and we need to provide access to those releases.
Providing these features is only part of the battle—for them to really add value to our development process they need to be implemented as a cohesive whole. If documentation is in one system, error reports are in another, and tasks in yet another then that solution is unwieldy and we will resist using it. Stick them together in a system that remains awkward to use and we will still resist using it. Give us a "development support system" that ties these elements together in an unobtrusive way that allows us to focus on what we really care about—developing software and writing code—and we have something that will make our lives easier.
It is not just about providing a solution for the developers though; it is also about the way that they use it. If the system is used in a prescribed way and consistently by all, then we have a process for managing software development.
As we have seen, managing software development goes beyond basic project management, but we can still see the basics: what needs to be done. We have just looked at the additional requirements for software development, and now we will see how this book will help us address them.
Things are much easier to find if we know where to look for them, whether we are talking about car keys or source code. If we lay the foundations, as we did for our wall, before we write a single line of code, then our project has a better chance of succeeding. As with task determination we don't need to plan for every eventuality, we just need to make sure that the obvious basics are covered. We need to consider things as follows:
This would include the following:
How we handle third-party code
Coding style
How we are going to name our files
What we are going to store in our revision control
When (or how often) we are going to put our changes into revision control
What we need to be able to develop e.g. compilers, IDEs, etc.
All these need to be documented—another word that can send developers running for the hills! This may seem like a significant amount of work to do before we even think about our first line of code, but it will save us time in the long run. In addition, once we have done this once, we will be able to reuse some or all of these details for other projects to get a head start next time.
We need to turn our preparation work into a best-practices guide for our developers. They are the users of our system, and they need a user guide to allow them to use it as we intend it to be used. Investing the time in preparing the system and its documentation means that more time can be spent on actual development. By providing our developers, or rather users, with clearly defined standards and practices we remove all ambiguity and reduce friction that could delay our project.
The principle we applied to task management can also be used here—we don't need to prepare for and document every eventuality, we just need to provide solid enough foundations for our developers to build on. We must seek not to weigh our developers down with unnecessary rules, but rather provide just enough to guide them to maximal productivity.
We will also apply the review activity from task management to our documentation—it needs to evolve with our project, not constrain it. As our developers use our system, things may change to suit the project in question, which is a good thing. Our documentation needs to be a living thing, not a dusty set of rules locked away in a library.
We also need to provide documentation of our software to the users, and ideally this will be written as the software develops. Some projects may be lucky enough to have a dedicated technical author, but even those will benefit from writing the documentation alongside the software. If a dedicated resource for documentation is not available then we will certainly find it easier to write the documentation with the software, not afterwards.
Every aspect of software development, from writing documentation through implementing a new feature and fixing bugs to packaging for a release, needs to be considered as a task. We need to make sure that they are all captured and then processed as outlined earlier in this chapter. If we use tasks correctly then the developers will always know what they personally have left to do, and likewise our project leader will know what is left to be done to reach the next release. By using the task information to create and update our roadmap—a concept we will look at in greater detail later—everyone will always be able to determine where we are going.
Now that our "development support system" is set up, our developers know how to use it, and our tasks are being managed, we can finally write some code! We can save ourselves a significant amount of effort by developing in isolation. This means keeping our work separate from other developers' work until it is ready—features and bug fixes are developed away from the main code, and only integrated when complete. This means that:
We are developing against a known base, not a constantly changing one.
We are responsible for making sure our code integrates with the rest; if another developer integrates their bug fix before we integrate our new feature, the blame can only lie with ourselves if our code doesn't work or we break something the other developer fixed.
Isolating code changes can also allow a single developer to tackle multiple tasks simultaneously.
While we may want to plow through the new feature we are adding in one go, it is much better to take small steps and implement it piece by piece. It means we are less likely to introduce bugs by making sweeping changes, and if we are using our revision control to track every change then we have a much richer history to step back through when required. As with everything there needs to be balance found, and a good rule of thumb is to only store a change in our revision control when that particular change works. Then we can move on to the next change with confidence.