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 Mike Bria on Aug 27, 2008
A successful meeting will identify specific metrics that will bring the discussion of technical debt down to earth. It will also marshal evidence that we're not fooling ourselves when we say that borrowed trouble behaves like borrowed money. (Or better, we prove another dynamic is in play.) It will also state debt management and debt repayment strategies and when they are indicated.The conference aimed to answer these 3 primary questions:
Transforming Software Delivery: An IBM Rational Case Study
Agility at scale, become as agile as you can be
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!
Thanks for the coverage of the workshop.
Just to add -
1) Chris Sterling has some (relatively) comprehensive coverage of workshop material listed here:
chrissterling.gettingagile.com/2008/08/25/the-i...
Obviously, it's hard to distill two days of conference into two or three pages of text, but he makes a strong attempt.
Also, we video-recorded the talks (thanks to Agile Alliance Sponsorship) and expect to have them up on youtube within a month. (Volunteer video editors of course). For the latest updates on the workshop, the best place to check is probably my blog:
xndev.blogspot.com
Technical debt is something I have been looking into for quite a long time. From looking into a whole bunch of software architectures, and unraveling their history, it appears that a lot of it come down to putting the best folks on an unexpected requirement to come up with a "really neat hack". The early payback on this is so great that these developers seem "10 times more productive than the average developer", so we reward hacking, and clap and
cheer when folks do it again. Eventually, they are the only folks who can understand their own fragile lattice of hacks, and everybody else backs away from the code. Eventually, even the mental ability of these folks is overwhelmed, and you have a bankrupt hackitecture.
Quite a bit of this is written up in a chapter in a book I am in the middle of writing: anthony.lauder.googlepages.com/legacysystems
(1) lack of self discpline
(2) impatience/hurry
(3) ignorance.
I have done a good prototype with exciting features. Then, I felt exhausted and even a bit disgusted with my own code. Heavy debts make the product ungly.
You may read more at ethicminds.blogspot.com/
Technical debt is either (1) "unknown unknown" or (2) bad YAGNI(You Aint Gonna Need It), as opposed to good/official YAGNI, or clear YAGNI.
See more at
ethicminds.blogspot.com/2008/09/technical-debt-...
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