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 Kurt Christensen on Oct 19, 2007
It's not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you're actively working on a program it can take half an hour to load into your head when you start work each day. And that's in the best case. Ordinary programmers working in typical office conditions never enter this mode. Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they're solving.So what can a developer do to get a program loaded into their head? Graham offers eight suggestions:
Five Key Practices to Agile ALM
Case Study: IBM's Agile Transformation
Agility at scale, become as agile as you can be
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.
Well, I was all prepared to disagree, but I like a lot of what is said.
My first and most important point is that this approach does not scale. If you want an approach that scales, you need to be able to have one or more levels of abstractions, you need to be able to separate the concerns and hide the details behind interfaces. Your mental model will not be in code.
Let's go through some of the points he raises.
Avoid Distractions: definitely not very agile. I favour Alistair Cockburn's description of 'osmotic communications' - one has a subliminal awareness of what's going on in the rest of the team. This isn't a distraction until it needs to be; until something comes up that needs your input.
Work in long stretches: I favour sessions about 90 minutes long. I really like and agree with Paul G's point that time away from a problem can give one's subconscious a chance to solve it. To me, wanting longer sessions is a smell; it says to me that the mental models are not adequate. For me, a good model is an aide-memoir; one glance at the model and the whole thinking behind it comes rushing back into my mind. Sure, if I haven't solved a problem then it takes a while to get back into the train of thought - but that tells me the problem is not being cut down into small enough chunks.
Succinct Languages: Agreed.
Keep re-writing: Only to improve the code.
Re-readable code: Essential.
Work in small groups: I favour group ownership of the code. This scales better and means that you never lose the ability to do all-encompassing re-designs.
Several People Editing: His suggestion here is definitely not agile. It sounds quite dysfunctional. The team should be working to a shared vision.
Start Small: Agreed, but the problem he addresses is better solved by developing abstract models that keep the big picture in mind, while delving into the detail one area at a time.
In general, these practices talk to me of poor team communication, poor abstract modelling. If you're listening, Paul, take this as hints as to how you might improve, not as destructive criticism.
As always, thanks for your thoughtful comments. I like most of what Paul Graham has to say, which is why I always enjoy trying to map it to practicing agile in a large IT shop. It works more often than may be obvious, but not always.
Which brings me to your comments. I agree with what you said, but I don't think it's because he's wrong, I simply think it's because he's addressing groups of 2 or 3 incredibly talented developers working on apps for startup companies. In that case, there are different forces at work, and - more importantly - the codebases are new and small. As an example, Reddit was built on top of web.py which is all of a thousand lines of Python code. Contrast that with one of my current clients, which has about 2 GB of source code feeding into a single product suite. I don't think the values in those two organizations necessarily differ, but the practices certainly will.
Hi, Kurt.
Yes, I'm all in favour of applying what works best in the given circumstances. I don't subscribe to the view that there are *any* universally best practices. On the other hand, a successful start-up will grow into a different set of circumstances. It makes sense to be aware of the problems that will come to the surface when that happens.
> Avoid Distractions
I've worked in Agile environments where "shared workspace" led to distractions, because of:
- poor inter-team boundaries (low walls, with team A overhearing team B's discussions: a real annoyance because team B's "noise" didn't contribute to team A's work, and vice-versa). This was resolved by adding a full wall in that location.
- poor teamroom flow (everyone sitting facing *out* at the boundary wall of the team room. Every conversation was shouted across the room). This was resolved by moving the tables away from the walls, to create smaller "pools" of conversation.
In both cases, space design contributed to chaos, rather than enhancing it. As long as the space itself is agile (susceptible to change, as needed) this just becomes part of the continuous improvement cycle.
Agreed. We want to distinguish between unproductive distractions and productive distractions. I wrote about productive distractions several years ago:
<www.aptprocess.com/whitepapers/risk/RiskToPatte...>
There's also a page on that site titled "Interrupts Unjam Blocking" (the name says it all!).
We usually consider these ways of thinking to be already embedded in the ways an agile team works.
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