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 Mark Levison on Jul 17, 2008
Last month the Japanese labor board ruled that the death of the Chief Engineer on the Camry Hybrid project was ‘karoshi’ (death by over work). In his last few months he worked more than 80 hrs of overtime a month. He died of a heart attack only day before he was due to fly to the Detroit Auto Show.
This story raised a number of interesting issues about what we can learn from Toyota, sustainable effort and why we develop software.
Joe Little points out that “Lean has a principle of not over taxing the system”. He goes on to ask is excessive overtime a fundamental part of Lean at Toyota or is this isolated to a specific group? Finally he reminds us that even though Lean comes from Toyota they are not perfect. Even so we can still learn from them and other lean practitioners.
Robin Dymond says:
I thought this was sad but interesting. The lean product development model that Toyota uses rolls the product owner, scrum master, and technical lead into one role, the chief engineer. Mary Poppendeick and I have been talking about how this leadership model might apply in software development too. The issue I have is that the Product Owner is already an overloaded role and an achilles heel for a scrum team. Adding the additional technical and process responsibilities has always struck me as being much too heroic, and not sustainable. It looks like that this may be the case.
Mary, author of Lean Software Development, replies, recalling her time as a Product Champion at 3M:
on good teams, overload/overtime was something that the team members did to themselves due to their passion for the product they were developing. I also do not see the product champion as an all-knowing all-powerful person - just a person with a vision that can excite passion in a team. When I was product champion, I certainly never could do all of the things expected of even a product owner all by myself, but I did know how to get the right people on the team and get them engaged in the goal – so all of the necessary technical and marketing things happened.
She goes on to say that any role can become overwhelming as they become a laundry list of things to do instead of a checklist of responsibilities shared with the team.
Finally in response to the problems of hard deadlines and fixed features sets imposed by management Mary comments:
Perhaps the biggest problem that drives the symptoms mentioned is that software seems for some reason to get divorced from the overall system and the overall business purpose of that system. Then of course, no one can get passionate about it. We have to stop developing software and start making systems that serve important purposes, so that team members can make valid judgments about how important the schedule really is – how important that difficult feature really is – what test strategy is best for the long run – where the true cost of the system lies.
18 agile and lean practices for effective software development governance
Agility at scale, become as agile as you can be
A practical guide to choosing the right agile tools
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!
So this is the classic case of the lynchpin guy getting hit by the proverbial bus. Noone ever wants to talk about it, but over-specialization/over-concentration can be a disaster for a project when someone leaves, or in this case, worse.
One person doing too much is also just warning sign that team work on your project is poor. Why is (s)he doing so much more than the others? Is it because they are territorial, or is it because they're terrified?
While its great to see passion, it's like marriage. Passion can only carry you for so long if you try to go full throttle all the time. Sooner or later, your energy level can't be sustained anymore, and if you try, you burn out. You end up hating the work you used to love. Moderation is far better... that's the key to sustainability.
This is just one of the reasons you need to monitor the hours people are truly putting in to ensure it's because they want to be working those hours rather than it's because they feel pressured to work those hours. Overtime is inevitable, but that doesn't mean it needs to be destructive. Quality suffers, your people suffer, and inevitably, you suffer as a consequence.
Jim - I agree. I think the hard part is spotting someone who is pushing too much and too hard.
His timesheet might have been a clue!
True Dave - but that assumes two things the organization keeps time sheets and that he was honest when writing in it.
In some organizations that don't pay for overtime employees don't see the point in filling out the time sheet with their real hours.
In his last few months he worked more than 80 hrs of overtime a month.
Someone was watching his hours. I'm just sayin'...
Jim
I understand where you're coming from but I think that it's not easy spotting the point in which
"positive" enthusiasm turns into compulsive behavior.
speaking as a "passionate" guy, I can tell you that trying to restrain my self from over working
always feels like trying to artificially convince myself that i care less,
furthermore we all want to succeed and it's very easy to say to your self -
work harder and you will have more success!
another angel is that because software development is part art form it's easy to relate to your work on an emotional level which blurs the boundaries that should exist between work and personal life,
making it really hard to find the right balance.
I think that at the end of the day finding the right balance is something that everyone should do for
him/her self, it's not something that your employer can impose on you and the most important thing
to remember is that "karoshi" is not an option.
Asy.
Asy, your comment made me laugh: "remember is that "karoshi" is not an option," because on our first agile team, we had a mascot sock monkey called Karoshi - and he got messed up in all the worst ways. He literally "hit the wall" many times, got hung up in the rafters and one morning was discovered in the paper shredder. I had never thought of these destructive activities in the context of his name, before. :-)
Isn't the chief engineer's role outlined in the "Toyota Way" similar to a surgical team? One quarterback, the others are instruments in the offensive choreography?
Cheers,
Zubin Wadia
CTO
www.imagework.com
"Business Acceleration through Process Automation."
I always knew that agile can bring the worst out of people ;-)
seriously though, I'm happy to hear that I made you lough ...
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.
9 comments
Watch Thread Reply