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 Mukund Srinivasan on Jun 23, 2009
When we, as an organization, were first exposed to Scrum a year ago, our first inclination was to believe that it was one of those areas that management wanted to see addressed, because there needed to be change in the way engineering functioned, and soon at that. Back then, it felt like it didn't have to be "Agile" that cut the bill; it could just have been anything that was different to what we were doing, and it would have gotten washed in the then popular "sweeping winds of change".
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!
Fast forward a year and there are numerous benefits we have reaped as an organization, due to the transformation we underwent, thanks in no small part to our then new VP of engineering who introduced us to Scrum. Putting a stake in the ground this moment, a few of the touted benefits we can claim points (see I can even speak the lingo!) for:
Not that any of this wasn't happening in any of our teams a year ago; it is the synergistic nature of all these points coming together in every single team that was missing then. Lest this article becomes another "driving" home point about the benefits of Agile, I wish to quickly move away - there are far more qualified experts to drive home that point if the results of Agile transformations don't speak for themselves already.
My inclination to pen this note stemmed not from the visible changes I have seen in our teams, but rather from the intangibles; the hidden side of the transformation, so to speak - the changes in perceived values of interpersonal relationships, the enhanced necessity for trust, the soon-obvious need for enhancing cross-site communication inefficiencies, etc that I wish to delve upon. In all the thousands of links I have clicked and forwarded in the past year, the white papers in every document kind and format you can imagine that have been shared, hardly not even 5% (or one-twentieth) of that have touched upon the point I am noticing as a by-product of our transformation. I don't remember where in that sea of information I found it, but I vividly remember a quote from last year - "Truthfulness is the foundation of Agile". A colleague later pointed me to a link that expressed this in better words.
By no means am I implying that a whole bunch of my colleagues and friends were dishonest and have become otherwise overnight; far from it - in fact, I am yet to encounter a professional situation wherein I have sufficient proof of anyone ever being dishonest intentionally. Rather, in my humble opinion, it is the circumstances that make or break an individual's reaction to a situation when it demands total truthfulness in all forms of it. Before I am branded naïve - the dishonesty as I understand it does not have any shades of grey whatsoever; you are either ethical or not; honest or dishonest, period. The weeds that don't conform to the ethical standards we have as a society possibly disappear from our radars over time as we humans tend to have a scenario of wanting to remember only pleasant thoughts and it applies to people as well.
Back to mainline, the honesty and truthfulness I am referring to is as abstract a concept as it can get. It is the commitment we make to ourselves and to those around us that makes our conscience clear. As a simple example, I wouldn't have hesitated twice if a couple of years ago, I was asked to take a swag estimate at what it would take to build something new, in my then role as an architect. Now, nothing's changed as far as my engineering biased estimating abilities go; it is the added sense of "am I committing something on my team members' behalf that I am doubly sure of?" For when I see a team member doing whatever it takes to live up to the commitment they made to the team, I want to hold my end of the bargain and wouldn't want to make a commitment that he/she cannot live up to. If you see closely, the lines are blurred and the roles are merged - team dynamics win! Before our Agile transformation, we could have made a commitment to those around us, but for various reasons outside the purview of those immediate actions, not have had to deal with it then and there or subsequently have to face the reactions emanating from those direct actions. With Agile and Scrum, because obstacles stare at us in the face and because we want to be part of the crowd we live in (herd mentality?), we are consciously looking to make a commitment - one that we can live up to, so as to not be isolated from others around us.
Think about it for a moment - if in your own ecosystem, every single individual speaks his mind about committing to something and owns up to it, honestly, it puts that extra bit of what's commonly known as "peer pressure" on everyone else to live up to one's own commitment. I am confident enough in the thought that given the control over our sphere of influence, we can control our destinies - implying there shouldn't be excuses to commitments we make to ourselves. Somewhere I read an article that our personal lives are just an extension of our work lives considering the amount of time we spend at work. For all my abilities to search on Google or any other search engine for that matter, I could not come up with an article that correlated how Agile development methodologies at one's workplace translated to a better quality of life outside work. But just cogitating on that thought a bit - if we were to adopt the same principles to outside of work, in our personal lives as well, can there be a better lesson we can convey to our children? Legacies are not made or created by monumental single actions, in today's world, as they were say in the era of wars a few centuries ago that created possibilities for overnight heroes. Today our legacy is not about what heroic actions or deeds we performed today, but actually what contributions one has made in his / her career that spans 2-3 decades.
If it means that the effect of a transformation in one's career has a direct correlation to a positive impact on society, then that needs to be celebrated. If we have an opportunity to set an example in our lives and thereby create our legacies (in our own small ways) thanks to the not so obvious faces of Agile, then I am all for it - therein, my friends, lies the hidden face of Agile.
Yet, there is one aspect of Agile doesn't apply to our daily lives - "life is a marathon, not a sprint"!!
Good perspective.
I'll share this!
you expressed a important aspect about agile philosophy. Ill share this too
I was really excited to read you latest post on truthfulness. I happen to work with Mishkin Berteig at Berteig Consulting and am aware of the original source of the concept of truthfulness as the foundation of Agile. In the writings of the Baha'i Faith (bahai.org) it is stated: "Truthfulness is the foundation of all the virtues of the world of humanity. Without truthfulness, progress and success... are impossible..." (reference.bahai.org/en/t/ab/TAB/tab-497.html#pg459).
Agile is about "uncovering better ways" of doing work. In order to uncover better ways, we must utilize certain human capabilities (i.e. virtues) such as imagination, thought, creativity, search, wisdom, tact, insight, foresight, etc. The foundation of all of these is truthfulness. Therefore the foundation of Agile is also truthfulness.
"Agile development methodologies at one's workplace translated to a better quality of life outside work "
This is true. I am working on an Agile project from last 2 years and I realize that I have become a better human being- thought process has changed.
I think life is also made up of sprints. The only difference here is that the sprints are of 5-6 years long.So plan it accordingly.
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.
4 comments
Watch Thread Reply