Personal Software Process
Our reality is that there is no direct answer to the software development problem. I'm beyond believing that any company, programming language, technique, process, etc. is the final answer. I'm now of the opinion that you need to attack each software project with an open mind, a lot of courage and enough skill to get you by. With this in mind, I have developed my own "software process" (for lack of a better term) that I've been using for a few years now to develop my software. This page summarizes what that process is and how it's coming along.
Part 1: The Personal Software Process (PSP)
The personal software process (PSP) is a self-improvement process designed to help you control, manage, and improve the way you work. It is a structured framework of forms, guidelines, and procedures for developing software. Properly used, the PSP provides the historical data you need to better make and meet commitments and it makes the routine elements of your job more predictable and more efficient.
The PSP is not a magic answer to all your software engineering problems. Although it can suggest where and how you can improve, you must make the improvements yourself.
Excerpts from A Discipline for Software Engineering by Watts S. Humphrey.
I first tried using the PSP exactly as it was written in the book. Over time, I've evolved the process using empirical measurements to guide me. For example, if I think my compiler is too slow I measure how long it takes to compile and then compare to where I spend the rest of my time. I measured and compiling takes about 6% of my time. Hardly a good argument for upgrading my compiler now is it?
Part 2: Extreme Programming (XP)
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software. It is distinguished from other methodologies by:
- Its early, concrete, and continuing feedback from short cycles.
- Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
- Its reliance on automated tests written by programmers and customers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
- Its reliance on oral communication, tests, and source code to communicate system structure and intent.
- Its reliance on an evolutionary design process that lasts as long as the system lasts.
- Its reliance on the close collaboration of programmers with ordinary skills.
- Its reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.
Excerpt from Extreme Programming Explained: Embrace Change by Kent Beck.
I added in XP after I had a fully functional PSP going strong for a couple of years. Why? Because the PSP did not come through for me in all its implied promises. I wasn't seeing progressively fewer defects. I wasn't seeing larger projects that were easier to maintain. And I wasn't enjoying collecting and analyzing all those metrics. XP and PSP didn't meld easily. In the end, I now use the PSP's metrics basis to measure my progress and XP to develop the software.
Part 3: Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Excerpt from the Manifesto for Agile Software Development by the Agile Alliance organization.
As anyone who has actually tried XP will tell you, despite its appearances, XP is an extremely disciplined way to develop software. So disciplined in fact that one should not be claiming to be using XP unless one is following it very closely. No picking and choosing allowed because each practice is dependent on the existence of all the other practices.
Then came the Agile Alliance and a host of so-called "Agile" methods. The quote above pretty much explains what agile methods are all about and why. What I was practicing was some kind of agile methodology of my own invention. My methodology started with PSP, added in elements of XP and finally ended up being what it is today. It still isn't perfect, but no agile methodology should be. Agile methods acknowledge, celebrate and embrace the fact that people build software and people are definitely not perfect.