Show me your software development process...
In germany we have a saying "show me your friends and I tell you who you are". Actually there are a lot of variations of this like "tell me what you eat and I ...". I will add my own here: Show me your software development process and I tell you who you are. I think it is quite amusing and helpfull to review a software development process from this point of view:
Eg. take a look at RUP: RUP is an artefact driven process. It tells you which artefacts you have to create, when and which role has to create the artefact. It doesn't tell you HOW to do it. So this sounds a lot like a management view to me. A manager has to tell you what you have to do but shouldn't tell you how to do it (delegation works best when you as a manager let the expert decide how to do his job).
Or another hint: take your favourit RUP book from your bookshelf and take the number of pages of the book. Then go to the table of contents and count the number of pages that deal with the pure coding aspect of a project. Got the point? I know coding is not the only part of a project, there are so many others (may be even more important aspects), but after all coding IS one of the main activities...
Now go to the other eXtreme and take a look at eXtreme programming. XP is so development centered hardly anyone but a developer can create a process like this. XP almost tells a developer almost on a minute exact basis when to do what (eg. when to switch pairs or when to see the green bar). On the other hand it does not deal to much eg. how the manuals for a software will be created, how to do a consitent and good looking UI design etc.. Not that it is impossible to do it, it's just "not documented".
So why do I think this is not only funny but important: if you have to implement a software development process, watch out for "missing parts or views". Of course no methodology will work out of the box because every project is different so you have to customize your process anyway. But this point of view might give you some important hints where you have customize first, or which group in your team will most probably like or dislike the new process.
Sometimes if you want to introduce a more exotic process this can give you a hint if the process has ever left the ivory tower and was used in real projects. Acutally only a view processes (in their documented form) will survive this check. Eg. feature driven development is a rather "complete and balanced" one.
Does this mean incomplete processes are bad. For sure not! Especially the very unbalanced XP is one of the greatest steps forward in software development methodolgies in the last years and has brought us loads of great stuff. But it has it's sweet spot (and by the way, one great point about XP is that it's sweet spot is documented and it is not meant to be one size fits all, like most methodolgies in the 80ties). So use this just as a little tool when you have to work with software development methodologies...
Alex
Eg. take a look at RUP: RUP is an artefact driven process. It tells you which artefacts you have to create, when and which role has to create the artefact. It doesn't tell you HOW to do it. So this sounds a lot like a management view to me. A manager has to tell you what you have to do but shouldn't tell you how to do it (delegation works best when you as a manager let the expert decide how to do his job).
Or another hint: take your favourit RUP book from your bookshelf and take the number of pages of the book. Then go to the table of contents and count the number of pages that deal with the pure coding aspect of a project. Got the point? I know coding is not the only part of a project, there are so many others (may be even more important aspects), but after all coding IS one of the main activities...
Now go to the other eXtreme and take a look at eXtreme programming. XP is so development centered hardly anyone but a developer can create a process like this. XP almost tells a developer almost on a minute exact basis when to do what (eg. when to switch pairs or when to see the green bar). On the other hand it does not deal to much eg. how the manuals for a software will be created, how to do a consitent and good looking UI design etc.. Not that it is impossible to do it, it's just "not documented".
So why do I think this is not only funny but important: if you have to implement a software development process, watch out for "missing parts or views". Of course no methodology will work out of the box because every project is different so you have to customize your process anyway. But this point of view might give you some important hints where you have customize first, or which group in your team will most probably like or dislike the new process.
Sometimes if you want to introduce a more exotic process this can give you a hint if the process has ever left the ivory tower and was used in real projects. Acutally only a view processes (in their documented form) will survive this check. Eg. feature driven development is a rather "complete and balanced" one.
Does this mean incomplete processes are bad. For sure not! Especially the very unbalanced XP is one of the greatest steps forward in software development methodolgies in the last years and has brought us loads of great stuff. But it has it's sweet spot (and by the way, one great point about XP is that it's sweet spot is documented and it is not meant to be one size fits all, like most methodolgies in the 80ties). So use this just as a little tool when you have to work with software development methodologies...
Alex
posted by Alex at 9:22 AM
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home