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 Mark Levison on Aug 21, 2008
At Agile 2008, Dave Nicolette and Lasse Koskela, author of Test Driven: TDD and Acceptance TDD for Java Developers, ran a workshop on "Overcoming Resistance to Change". Any change whether an Agile implementation or re-arranging the office furniture is going to encounter some resistance. The real question is how we react when that happens.
When people resist changes we propose our first reactions are often emotional (anger and frustration): They're stupid, stubborn, etc. As Dave pointed out thinking like this will not help us achieve positive change.
Reasons for resistance were broken down into three basic types:
We were invited to play Dale Emery's: Resistance as a Resource Game - answering the question "Why would 'an intelligent, competent, sincere person of good will' resist a proposed change?". According to Dale the purpose of the game "To create, learn, remember, and express ideas about how to respond to resistance". In our version of the game each table worked together to discuss a few examples of resistance. For each resistance we proposed possible a Reason and then one or more Responses for each reason.
When it came time for the role playing Lasse join this reporters group and played the role of a Team Member who refused to standup. As a group we had discussed a number of emotional reasons that this person might be refusing to stand. However when this reporter acted as Scrum Master he completely forgot the emotional side and made cognitive appeals - which had no affect on Lasse. In the end the team stepped in and asked Lasse to be part of the team and try standing for the next couple of sprints.
Who will resist depends on the source of the ideas and their conflicting priorities. Developers want to deliver quality, customers might want features and management to protect their budget. So each will view proposals for changes from the others through their own lens.
In handling resistance we were reminded on Kotter and Schlesinger's Six Approach Model:
As Dave and Lasse both said its best to focus on the first three and leave the others alone as they can make the situation worse.
Johanna Rothman adds that when you see resistance you should consider if its a reflection of your resistance.
So when we're faced with resistance to proposed change, step back and consider playing Dale's gam with a partner it may help illuminate the underlying problem and also responses that help improve the situation.
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.
There have been several times since the conference that I've found myself in situations with people actively resisting new ideas. I find it a real struggle to step and ask myself about their reasons and what appropriate responses might be.
Its very humbling to try and put into practice new ideas like this.
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.
1 comment
Watch Thread Reply