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 Chris Sims on Dec 08, 2008
Scrum has proven effective at promoting communication between members of a development team. The question of how to scale this high-bandwidth communication across teams, especially in large organizations, remains an area of active exploration and debate. Will Read has proposed a mesh-network inspired alternative to the popular Scrum-of-Scrums meeting for achieving this goal.
Will points out that the Scrum of Scrums creates a hierarchical, tree-shaped communication network. People are the creators and consumers of information in the system, and they are the leaf nodes in the tree. This structure works reasonably well for drawing information to, and disseminating information from, a central control point. However, this may not be the best way to coordinate the work of the developers. The type of information that individual developers need to know is unlikely to get transmitted up and down a tree effectively.
Jim needs to know about the new Logging API so he doesn't have to rewrite one of his own. Bob needs to know that Sue has a problem with the parameters being passed to her function because she wasn't expecting NULL to be allowed. Dave needs to know that he needs to add upgrade the Linux servers to the latest Java VM to fix a bug Mark found, and the new employee, Mindy, needs to figure out where to download the third party DLLs from.
This type of information is more likely to flow across a mesh network where individuals and teams connect with each other in a more ad-hoc and as-needed basis. The question then becomes, how can a company create a mesh network that promotes this type of information to flow? Promiscuous attendance at daily stand-up meetings is one approach. If two or more teams often work in the same code, or otherwise are likely to have interdependencies, then it may make sense to allow members to attend the stand-up meetings of the related teams. Will also suggests some additional approaches:
Will describes the benefits of this type of communication network this way:
Through this Mesh network, a company can produce a much more adaptive communication structure that disseminates knowledge more reliably, is at less risk of a communication failure, and addresses the issue of limited bandwidth in a way that scales to any sized company. Best of all, it fits with Agile principles of self-organizing, and removing waste in a way that enhances your business.
As described, the mesh network is designed to promote information flow between developers, not status reporting up to management. For this, the tree may still be the preferred approach, though the amount of bandwidth needed will be greatly reduced if the focus of that communication is around status, progress, and priorities.
How do the Scrum teams in your organization communicate with each other? How well does it work? How could it be better? Leave a comment and share with the community.
Agile Development: A Manager's Roadmap for Success
Case Study: IBM's Agile Transformation
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!
We've found that Mesh alone only goes so far in promoting communication. We created a SoS where each team nominates a representative to attend for a Sprint. The reps rotate so all team members will eventually get a turn to attend. We run the SoS exactly the same as the Daily Scrum Meeting by each rep answering:
- What did my team do yesterday?
- What did my team do today?
- What impediments is the team facing?
This approach has removed the hierarchy problem sited in the article. It works great in combination with the suggested Mesh approach.
I used to work for this company that had two teams which were not in the same geographical location. The two teams were working on two different products but they were led by the same CTO; therefore, we were asked to keep the technology level in the two products at the same level so that managing technology risk and all those things is a lot easier. It goes without saying we had serious communication issues and to some extent we had lack of communication to begin with. However, we used a Wiki that had RSS update feeds, and everyday when I had a few free minutes I used to go through what was new in the wiki and after a while I was an active member of the other project's discussions.
I could never put this idea into practice but I do believe programmers should blog their programming life and everybody in a company should browse those blogs. This will give a very good visibility to what is going on throughout a company.
Edit:
- What will my team do today?
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.
3 comments
Watch Thread Reply