A manager at a software shop yells “I thought we fixed that!” Guts clinch all around. This is not a new scenario.
Back in the mid 90’s, I read an eye-opening book on software development by Watts Humphrey, A Discipline for Sofware Engineering. His revolutionary idea was that we should consciously review the way we develop software and see whether do it in a more methodical, controlled manner. He said that we should be aware of the process, and constantly subject it to critical evaluation.
Dr. Humphrey went on to elaborate the famous Capability Maturity Model (CMM), which categorizes software engineering practices and procedures in regard to how effectively they manage the development, delivery, and maintenance of software products. CMM has the concept of levels, with higher levels being better.
At the time, it seemed to me that many software shops were flirting with level zero, “non-repeatable results”, aka “chaotic”. Apparently other people felt the same, because dissemination of Dr. Humphrey’s work on CMM was followed by the heyday of ISO-9000 and strict demands for procedures, method, and documentation.
Chaos is a dubious business model, but enforcing methods and procedures can be a mixed bag. At its worse, too onerous a process will hamper development, perhaps with no benefits whatsoever. As a friend liked to say, you can define and document a repeatable process for sticking a pencil in your eye.
What seemed to be forgotten is that a software development process is a means to the goal of high quality products, delivered on time. If your processes don’t facilitate your work, they need to be fixed or replaced.
There are many approaches to developing and maintaining software products. But across all of them, your versioning, source control, and bug/feature tracking must allow you to do the following:
- Phone support for your product must be able to walk a customer through determining and reporting the version of your product that the customer has deployed.
- Maintenance programmers must be able to rebuild the exact version of your product that a customer is using.
- It must be easy to determine the product release in which a bug was fixed.
- It must be possible to view the changes that were made to the code in order to fix the bug.
- Changes made to the code must correspond to some description in the bug/feature tracking system.
You can do agile, you can do waterfall (assuming anyone still admits they do waterfall), but if you can’t handle the above, you are screwed.
Some related practices are:
- The scope of a commit or check-in should not span multiple bug fixes or features.
- Code formatting changes or pure refactoring should be committed separately from fixes and features. (It’s natural to clean up code when making a fix, but that should be done in moderation.)
I don’t mean to disillusion anyone, but there is no silver bullet. Perhaps the best we can do is to keep from shooting ourselves in the foot. Your product may be good, it may be bad, it may be successful, it may be ignored. But if you don’t have a repeatable process, you got nothing.