Collaboration: At the Extremities of Extreme
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.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
How would you like to view the presentation?
Getting Started with Stratos - an Open Source Cloud Platform
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!
Great presentation. I read an article about DCI before, but didn't get it. James does a great job here of getting his point across. The idea of use-cases as their own abstraction is a powerful one. Also, I've always been confused between the difference between an objects role and its (domain) class. DCI provides an answer.
I haven't followed through the code example bit yet (brain overload), but I can't help thinking that perhaps classes should be avoided all together, and the required role needed to support the context (use-case) should be built up dynamically by mixing in the appropriate role trait. The Self language came to mind.
One thing it drove home, is just how difficult it is to come up with software abstractions that map well to the abstractions in our brain. I guess its the powerful R-Mode pattern matching feature of the brian that allows us to perceive patterns and abstractions that are very difficult to replicate in software. Is the added cost and complexity of DCI worth the benefit? I don't know.
One nit-pick. I didn't buy the link with Lean (or even Agile for that matter). Not sure if it helps, other then tying this idea to some fashionable buzz words. For example DCI doesn't sound like the simplest thing that could possibly work... and could even be considered YAGNI.
I think it is going to take me a while to digest this one. Thanks for getting this content out there.
Paul.
I am very happy to have had the opportunity to delve deeper into DCI. I finally resolved myself to work through the OOram book and I think that the distillation of OOram to DCI is commendable. I heartily agree with Mr. Coplien that the model in the mind must be captured in the architecture. We definitely need to move away from our grandfathers’ OOP and fast.
I am not convinced that creating polymorphism through templates and calling it Role/Context is that much different from using inheritance to create objects with varying strategies. Certainly, one can create the same "Form" by interchanging the use of inheritance with the use of templates. What one chooses to use is personal preference I suppose. I myself prefer to leave them in the realm of containers and algorithms. What I find alarming is the claim that I will attain OOP nirvana by removing inheritance from my arsenal of software tools. Please don't take away my inheritance - I beg you.
Is the key objective of DCI to create software that can be more easily understood and mentally verified? I do not disagree that these constructs provide the ability to present the logic - the user stories - in a meaningful way. I am just not convinced that this paradigm provides a level of clarity greater than that which can be achieved through the use of aggregation and inheritance.
Does Mr. Coplien propose this paradigm as a stepping stone to OOP? A way of helping the masses get on the band wagon? I see value in this approach as a teaching aid, one that could help people to train themselves to think in terms of objects.
Certainly DCI is a helpful construct for a certain class of problems. But I can think of other classes of problems where the usefulness of this construct is not so apparent. I am currently developing a tool to simplify RIA development and I am hard pressed to think of a DIV element as a role played by an HTML element. I have spent the majority of my career developing tools to simplify development and to maximize re-use. IMHO this is a big part of OO development where DCI does not seem to apply.
I am very grateful to Mr. Coplien for using his prodigious intellect to help further illuminate the murky waters of OOP. Unfortunately, I am just not convinced that the distillation process is complete.
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.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
2 comments
Watch Thread Reply