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.
Posted by Geoffrey Wiseman on May 02, 2007
In an eight-page interview with Stefan Roock, Jeff De Luca, who created and documented Feature Driven Development, discusses developing an overall model, code ownership, choosing an agile method, and more.
Contrasting feature-driven development with other Agile methods, Jeff says the initial phase of FDD (Develop an Overall Model) allows project teams to come to grips with the overall project such that they can answer questions like, "How much of the project is left?":
If we are too pure in our iterative/incremental approach - that is we are also slicing through requirements and analysis - then of course it is hard for us to answer the questions "How far along are you?" and "How far is there left to go?" because we haven't even looked across the rest of the requirements yet. So, there has to be some informational/analytical activity at the start to give us the knowledge to set a baseline that we can track and report against so that we can answer those questions. FDD is the only agile method that gets this part right.
Addressing the idea that this phase can be seen as Big Design Up-Front (BDUF):
Not "all of the design up front" as the pejorative use of BDUF has come to mean - but "just enough design" and note that this first activity in FDD is as much about requirements and requirements analysis as it is about high-level design.
Jeff De Luca also takes a strong stand against collective code ownership:
Collective ownership is code for "no ownership". It's not a structure I believe in.
And in favour of individual code ownership:
The concept of module or component ownership has long been practised and long been known to be a best practice. That's how all professional development at scale is done. Everyone can't know everything about everything - that is brittle and it can't scale.
And what's especially ironic about this is that one of the fundamental principles of OO is encapsulation; how a class does what it does is private and internal to that class and those implementation details can vary wildly as long as the class presents a consistent interface to the rest of the world (the other classes). Well, humans naturally encapsulate. If you practice class ownership you get much better consistency of implementation and interface.
Although he tempers that stance with:
Class ownership is not a life sentence. If you get the Customer class you're not stuck on Customer forever. These owners can and do change throughout a project.
Jeff De Luca takes a pratical approach to choosing an agile method, when talking about the different agile methodologies and their suitability to different kinds of projects:
I don't think the Agile methods classify ... by project type. When it comes to this sort of thing I tell people to get Jim Highsmith's Agile Software Development Ecosystems book. That's the only book that talks about all the Agile methods, in some detail, in the one book. You read that book, and one or two of the methods are going to resonate with you and your team. And whichever methods those are, they are the ones you should explore. In other words I'm saying that the Agile methods are more suited to types of people and organisational cultures than types of project.
The interview ends with references for further reading on FDD.
For more information these topics, consider reading InfoQ's coverage of agile methods, feature-driven development, and modeling.
Agile Development: A Manager's Roadmap for Success
Case Study: IBM's Agile Transformation
18 agile and lean practices for effective software development governance
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
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