When I was recruited to join a local company as a software developer, I was told that the group in which I would work was going to pursue level 2 or better of the Capability Maturity Model (CMM). That appealed to me because it represented a step forward in my own professional development. It was also an important part of dealing with the size and complexity of the software system.
It didn't happen.
Later I moved on to other projects, some with greater process maturity, some with even less. From my experiences with these projects and others earlier in my career, I learned several valuable lessons. They're listed here as simple maxims; I'll expand on them as time permits and the spirit moves me.
Write it down!
It's one thing to know you need documentation and peer review. It's another to know why. Without the latter, your application of the former will be useless.
Without a clear description of the software requirements, not only does the developer not know when he's completed his task; he also can't possibly know that he hasn't completed it.
Apply established standard formats for documentation rather than relying on ad hoc formats.
Disastrous results can occur in an electric circuit when electrons follow the path of least resistance. The same thing can happen to a software product when developers are told to do the same.
Following the path of least resistance eventually makes that path more resistant than the path of due diligence.
Aggressively pursue opportunities to improve the architecture of the system.
By forgoing peer reviews, your developers lose opportunities to learn from the successes, mistakes, and experiences of their colleagues. Consequently, your products aren't as robust, efficient, and maintainable as they could be. Read more.
If you want to make your electronic documents look like paper documents, throw them away and use paper. If you want to use electronic documents effectively, use the flexibility of the electronic medium to your advantage.
I haven't listed a maxim above on the importance of a documented coding standard, but I've begun to collect and respond to some of the retorts sometimes provided by "cowboy programmers" who don't think a coding standard is beneficial.
Chuck Taylor --