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.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
The Open UP Debate
Posted by Shane Hastie on Mar 05, 2010
Recently a discussion of the various derivations/flavours of the Unified Process was posted here. There is some debate among the InfoQ readers regarding the Open Unified Process (Open UP) which mirrors debate in the wider blogsphere.
Mark Lines of UP Mentors wrote a recent article titled "Agile Development Grows UP" in which he cites Scott Amber as stating that many in the Agile world seem to trivialise or ignore the realities of the corporate world:
- Many of us don’t have the benefit of co-location, where the entire team works in close proximity (ideally in the same room), with the user representative present at all times to answer questions
- Pair programming i.e. 2 programmers sharing 1 keyboard is an expenditure most management will not endorse
- Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes.
- Fixing architecture as you go (i.e. refactoring) without some initial architectural design is not appropriate for large-scale enterprise systems
- Most projects are not completely independent and cannot be built in isolation. Dependencies and integrations with other systems are required and require some co-ordination.
- Organizations usually have some governance practices in place (such as PMOs, ISO, CMMI) that necessitate a level of bureaucracy and documentation
- Deploying software to users every 1 or 2 weeks is usually not practical in most organizations. Just migrating software through development, test, system test, user acceptance, production environments is a major undertaking. Having many projects trying to do this in parallel on a weekly basis simply isn’t feasible.
He continues with an overview of OpenUP and contends that it provides an adequate framework and process to deal with the broader corporate challenges while still retaining a core of Agility.
A contrasting viewpoint on OpenUP, and UP approaches in general can be found in Michael Dubakov’s response - Relax, Agile Development IS Growing Up - wherein he addresses each of the challenges Lines raises:
On Colocation:
Sure we all know that a co-located team is better. It is not a surprise that consultants advise to co-locate team members. If you need to win the race, it is better to drive BMW M3 than Ford Focus. There are so many discussions around distributed agile this year. There are so many ideas and experience reports on how to implement agile remotely. Agile works in remote teams.
On Pair programming:
It’s a very strange argument. Many managers will not support continuous integration, iterative development and BDD. It does not mean that these practices are bad. Context is everything. In some companies and on some projects pair programming will increase productivity. While on other projects there will be no benefits or even degradation. How many agile coaches insist on pair programming and say “You are not agile without PP”? Not many. It is wrong to spread this argument to the whole agile community.
On detailed requirements:
C’mon! User stories can be VERY detailed. For example, you may use BDD-style user stories format and write many cases that will describe functionality in some format, that can be directly converted to unit tests! It is an incredible thing, to be honest. http://www.targetprocess.com/blog/2009/10/bdd-and-user-story-specification-examples.html
On architecture
Most people in agile community believe that it is required to spend some time on architecture. Again, it is so context dependent. If you create a simple application, one day may be enough to nail down all important decisions. If you create a complex system, it may take several months. Common sense is a critical factor here. There is always a danger to over-architect things and working software is the best proof of concept. Also something called “emergent architecture” is being developed. I like the idea and maybe it is a right direction. http://www.infoq.com/emergent_architecture
On project independence
Agile adoption is spreading rapidly and indeed there are no common/standard approaches to solve this problem. But I believe it will be resolved during agile enterprise adoption (and we already stepping into this phase).
On governance & standards
Does it all mean that PMO, ISO and CMMI are good and we should give up and follow the rules? Agile community tries to fight bureaucracy and I personally love that. Documented process means NOTHING for success of software development project. In 90% of cases it holds you in the spider’s net and blocks creativity. There is NO software development without creativity. Wake up, Mark.We live with these standards, but we should fight them.
On frequent releases:
This argument is so common… and “not practical in most organizations” is a truly masterpiece. Any statistic data? Did Mark try to deploy anything outside the enterprise-scale Java mastodon applications world? Many SaaS services do painless weekly updates. Some services do painless updates on a Daily basis! It is unbelievable, but I like that. Customers like that!
Which side of the argument gets your vote? Please share your feedback.
Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Transforming Software Delivery: An IBM Rational Case Study
Agile Maturity Model Applied to Building and Releasing Software
Related Sponsor
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!
Forgive my ignorance.
by
Chris Matts
Posted
The thing bothers me about Scott's claim...
by
Mark Levison
Posted
-
When I think of RUP, I think of a business/systems analyst/designer creating a domain model and then using this to drive the development. I used to work that way but I no longer think it appropriate. ( Forgive my ignorance if RUP etc. no longer drive using models. )
I now think the development process should be driven by examples/tests.
Apart from that, I'm not that bothered. -
...is that we should live with these limitations forever. Many these limitations exist for now. My approach at the start accept the limitations, create small successes and build trust. The more success and trust you've built the more leeway you can get.
Some examples:
Scott says: many organizations will never accept pair programming.
My take: Once trust has been built go back and make a case for pair programming. Ask about running it as a 6-8 week experiment.
Scott says: The needs of training, documents etc require more detail in the user stories, ...
My take: record that detail in the user acceptance tests in way that humans can read and understand i.e. a wiki, excel. Then work with these groups to use it. Over time I like to see docs etc made part of the team and contributing to done.
I often see limitations that can't be handled today, they question is will you accept them forever or always seek to improve.
Cheers
Mark Levison
Agile Pain Relief Consulting
2 comments
Watch Thread Reply