Software development processes for successful software
Successful software. Yes, it exists today. And it is not an accident. It typically occurs because software development teams think beyond the writing code. They consider the wider software release world, including:
- Project Management
- Release and Configuration Management
- Quality Assurance
- Production Release
- Production Performance, Maintenance and Operations
- Customer Support
- Continuous Improvement
- Creative work environment
When software development teams seriously consider these items when designing, developing and releasing projects, time is not wasted, other groups develop an appreciation for the development team, and iterations/releases go much more smoothly. Much of what I outline here is common sense to many, yet time after time I see development teams and individuals neglect this. Additionally, I often see development teams that have good intentions, but lack the time. Often external groups fail to see the benefit of the processes discussed below. It is my hope that this article helps development teams as well as other groups within a company recognize the benefit of these practices.
First step is to understand as clearly as possible what it is you need to build. The process for gathering and documenting requirements varies greatly from company to company. Whatever process your company utilizes, there is some form of communication to the development team regarding what is needed. It is critical that the development team has a clear picture of what is needed. Sometimes this will take place though several release iterations, but the point I want to stress is that when there are uncertainties, a developer needs to do the leg work necessary to resolve the uncertainties. A developer must also have an audit trail preserved as to the resolution. Verbal resolution is usually not good enough. You want proof that this was the resolution as it could be forgotten. I’ve seen this happen hours before a production release.
Once the development team has a fairly clear understanding of what is expected, the task of designing the implementation begins. Again, this varies company to company, from detailed design specifications to informally explaining the planned coding approach to a lead developer. This is an important part of software development as often problems can be surfaced at this point, which is still early in the process. This saves critical time and money later in the process. Don’t waste the time of other functional groups by releasing substandard code. It is preferable that the individual(s) that review the design have system wide knowledge and experience.
Once the design is agreed upon, the actual coding and unit testing can begin. Once this nears completion, a code review should take place. A code review can often surface issues early in the process. Catching issues in before release to a QA team saves time and money. It is important not to just review the code, but to look at the code in a wider context. The following areas should be covered:
- Content of code changes (new features, bug fixes)
- Review of source code
- Review of testing
- Review of any supporting documents, such as release notes and operational guides
I recommend utilizing a code review template to capture any action items from the above areas. The code review section of the document should capture all comments and suggestions from participants. This is important part of fostering an open, creative and innovative environment. Note every item needs to be addressed, however every item should be captured. The participants can must decide if the item must be included or if it can be deferred.
Documented test plan
During the design and coding phase, notes need to be kept that detail the testing of the feature(s). These notes will then be turned into a formal test plan that is submitted to QA on or before initial release to QA. This formalizes the development to QA communication, and is an important document that is often used by production support teams. In some organizations the QA group will create the formal test plans, however the development team should still create some form of development test documentation.
Automated build process
What ever build tool your team uses, the build scripts should be rock solid and easy to reproduce. Configuration data tied to local developer workstations need to be externalized. Scripts should be created to both build and package the release. The packaging of the release needs to take into account the production installation image, and should replicate this image as close as possible. Once the scripts are created, development teams should continue to seek out opportunities for improvement. Often you can build testing scripts into the build process which lead to greater and greater quality of the basic release artifacts. When you are ready to release to QA, it is important to go through the process two complete times. First, the development team should make sure all the code for the release is checked into source control. The designated developer should check out the code, build and package the release. Once this is complete the release artifacts should be closely inspected. If the developer is satisfied at this point, label the source, totally clean (delete) all project directories and files (make a back up first). Now you are ready to go through the process the second time, only this time you check out the source from the label you created the first time. Make sense? This ensures that no artifacts on the developers machine were not in the source control tool, and it also guarantees that the release can be recreated.
Source code management
Of course source control should be utilized to support new releases and recreate existing releases. I personally use a branch by task strategy. This is where every feature/task has its own branch created. When release time comes, tasks for the release are selected and merged into an intermediate integration branch. If the integration branch passes development testing, the integration branch is merged back into the main code line and the release is cut.
By having your build process replicate the production install image as closely as possible, you make the hand off to Release/Configuration Management much easier. By thinking of the production image of your software, you anticipate and account for the process that will lead to a successful and pain free production installation. If questions come up when you are considering this, talk to Release Management, they will certainly appreciate it and will usually be more then happy to help work out these issues.
Your development processes need to be solid enough to avoid unnecessary QA cycles. When a release is in QA, make yourself available to the QA staff to help clarify any questions. This will eliminate bugs being logged that are really only questions, and it will help isolate points of confusion to person to person communication. This is usually better then exposing the confusion to a wider group, which can make the development team look as though they have not thought everything out, which in turn leads to lower confidence in the development team by external groups. This also helps you to improve your process so as to avoid the same confusion in the future.
This is the area where software development team often have the biggest challenge. I have seen development teams present realistic estimates and that are immediately rejected. Often the team is forced to revise the original estimates to meet project management time lines. I recall a manager presenting a development schedule that estimated 8 weeks of development. The response from the project manager was a “no way” and “for these requirements” and “did you really read the requirements”. Eventually the software development manager agreed to revise the estimate to 6 weeks. The scope of the release was not changed. At this point, timelines were communicated a wider audience, including the end user community. When the project actually took 8 weeks to complete, the project manager was genuinely confused why it took 2 weeks longer then the estimate, questioning the team’s ability to estimate projects. Software development estimation is critical to software success. You must provide reasonable estimates and stick to them. Do not compromise unless something of equal value, like a dropped feature or added resource, is agreed to. Otherwise you must make it clear that the quality of the release may be compromised if the schedule is indeed pulled in. My motto is “Under promise and over deliver”. In the end your team will look much better being 1 week early then 2 weeks late. At the end of the day most companies will come to realize the benefit to both internal teams and external customers of delivering on time, and an important aspect of this is properly managing expectations and estimates.
This part of the organization is critical. Poor customer support leaves the impression of poor software, whereas excellent customer support will give your customer confidence and leave the impression of quality software, or at least a culture of customer focused continuous improvement. The software development team can help create a first class customer support group by careful attention to the items outlined in this article. Good documentation and prompt attention when customer support requires more expert guidance also will make a huge difference, so don’t ignore this aspect of the software process.
Managing the knowledge that is created by all the processes defined above is an ongoing and critical activity. Developers need to be knowledge management experts. Wiki’s are idea for managing this information. Note that it is critical to continually update whatever knowledge repository you use. Do not let the information get stale!
Software development teams need to continually measure the results of their processes and improve wherever they can. The processes outlined within this article are not static. They need to be adjusted for your organization, measured and improved upon. Continually. It takes a real commitment to a holistic software design and development discipline.
Creative work environment
It is important to foster a creative and innovative environment. The team should always be open and encouraging to ideas and suggestions that improve processes, policies, and software. It is often helpful to have periodic idea storm sessions were everyone is comfortable making suggestions. It is often helpful to capture all suggestions, and not discuss the merits at an idea storm session. This will encourage folks to speak up without fear of having defend the idea. This can be a fine line. It is very helpful to discuss the actual idea, as others often speak up and help refine the idea, thereby making it better. However, all participants should refrain from judging any ideas.
As you can see, each aspect of the development process takes into account external functional groups. The processes defined above thus lead to quick iterations and confidence within external groups. This in the end is critical to the success of software. Quality Assurance, Release Management, Project Management, Operations, Executive Management and in the end the customer, all benefit from solid development processes. They appreciate the attention your team paid to quality, performance, release and operational issues. They are as busy as you are, so don’t waste their time!