Kelly French wrote yesterday about Why Extreme Programming Fails. He made an interesting observation that caught my eye about human nature. He drew a correlation between why Continuous Integration is scoffed at and law #11 from The 48 Laws of Power.
I believe in Continuous Deployment as Timothy Fitz writes about and IMVU, Flickr and others practice. I am itching to implement the bits necessary to flush out defects early and prevent major problems later at work. I guess the “Laws” keep getting in the way, though. I wanted to believe people just needed some time to understand the concept and might slowly come around. After reading the “Laws”, however, they may just be trying to hold on to power.
I guess I need to change my tact. Now… how to do that?
2 Comments
When Machiavelli wrote “The Prince”, which described how power was obtained and kept in very stark terms, the rulers of his time felt that the plain-spoken explanation was too dangerous and banned the book in fear of usurpers. With “The Prince” and “The 48 Laws of Power” the first step is knowing what you’re up against. We should take to heart these tools not to wield them but to know how to protect ourselves from them.
Interesting referenced material…
Regarding the CD one…this (specifically deploying to *production*) is probably an okay (not good) practice for applications that aren’t of any consequence, are in beta, etc… but not for revenue generating, value producing software. Alex, in his case, would’ve cost many companies several hundreds of thousands of dollars (if not more) and an incalcuable cost in good will. Deploying to internal environments for review is one thing, but any system of value should be reasonably vetted before making it into a public facing scenario.
Further…the notion that automated testing would not have picked up the issue is debatable. There’s an abundance of available tools that will assist in determining what your tests have covered which should be a part of the development process to begin with. Heck, even manual testing in an Agile environment generally scales quite without the need for testing resources 5x the size of their development resources, as one comment states. Alex needs to revisit her “definition of done” and write better / more complete tests which is a very scalable solution. The author might be wise to revisit the cost curves of how much more expensive it is to resolve a defect that was found in a production environment than during the development cycle.
To your original desire…Agile methods are a great way to flush out defects early and often due to the nature of the process through continuous feedback and well constructed definitions of done.
As far as changing your tact…no clue on that one
Depends on the people of course, but simply aim for their value center. Use those “laws” to your advantage in order to make them look better and *suggest* it to them from that angle.