Brian Marick made a bold statement in his presentation on last night's Naked Agilists Skype conference. The podcast will be available soon but, put simply, his point was this.
With reference to Moore's technology adoption life cycle, Agile methodologies have crossed the chasm between visionaries and pragmatists only to find that, in his opinion, there are not many true pragmatists out there and the only option is to skip straight to the conservatives. He feels that the original visionaries are now spread very thinly across the world consulting with Conservative companies and the development of Agile would be better served if they were to retreat back to Visionary companies and work together on real projects creating new innovations.
Well done to Brian for sticking his neck out and making such a bold statement. As one of the original signatories on the Agile Manifesto and a consistent contributor and leader in the community, he is well qualified to comment on how Agile is being applied across the industry. Clearly, he has seen some things that have disturbed him greatly and has been moved to comment this strongly.
He is also the first to admit (listen to the podcast) that he would love to discuss this much further so I would like to offer an opinion on a factor he might not have considered...
The Agile community is too heavily skewed towards Object Oriented languages and people believe it only works with Object Oriented languages.
Back in the day, the patterns community, who were the thought leaders in the objects community, met up with the leaders in the methodology community and created what we now know as Agile (OK, so I skipped a few steps along the way, but please run with it). Naturally, the technical practices on OO projects continued to evolve and the people involved wrote the definitive works on refactoring, TDD and Agile design.
Let's be absolutely clear on something. I don't want to, even slightly, cast any doubt on the excellence and relevance of these books and I am certainly not trying to belittle the efforts or success of the people who wrote or have read them. But there is a problem. No one is writing technical books about anything other then OO technologies.
So why is this important?
Because Big Companies Are Conservative
The converse is not true (there are small conservative companies too), but in order for Agile to become truly mainstream it needs to establish itself in IT departments at multinationals like telcos, banks, media companies, major retailers and energy suppliers (the list is endless!)
Big companies like these employ legions of programmers, designers, architects, testers, managers and support staff who don't know about objects, don't do UML and think Ruby is a sort of red diamond. It's not a problem though. They don't need to know about objects because they have built their careers with languages and environments like Ab Initio, COBOL, Siebel, SAP, SAS, PeopleSoft, Business Objects, Brio and Teradata to name but a very few.
These technologies are the heart and lungs of the company and the latest J2EE or Rails website would be pretty useless without them quietly churning away in the background supporting the business's ability to deliver. Of course, we know that nothing really churns away quietly, so we need people to look after them and projects to update them and add new functions when the business environment changes - just like anything else.
It's not glamorous or sexy, but it's still very challenging and often cutting-edge work which is subject to exactly the same project pressures as the latest marketing initiative.
Unfortunately, when the IT director at a multinational looks at Agile, his or her first reaction is not that of one of Moore's Visionaries who would wonder "will this help me achieve 10X productivity gains". It's more likely to be "how does this affect my ability to keep the lights on". And that's the right place to focus - failure to do so would be reckless, career ending and maybe even illegal (governments tend to take a dim view of telecoms operators that cannot reliably provide, for example, 999 emergency services).
So what can we do?
Scrum, Crystal and DSDM have shown us how to work iteratively, Lean has taught managers how to think about software development, but a team cannot be truly Agile without the Extreme Programming technical practices that allow it to truly embrace change. It is essential that we can provide documented proof and guidance on how to apply the technical practices across a wide range of modern and legacy technologies rather than just the new era of OO toys.
The adoption pattern is there to see from the OO world. We need expert visionaries from untried technical domains to stand forward, say "YES! This is possible using Product X", and then go and make it happen. We need blogs, articles, conference presentations, training courses and, ultimately, books to guide Agile virgins through the technical practices using a range of technologies. We need to show business software vendors that they can differentiate themselves by supporting their clients Agile development needs.
That's what I am doing, but I can only work with what I know so I will end with a rallying call to the next generation of visionaries:
If you are breaking ground in non OO environments - especially business software - please write about it! There has never been a better time to make a real difference and maybe a name for yourself too.
12 comments:
We do a lot of work in C because we have to. Lots of conservative and progressive sectors must work a lot in C (after all Ruby is a C program!) Anyway, we've done a some things to make C apps testable and there are lots of others out there doing the same. I would be interested to see if the agile community would be interested in discussing applying agile to C?
Hi Tom. Great example, I am sure there will be a lot of people in the community who are interested in your work. The extremeprogramming list at Yahoo groups is very friendly and I think you'll get a good response if you post a question or experience report there. From my own knowledge, I know there have been some Agile projects in C - the embedded work papers at http://www.agilerules.com/index.phtml are C based - but I don't know how much else is out there.
Sounds like a good research project. Is there a correlation between programming language age and software development methodology age?
If you don't have access to survey data (like perhaps data from software development user groups) you could grab language and development methodology data from job listings.
I don't consider C++ to be object-oriented (there's too much visibility of the memory model and other yucky stuff); but I've been working in C++ a lot lately, and doing a reasonable job of TDD, continuous integration, etc. I think the downside of such languages is related to throughput and the cost of change -- C++ development is measurably slower than, say, Java development (4 times slower, I recall). So the cost of refactoring, requirements churn etc is much higher -- and that can tend to push the pendulum back towards BDUF.
That said, I'll be happy to discuss my agile work with C++ with anyone who wants to contact me.
I think it is important to recognize that the reason why agile hasn't penetrated further into non-OO (read "procedual") languages are technical, they are not just a matter of preference.
It is possible to use C in a very testable way, but many other procedural languages (particularly vendor languages) lack seams that make testing as easy as it would be in OO languages.
When I wrote the post, I was thinking about the 4th generation languages, tools and environments that borrow from OO, procedural and functional paradigms but don't sit comfortably in any one of them. It's really interesting to find that there are people in the procedural/C++ space with whom my talk resonated. Certainly C++ seems much less well supported that I had thought. I am not sure what to do about it though beyond banging the drum like I have been. Does anyone have any ideas?
I work on the IBM iSeries and am trying to push Agile within our company. There is little movement on the SCRUM Project front, but the data hiding/descriptive names/TDD/Unit tests of XP & OOP may have landed in fertile soil.
"but many other procedural languages (particularly vendor languages) lack seams that make testing as easy as it would be in OO languages."
This is where as a conservative RPG pgmr, I am pushing a methodology for a standardized Unit Test for code in our shop.
The last meeting of AgilePhilly had us bashing /or/ praising code comments, since procedural and black-box interfaces require them, and descriptive names & functions with data hiding in the latest RPG is where Agile ideas affect us.
I've done work to apply agile practices for embedded software written in C. I co-authored a test framework for that. It is at http://www.agilerules.com/projects/catsrunner/index.phtml
It is harder to apply agile practices in non-OO languages but it is possible. Object Orientation is a design approach, and can be applied even where it is not explicitly supported.
Adrian, as you know I'm a believer that agile needs to go into those more traditional, procedural languages. There is a lot of innovation still to be done. I hope people reading this will give thought to that.
Hi Adrien,
I found this post via David Peterson's link to you. A question about your "Beyond Objects" post: Do you think the lack of "agile" practices in the non-oo environments you described is because of a lack of programming tools that lend themselves to agile practices?
Thanks and nice to meet you.
Niraj.
Hi Nik,
It's nice to meet you too.
I find you comment interesting because I believe Agile principles and practices can be applied to any programming language/tool/environment. Certainly, the path is well trodden and documented for OO languages and it can often be easier in an OO language, but there is nothing in principles of TDD, continuous integration, refactoring etc that are specific to OO.
It has been my experience when doing data management development that we can do all these things - we just need to focus on the principles of what we are trying to achieve and allow practices to evolve accordingly.
Hope this helps
Adrian
Just spotted this http://martinfowler.com/books.html#refactoringHtml
I guess you can't get further from OO than HTML, yet someone has figured out a set of refactorings.
The problem is not so much the language these apps are written in as it is the fact that they are legacy systems. There is a lot of code written without unit tests and a lot of duplication. It is hard to retrofit agile practices into a project with a lot of existing code.
Post a Comment