Many times, we have heard the word "process" and cringed.
To a lot of us, process is simply the techie garb for red-tape. For instance, wouldn't you as a developer love to hunker down at your terminal and tap out great code? But that is not all you are expected to do. First, you must read a voluminous requirements document - depending on your organization's way of working, there may be more than one such document. Business requirements, functional specifications, UX documents, performance and security guidelines, build documents, deployment guidance, and so forth. You also need to add documentation of your own - the technical specification, data flow diagrams, various other flowcharts, class diagrams, database diagrams, unit testing guides and more. And that was just documents. Organizations also follow quality control mechanisms like code reviews, inspections, automated unit and functional testing, which are all your responsibility.
Some members on your team are also have tasks like creating granular project tasks, tracking them on a daily/weekly basis, creating so many different types of reports, performing triage and deciding what to do about problems both proactively and reactively. The execution model chosen for the project varies these tasks by degrees - for instance, if you have a regular waterfall model, perhaps you have the easiest set of management tasks. But, if you were executing against a Scrum model, the tasks and the complexity of those tasks go up a notch. A TSP project raises the bar even further.
Processes to excellence
Not all processes lead to excellence. Even those that should, do not, unless you follow them for the right reasons, in the right spirit and with the right follow up actions. For instance:
Hang on a minute, we said the right "follow up actions". What do we mean by that? Put simply, once the exercise of a comment gathering from a review or inspection is done with, do we perform any follow up exercise at a later point of time to check whether the comments recieved was actioned on, and if not why that was not done? More on how to get this done a little later.
Reviews or Inspections?
Reviews are a matter of internal affairs - i.e., it is done within a project team. Simply put, you review each others' code in a team. For inspections, you call in experts from outside the team. This is so that you can get a impartial and outside perspective on your design and implementation. Both reviews and inspections provide the best returns when they are used prior to the next stage of the development cycle. Reviews must be done prior to creating a droppable build, and inspections prior to handing over your bits to the Test team.
At many organizations, the process of reviews or inspections use mechanisms disconnected from central tracking systems to record the comments, suggestions and problems found. What do I mean by this? If you send in your review or inspection comments via email, in Excel spreadsheets or Word documents, you are using a mechanism disconnected from whatever means you are using to track the metrics of your project. Because these metrics are disconnected, there would be no way to affix responsibility back to the team to fix the problems or to track if anyone is doing anything about it (and if they didnt, why?).
The way out is to put them into the centralized tracking system you have. At Microsoft, obviously, we do this through VSTF (Visual Studio Team Foundation, our source control and bug tracking system). The reports received post a review or inspection for any artifact is filed as a bug in the VSTF project related to that artifact. However, that is not the only mechanism you can use. For instance, if you have a content management system (like Office SharePoint Server or Windows SharePoint Services), you can take advantage of its "Issue" lists to do similar things. Infact, both MOSS and WSS provide out of the box change notification mechanisms through e-mail for such lists. After that, it can be tracked just like any other bug.
Quality Gates
Now that every problem, issue and suggestion towards artifacts of your project is tracked as a bug, your team can enforce quality gates for your project. The following gatekeepers of your project's quality can help determine when and where the bugs were injected into the application:
The robustness of your build, delivery and release process also matters in the ensurance of engineering excellence. A related measure is "Defect Leakage". Defect leakage is nothing but the number of bugs for a given feature set that has been introduced (found) at a later stage. For instance, you made a screen that had a defect that you did not manage to catch and fix during your developer unit and functional testing. The testers didnt find it in their integration testing phase, but it popped up all the way out in user acceptance testing. That is a defect leakage of a high order as it "leaked" all the way to the user. The general guidance is that if the number of bugs at the entry/exit from one phase to another of the project cycle is consistently going down, then your team is doing a good job.
However, there may be other factors that influence this. For instance, what is the code reuse percentage in your project between each release? How is the lines of code of the project changing (inserts versus updates/deletes) ? What kind of bugs are being found as time goes on - do they become more severe/critical or less? Was there new knowledge or requirements that came in late that are causing the bugs?
Build consistency
It would be dangerous to create build that you would like others to install and make use of from the same systems that you use to write the code. Reasons are many:
Therefore it is a recommended process to check in all of your code (after your local unit testing and peer-review), pull down the latest sources into a centralized "build box" - you do not use this box for any coding activity and has just enough resources installed to ensure the solutions compile properly - created for the purpose and build it from there. VSTF provides the ability to configure remote build agents that you can run on any PC on your network. Simply install the version of .NET your application uses, and the rest of the libraries you need to build your projects, install and configure the VSTF agent both on the build box and in your VSTF Team Project. These jobs can run on-demand or on a schedule or can be triggered on an event (like a checkin).
Yet another level of abstraction is to have a centrally hosted and administered build system that any one can go onto and request for builds. This lets us introduce build and post-build processes in a centralized fashion.
For instance, when our group decided to onboard 40 legacy applications onto a Continuous Integration (where compile to BVT happens in an automated fashion) effort, it was far easier to just ensure that these applications had valid unit test solutions checked into their project trees and perform a one-time configuration in our central build system to take care of the rest. This also helps in disaster recovery where (say) the production systems crash and you need to create working builds out of sources quickly.
Delivery mechanisms
You do not want to learn the hard way that it is best left to automated systems to perform release and delivery activities so that every time an application goes through a delivery interation, the exact same sequence of events are followed, with the same results (system problems and silly mistakes apart). Consider the elaborate dance of systems that cause a bit of code that you write to land up a hundred miles away on your user's desktop (in binary form, of course).
Code -> Build System -> Developer testing box -> Release location -> Alpha/Beta testing box -> Release candidate environment -> End-user testing environment -> Production systems
If the process of transfering a build from one system to another was left to humans, there could be inadvertent mistakes - you copy the wrong builds, miss out some vital updates, forget to update the drop scripts to take care of any changes, ... or any number of other things. This in itself can cause problems in the delivery and release phases of your project.
In conclusion
Along with strong engineering skills, one must also follow sound engineering practices and processes to ensure excellence and quality. The definition of what constitutes "quality" depends on various factors: who the end users are, what the business priorities are, how easily can you fix existing bugs post release to the customer, and others. However, following the right practices from the beginning can help ensure that towards the end, the number of "defects" in the system are minimized.