Discussions in the office typically bring interesting conversation, and as I head to Agile2008 (I sit on the flight whilst writing this), I wanted to ask what's the difference between enterprise agile and start up agile, and how does that difference affect not just the maintainability of the products build, but also the innovation of the respective engineering group?
There is always the classic trade off between feature delivery and quality, but is it really the case that startups are generally exempt from these quality metrics? If this is the case, what other practices can be put in place instead of code metrics?
One of my memorably quotes from high school was my physics teacher, Mr Shave. He said to the class 'you can never prove anything, you can only disprove something'. This applies here with quality metrics. Code coverage, convention and duplication don't prove quality in code, even intergration testing or robustness and performance testing do not prove anything, they only dis-prove that your system doesn't fail under certain conditions. However, all of these steps do increase confidence in a product, and that is an integral part of any product development (confidence that is).
You can still not do any of this and be agile right? These practices are generally incoraged, but agile is about customer engagement and acceptance and if you're customer knows what they're getting and they accept your stories then it's OK right? What is enterprise agile anyway? Do enterprise developers build a product, deliver it into an in-life team and then move on? Does that require higher confidence as you're handing over? Is a start up developer likely to support that product in-life and as such be more likely to stick around, fix issues and add functionality?
2 comments:
Really reckon that the main difference between startup agile and the enterprise sort it that the enterprise encourages all sorts of metrics, sometimes over delivery. whereas a start up just says "when can i launch it"?
Both will change there mind during delivery cycles, and it's flexibility to me that is the key part of agility, as opposed to "god we can measure all this stuff"
code quality is a factor of code size, and the larger and more complex the code base, the higher the level of quality required. start up code starts small, and sometimes suffers from not increasing quality as the size of code base grows.
the way i use code metrics is to flag up issues when i am coding: as means of getting immediate feedback from the IDE to act and correct immediately. I don't think of code metrics as means to police code or measure ultimate quality. Pairing and code reviews are more appropriate in that respect.
as for enterprise and agile i found this blog - you may be interested http://scalingsoftwareagility.wordpress.com/2008/08/11/revised-big-picture-graphic-and-posts-1-4/
Post a Comment