New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mike Bria on Jun 02, 2009
Registration is nearly full for next week's public courses from respected agile thought-leaders Jim Shore and Diana Larsen, and InfoQ got the opportunity to catch up with Jim as he prepares for them. In a casual interview, InfoQ got to talk with Jim about some of the topics he's been most vocal about lately, including his Art Of Agile book, recent waves of watered-down agile, and how Kanban might be less than the whole picture.
InfoQ first asked Jim about the Art of Agile book he and Shane Warden recently co-authored, particularly why the book matters and what readers can expect from it. Jim explained that many of the earlier comprehensive classics, such as those in the Extreme Programming series, target more of the "innovator and early adopter" audience (in Jeffrey Moore "crossing the chasm" terms), where as his book explicitly aims to be more pragmatic content for the many "early majority" types now looking for their introduction to agile. Jim went on to describe where the content comes from:
This book is really an amalgamation of my experiences with teams, which was based on me applying XP at first then bringing in pieces of Scrum because a lot of the teams I work with start with Scrum, and then also bringing in Lean concepts. All of this levied with a dash of Eli Goldratt's Theory Of Constraints model, which is very Lean-like. A final piece we brought in was Brian Marick's Agile Testing Directions.
More information about Jim's take on the book can be viewed in this interview filmed at Agile 2007 conference.
InfoQ talked then with Jim about his perception that agile adoptions are growing increasingly watered-down, as his well-known Stumbling Through Mediocrity and Decline and Fall Of Agile articles document. Summarizing his observation, he said this:
People are saying, 'we want to be agile', then finding the easiest, cheapest way to "be agile", and as a result are not making their lives any better. In many cases, in fact, they are making their lives worse.
...
What I see out there is that as agile has become a buzzword, and now agile itself has become the goal. But if agile is the goal, you can do all kinds of dysfunctional things, slap the word "agile" on what you're doing and declare success, but without actually ever making anybody's lives any better. The goal of agile isn't to "be agile", the goal is to produce great software that has value and that is fit for purpose in a way that is responsive, flexible, and humane.
When asked about what he thought the agile community can do to improve the situation, Jim offered this:
We need to stop saying agile is easy. We need to say agile is effective, its powerful, and that agile is going to deliver value - but its not necessarily easy. In fact, its hard. [Agile is an organizational change, and any] organizational change is hard.
As the conversation about the growing trend to take on agile methodology without really taking the whole methodology on continued, the topic of Kanban arose. Jim explained that he thinks Kanban is a great tool, but worries that focusing too much on Kanban in and of itself might be missing the bigger picture intended by Lean:
I think Kanban is a really interesting idea, and an excellent tool...but, the Lean Software Development ideas brought from the Toyota Production System over to the agile world [initially by Mary and Tom Poppendieck] have a lot more in there than just how you plan your work, which is largely what Kanban is about. Things like Continuous Flow, and a philosophy of improvement [a "Learning Culture"], and eliminating waste. Kanban though is only one of the tools used for creating a Continuous Flow environment, but it's not the whole picture. It would be similar to adopting XP and Scrum, but then only really talking about what goes on the planning board.
Many Kanban proponents will say to me, "no, Kanban is a whole philosophy" to which I ask, "why not talk about Lean as a whole then"? Because, we've already got a philosophy with Lean, and it fits in perfectly with agile.
If we're going to do Kanban, let's not just do Kanban, but let's take the whole Lean pie and embrace it because it fits in great with agile.
When asked more about what he finds great about Lean, Jim said this to close up our conversation:
When I first read the Poppendieck's book, I thought 'finally, here is something that explains why we're doing all this stuff we're doing in agile'. The Agile Manifesto of course has some principles associated with it, but in my opinion the Lean principles do better. Things like why we care about keeping our options open, and why we care about delivering frequently. Lean provides a lot of great explanation for that.
If you're interested in Jim's approach to and ideas about agile, be sure to consider checking out the Art of Agile Planning & Delivery public courses he and and Diana Larsen are offering June 8-12 .
Case Study: IBM's Agile Transformation
18 agile and lean practices for effective software development governance
Agility at scale, become as agile as you can be
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
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.
No comments
Watch Thread Reply