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 Amr Elssamadisy on Jun 02, 2009
Bas Vodde describes strategies for large teams with legacy software to adopt Scrum successfully in this interview at Agile 2008. Bas discusses communication problems found in most component teams and why and how teams - especially large ones - should make the change to feature teams and how that change affects organizational structure.
Bas discusses the communication issues that come up with component teams:
If you got a bunch of component teams and you got one requirement and one requirement will never fit to one component team, and therefore the requirement will need to be split up and parts of the requirements will need to be given to different teams. Once you got a requirement and you give it to multiple teams and the requirement is over, first of all there will be a lot of communication freezing of interfaces and that kind of things, to decide, because interface in software and communication between teams in component teams is equal to each other so teams need to freeze their interfaces because their interface is the communication between other teams.
If they freeze the interface they can program to the interface and then hopefully later integrate it together. And because the requirements never balance to the teams, therefore the teams will get out of synch so when they got maybe perhaps not the highest priority requirement then that requirement will be worked on for example in one component team in one sprint but the other team will not be working on that requirement yet and they will be working on the next sprint and therefore you get not only the communication or the synchronization issues but because they are not working on the same feature at the same time you get this other team sprint later communicating back about one thing that they did in the previous sprint. And you get kind of the same problems as traditionally between developers and testers, where developers are annoyed by testers because testers are giving feedback about what the developers did earlier.
And his solution to this problem is to create feature teams and have teams manage their own inter-team communication:
One of the key practice for letting multiple teams work on the same component is continuous integration so a lot of the communication actually goes by the teams via integrating lots of small parts. So for example if one team makes a change in a component the other team is also working in that component and they notice that the other team makes that change then at that moment these teams would talk to each other and that is another important concept which we talk about in the book is that teams within a large product need to be responsible for their coordination between teams. Instead of creating a role for coordination, it’s the job of the team to coordinate between teams and such coordination could be changes in the code for example.
So if you are in a large organization considering a move to Agile watch this interview.
Transforming Software Delivery: An IBM Rational Case Study
Agile Development: A Manager's Roadmap for Success
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
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