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 Ben Hughes on Dec 06, 2007
Teams of workers that labored together for several months in specially designed "war rooms" were twice as productive as their counterparts working in traditional office arrangements...This sparked a Lean-Agile-Scrum thread discussion,some for and some against the concept. Jay Vandewark commented:
...one-room locations do have drawbacks and I believe that one-room locations are the weakest practice advocated by agilists.However Ron Jeffries' viewpoint differs - stating:
My bottom line, though, is that I have observed the team room effect:Are InfoQ readers thoughts on 'War Rooms'? Are they neccessary for a team that already buzzes? Indeed do InfoQ readers have any ideas about the layout of a room that fosters greater productivity? Take a look at the thread and post your comments below or on the thread.
and it is substantial enough to make me believe that it is by far one of the strongest of the Agile practices, not the weakest. Still needs to be tempered by other considerations, but it would be very unwise to dismiss it, in my opinion.
- on my own teams;
- on other people's teams;
- in the literature;
Agility at scale, become as agile as you can be
SCM best practices for multiple processes, releases & distributed teams
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!
Besides the resistance of many developers, I found there are actually other significant obstacles to war rooms.
I once asked my boss why we couldn't tear down our cubicles and build a nice, common war room environment. She responded that she'd be delighted to do so but:
- Cubicles are actually pretty cheap, apparently.
- Setting up a war room can actually cost more than cubicles for the same number of people, if you factor in buying extra whiteboards, re-arranging the environment, knocking down walls, etc.
- Many offices just aren't war-room friendly.
Still, I think one of the things that makes war rooms attractive is the simple fact that your company actually cares enough about your productivity to invest in your environment. It doesn't matter if you don't believe that war rooms are more productive, it's the mere fact that the company isn't stuffing you into a cubicle because "it's easier".
I would say the same about a company that tailored hardware, tools, whatever, to a particular team.
So, perhaps teams with war rooms succeed because they work in companies that support them rather than try to make them comply with accountant-driven ideas of the perfect work environment??
This sort of question always seems strange to me. I have worked in software development for several different companies, of wildly differing sizes, since graduating in 1986. I have always worked with the development team (and often with non-development staff) in the same room. I've only ever seen "cubicles" in Dilbert.
It just seems so much like common sense that working near to the people you are working with makes everything easier.
So I have to ask, can anyone give any reasons why separating a team might make it more productive?
One reply to the original paper was: Even here at the U-M, many of the conversations that I have observed in shared offices are not work-related. I feel very strongly that the bullpen or war room would be a terrible work environment. In addition to the frequent distraction of non-work-related conversations, many people feel the need to play radios during business hours. Often, head phones are not adequate to insulate people who want to work in a quiet atmosphere.
Of course, Ron's comments would be in the context of XP. And XP is a set of patterns that work together synergistically. None of those patterns provide a place for unrelated work being done in the team room, imo. And those patterns usually also provide for space for private work, when needed.
On a humanitarian basis, I urge these researchers to reconsider what they are advocating. Their next step should be to interview people who have worked in both war rooms and private offices or cubicles. I will be very surprised if they don’t find a strong worker preference for a private and quiet work space.
Experienced teams might have "team norms" as a pattern and "team turns cellphones off 10-4" and "have unrelated conversations outside" could be norms for one team, "no radios" could be agreed upon by another, if it's affecting one or more people's productivity. That is to say, the "continuous improvement" pattern (retrospectives, feedback) should allow for creating a better workspace, not just better software, since people create software and need to be treated well.
Having a war room isn't all that particularly helpful without XP. XP is the key... or more simply, a good team to start with.
If you have a war room and a bad team that can't communicate it won't make a damn difference in the world to productivity. So any consideration of war rooms is really only practical if your team is very XP - or as I like to say, good friends. In that sense, I've seen teams work just as well in a bar, at a coffee shop, in a war room, separated in cubes, sitting at home 400+ miles apart.
To summarize, the key isn't the war room, it is the team and the ability to communicate instantly. THAT is what does or does not make an environment helpful.
Personally I like two environments... war rooms and at home. All others IMHO are kinda "meh".
Sure - Joel Spolsky regularly argues that concentration is an important factor in software development, and that putting a software developer in any environment that reduces concentration is a bad idea, so he argues for individual offices.
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.
5 comments
Watch Thread Reply