Wednesday, December 07, 2005
Thoughts on Software & Integration Architecture from the Trenches: Agile Development and Architecture - Yeah Right!
http://blogs.ittoolbox.com/eai/trenches/archives/006787.asp
I'm somewhat agree with the author as far as what are bad things that could happen when Agile practices are not done correctly. Like any other practices, RUP, XP, RAD, things could go wrong regardless of how well/matured the particular practice is.
"Speed" is not the main goal of Agile development practice, it's one of the many side effects that come from it, like many other efficiently run practices (RUP or RAD).
Agile practices support delivering what's most important to the users of the system/stakeholders(could be users, architects, project sponsor, etc.)
Things that Agile practices have done that resulted in faster time delivery:
1. Only implement what the requirement stated, with no added bell and whistles that deliver the least amount of value but it still take time to produce.
This doesn't necessary mean Agile practioners abandon common senses/good practices, b/c by doing that it will also cause negative effects in the future and thus cause major rework which essentially will impede the "speed".
2. Agile practice encourage constant refactoring
This doesn't mean that Agile practioners do things badly in the first place without thinking and fix it later, I hate to admit but bad people usually does this, but regardless of how good a practice is, bad people will always exists, we can't control that.
Refactoring is done to improve the code, readability, make it easier to maintain in the future, because software are flexible, in my experience , you can't possibly write a piece of software and get it right at the first cut. (even Beethoven couldn't do it, unless you're Mozart) As things changes, and development team learn new thing/technology, its to developer good conscience to apply his newly found knowledge to the codebase rather than leaving it the way it is.
3. Creating a good testable code with loosely coupled and high cohesion is also goals for every agile practioners
the way to achieve this is you're applying Test Driven Development in your coding practice, you'll write your test to improve your design, afterall each component that you create will be use by some other component, and it only make sense that your test component be the first one that use your component, because you'd rather find out that your design make sense earlier rather than later on once things are harder to control/fix.
this practice allows you to have faster feedback as far as how good your design really is, again "speed" is the result of other good practice not the ultimate goal of it.
The author mentioned as an example things about enforcing database constraint, these are a common sense, and should be part of other non functional requirements of system under development.
One should allocate/treat these non functional requirements the same way as the other business requirements, which I admit is a bit harder, since business stakeholders don't care (directly) about these non functional requirements, however, architects and other people in an organization are also stakeholders, and their needs should be fulfilled, and works should also be budgetted against that requirements.
Like other software practices, sometimes development team will miss estimate on these non-functional requirements, which are a shame, and should be corrected and included as part of work and budget when building a system.
But one thing for sure there should be tradeoff made on these non functional requirements also, the same as business requirements, because the last thing people want is to spend years on development handling these requirements trying to make the system perfect and missing the actual intention of creating the system in the first place.
I'm somewhat agree with the author as far as what are bad things that could happen when Agile practices are not done correctly. Like any other practices, RUP, XP, RAD, things could go wrong regardless of how well/matured the particular practice is.
"Speed" is not the main goal of Agile development practice, it's one of the many side effects that come from it, like many other efficiently run practices (RUP or RAD).
Agile practices support delivering what's most important to the users of the system/stakeholders(could be users, architects, project sponsor, etc.)
Things that Agile practices have done that resulted in faster time delivery:
1. Only implement what the requirement stated, with no added bell and whistles that deliver the least amount of value but it still take time to produce.
This doesn't necessary mean Agile practioners abandon common senses/good practices, b/c by doing that it will also cause negative effects in the future and thus cause major rework which essentially will impede the "speed".
2. Agile practice encourage constant refactoring
This doesn't mean that Agile practioners do things badly in the first place without thinking and fix it later, I hate to admit but bad people usually does this, but regardless of how good a practice is, bad people will always exists, we can't control that.
Refactoring is done to improve the code, readability, make it easier to maintain in the future, because software are flexible, in my experience , you can't possibly write a piece of software and get it right at the first cut. (even Beethoven couldn't do it, unless you're Mozart) As things changes, and development team learn new thing/technology, its to developer good conscience to apply his newly found knowledge to the codebase rather than leaving it the way it is.
3. Creating a good testable code with loosely coupled and high cohesion is also goals for every agile practioners
the way to achieve this is you're applying Test Driven Development in your coding practice, you'll write your test to improve your design, afterall each component that you create will be use by some other component, and it only make sense that your test component be the first one that use your component, because you'd rather find out that your design make sense earlier rather than later on once things are harder to control/fix.
this practice allows you to have faster feedback as far as how good your design really is, again "speed" is the result of other good practice not the ultimate goal of it.
The author mentioned as an example things about enforcing database constraint, these are a common sense, and should be part of other non functional requirements of system under development.
One should allocate/treat these non functional requirements the same way as the other business requirements, which I admit is a bit harder, since business stakeholders don't care (directly) about these non functional requirements, however, architects and other people in an organization are also stakeholders, and their needs should be fulfilled, and works should also be budgetted against that requirements.
Like other software practices, sometimes development team will miss estimate on these non-functional requirements, which are a shame, and should be corrected and included as part of work and budget when building a system.
But one thing for sure there should be tradeoff made on these non functional requirements also, the same as business requirements, because the last thing people want is to spend years on development handling these requirements trying to make the system perfect and missing the actual intention of creating the system in the first place.
