Process, Philosophy or Religion
As I have admitted before, I work in software development. That means that I attempt to create useful1 software for people.
Starting from the requirements2, I:
Umm, no. You can't tell clients that, can you? let's try that again:
That's better. Now I have a process. I'm still doing the same things, but now I have fancy names. And when a client asks me how I develop software, I can answer that I use a RUP-derived Agile methodolgy. And I'm still doing things the same. The same way I did them when the correct answer to the above question was Waterfall. Many people misunderstand Waterfall; as a development process, it never worked. In fact, almost no one except the military tried to follow it literally (who notched up some really impressive catastrophes as a result). Waterfall is a tool used by project managers to document and report the project upwards. Managers understand Waterfall. Waterfall assumes omnicience; mere mortals need not even try that route.
So what does a poor developer do? Pick a process? Draw a line between Waterfall and XP, close your eyes and jab a pin to make your selection? Or perhaps the other way around? Find a style and methodology that works for you; pin fancy names on it. Here is the divide. Should you choose a Process or a Philosophy (or a Religion)?
A Process is useful if you need guidance. It is also useful as the basis for a contract between the developer and the client. If you tell your client that you will be following the Unified Process (or, more concretely, RUP), you are defining a set concepts; artifacts, activities, roles, responsibilities and so on. These form a common vocabulary (with the oft forgotten proviso that everyone needs to share the same understanding of the terms) for the project. Customize to the needs of the project and you have your methodology. Alas, this is no silver bullet. You still need to know what you're doing. Apply a process (any process) without understanding and you are on the road to disaster.
A Philosophy is the distilled result of experience. It trancends process; it is flexible; it adapts to your current needs, yet allows you to do things the same way as before. It may guide you, for example, to test early and test often (now called TDD – Test Driven Development). You can do that in virtually any process; whether your process specifies unit testing or no. Philosophy may guide you to maintain your code in a constantly buildable state. With a little ingenuity, you can fit Continuous Integration into most projects. Code ownership, or rather the lack of ownership may be a bit trickier if your team includes developers who are territorial, but that's a reminder that a team that is divided in Philosophy is not an effective team.
Religion is a Philosophy that has hardened through dogma. William Caputo baldly proclaims XP as a Religion (though he softens that statement down in his explanation). I guess that's why it's called eXtreme Programming. He elsewhere makes the good point that it is ultimately people who make a project succeed, not the process. For my own responsibility, I will add that successful teams generally share a common Philosophy; that is the secret sauce that binds them together. It promotes the trust and openess that is at the heart of the agile process. And that brings us to this simple paraphrase of (I believe) Kung Fu-tze (aka Confucius)3.
Category: Software
Note 1: Useful means both functional and useable (pointed out by Don Norman in his POET book, as I remember)
Note 2:Requirements gathering is another prickly area that I am saving for another occasion.
Note 3:With so many quotations attributed to him, I may just be mistaken. I can't find a reference to the original.
Starting from the requirements2, I:
- think until it hurts
- scratch out a bare-bones solution (back of envelope style))
- hack it until it works
Umm, no. You can't tell clients that, can you? let's try that again:
- Perform Analysis on the requirements
- Develop the Analysis model into an implementation specific Design
- Construct, Test and Improve the code (and design (and analysis))) iteratively
That's better. Now I have a process. I'm still doing the same things, but now I have fancy names. And when a client asks me how I develop software, I can answer that I use a RUP-derived Agile methodolgy. And I'm still doing things the same. The same way I did them when the correct answer to the above question was Waterfall. Many people misunderstand Waterfall; as a development process, it never worked. In fact, almost no one except the military tried to follow it literally (who notched up some really impressive catastrophes as a result). Waterfall is a tool used by project managers to document and report the project upwards. Managers understand Waterfall. Waterfall assumes omnicience; mere mortals need not even try that route.
So what does a poor developer do? Pick a process? Draw a line between Waterfall and XP, close your eyes and jab a pin to make your selection? Or perhaps the other way around? Find a style and methodology that works for you; pin fancy names on it. Here is the divide. Should you choose a Process or a Philosophy (or a Religion)?
A Process is useful if you need guidance. It is also useful as the basis for a contract between the developer and the client. If you tell your client that you will be following the Unified Process (or, more concretely, RUP), you are defining a set concepts; artifacts, activities, roles, responsibilities and so on. These form a common vocabulary (with the oft forgotten proviso that everyone needs to share the same understanding of the terms) for the project. Customize to the needs of the project and you have your methodology. Alas, this is no silver bullet. You still need to know what you're doing. Apply a process (any process) without understanding and you are on the road to disaster.
A Philosophy is the distilled result of experience. It trancends process; it is flexible; it adapts to your current needs, yet allows you to do things the same way as before. It may guide you, for example, to test early and test often (now called TDD – Test Driven Development). You can do that in virtually any process; whether your process specifies unit testing or no. Philosophy may guide you to maintain your code in a constantly buildable state. With a little ingenuity, you can fit Continuous Integration into most projects. Code ownership, or rather the lack of ownership may be a bit trickier if your team includes developers who are territorial, but that's a reminder that a team that is divided in Philosophy is not an effective team.
Religion is a Philosophy that has hardened through dogma. William Caputo baldly proclaims XP as a Religion (though he softens that statement down in his explanation). I guess that's why it's called eXtreme Programming. He elsewhere makes the good point that it is ultimately people who make a project succeed, not the process. For my own responsibility, I will add that successful teams generally share a common Philosophy; that is the secret sauce that binds them together. It promotes the trust and openess that is at the heart of the agile process. And that brings us to this simple paraphrase of (I believe) Kung Fu-tze (aka Confucius)3.
When the right man uses the wrong process, the wrong process works in the right way
When the wrong man uses the right process, the right process works in the wrong way
Category: Software
Note 1: Useful means both functional and useable (pointed out by Don Norman in his POET book, as I remember)
Note 2:Requirements gathering is another prickly area that I am saving for another occasion.
Note 3:With so many quotations attributed to him, I may just be mistaken. I can't find a reference to the original.
posted by John at 1:54 PM
0 Comments:
Post a Comment
<< Home