Cool Code
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Abel Avram on Dec 30, 2008
In this interview made by InfoQ’s Amr Elssamadisy during Agile 2008, Keith Braithwaite, an Agile developer, consultant and trainer, says that we should show a good deal of skepticism towards today’s Agile practice.
Watch: Keith Braithwaite, an Agile Skeptic (32 min.)
Keith confesses he is an Agile skeptic, not because Agile is wrong in its essence but because Agile is perceived and practiced in ways that distort its base principles. Many failures occur and they shed a negative light over the entire Agile movement because too many times one thinks that buying an Agile book or tool is enough to ensure project success.
Keith suggests students in Agile should be rigorously tested and a certain level of experience should be imposed in order to graduate someone as Agile coach.
Five Key Practices to Agile ALM
Case Study: IBM's Agile Transformation
SCM best practices for multiple processes, releases & distributed teams
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
"knots and bolts" => "nuts and bolts"
I wonder if selling agile is the real smell Keith is describing. In order to effectively sell a particular agile methodology you must package (catalog) best practices in such a way that easily identifies what you are selling, resulting in the symptom that Keith describes:There is an answer and your desire to do things differently from that is an indication that either you haven't understood, or you've not appreciated something else and your organization is broken and that makes you want to do things differently, or something of that nature. There is a kind of excessive strength or force in the way these things are performed. You can almost understand why an author would do that.
I'm wondering why Keith alludes to but doesn't name the primary culprits he is talking about when he is making claims: Unfortunately, some of these catalogs of Best Practices, say things like "If you feel you want some Monkey Bag with our set of Best Practices, that's an indication that there is something wrong you." More specifically, if you want to change them, then you've made a mistake, which I think is quite a dangerous principle to have floating over your head.
Some? How many are there? Which are the worst offenders? While Keith does a good job giving you some specific examples of when extra skepticism can save time and money, perhaps people should be skeptical of boxed agile best practices that carry price tags in general? I wonder if money is the motivation that causes people to be more defensive of the agile boxes they create?
Hi Cobbie. I didn't, and don't think that it would be terribly helpful to go around "naming names" on this. However, the danger sign is pretty well defined and that's the thing to beware of.
By the way, your transcript isn't quite right (the fault of my accent, I'm sure) What I said was:Unfortunately, some of these catalogs of Best Practices, say things like "If you feel you want to monkey about with our set of Best Practices, that's an indication that there is something wrong with you." More specifically, if you want to change them, then you've made a mistake, which I think is quite a dangerous principle to have floating around in your head.
Price tags aren't bad in themselves. I sell services aimed at improving the ability of an organisation to add value through building information systems. The Agile toolkit has a lot of great ideas to offer there and I use a lot of those ideas. And a lot of great ideas from elsewhere.
I think that it's the box that causes the problem. I've gigs where a client has previously had one or another vendor of a particular, specific Agile solution come in and do their thing. The end result has been a diminution of the client's ability, which I (or someone else) then has to fix. That's bad.
Well said Keith. Should be required wiewing for anyone considering Agile as an approach.
I have this hypothesis: Agile brands that have a well defined commercial marketing strategy are going to be defended more than brands that don't. When it comes to agile, defending the commercial interests of a brand (components, identity, and language) is counter productive because it leads to unacceptable levels of rigidity.
As you point out it is very ironic when any agile approach has rigidity that does not allow you to refactor the approach itself. All agile brands have rigidity: there is a point at which, having altered or abandoned enough of its components, where XP is no longer XP. Hence if someone says: we are going to do XP, there is a tendency to limit the degree to which you adapt XP to fit your needs.
However, when you overlay a strong marketing and commercial structure on top of an agile methodology you increase the inherent rigidity of an agile brand still further, thus increasing the pressure to confine your approach to those practices directly promoted by the brand you are purchasing. For example, if as a CIO I pay money to have someone become Scrum certified I'm going to expect them to implement Scrum, and not something that doesn't resemble Scrum as it was sold to me.
For this reason maybe agile best practices should not be defined (packaged, cataloged) to the degree that they can be sold. You are right, the box is the problem, however, perhaps selling and marketing the box magnifies the problem to unacceptable levels?
With regard to specificity: I can understand your hesitance to name names, and this isn't the first time I've seen this issue mentioned (agilethinking.net).Scrum is a useful framework to get started down an Agile pathway, but if the framework becomes a rigid way of thinking it destroys its own purpose.
I think there is a way to talk about this with greater specificity that goes beyond name calling, and works to guide people when adopting agile. For example, the quote above names the methodology and puts the criticism in the context of what the methodology does well.
Fixed. Thanks for noticing.
seems as if Certified Best Practices have been proposed since antiquity and have been knocked down since antiquity.
uncritically applying behavior from one context to another is not good. adopting a permanent, certified "Context-driven" stance is also not good.
Here, a message from Library Science:
There is no single set of preferred or "best" practices that one should follow in collecting free Web resources. What succeeds in one context might prove fruitless in another. The practices recommended in this report have proved effective in a specific project or show promise for broad applicability, regardless of the fiscal, technical, or human resource parameters in any specific institutional setting. Ultimately, it is not the practice per se, but rather how well that practice lends itself to a particular set of goals, workflows, and staffing preferences, that determines its effectiveness and value in any given setting.
www.clir.org/pubs/reports/pub98/bodya.html#intr...
Shouldn't we in software development know this already?
I'd like to see the rest, 9minutes is not enough :)
I'd like to see the rest, 9minutes is not enough :)
Hi Niall, have you tried clicking some of the questions in the transcript? They forward me into the interview far further than 9 minutes. I'm not experiencing the 'clipping' you mentioned.
Floyd
nice one Floyd I didn't even notice the questions in the transcript, thanks.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
10 comments
Watch Thread Reply