I was triggered by Dennis’s post “Why developers should not be happy with a project manager” in which he states.
..in a team with different roles, there’s always the product manager and the program manager. These roles can never be filled by the same person. Putting it simple, the first role is there to make sure the customer gets what he wants. The second role is to make sure the team isn’t stressed out, can do their job, etc.
Dennis continues with..
People involved so far are also pretty anxious to use Scrum and some XP practices for this project, so we’ll see where this ends.
This reminded me of my own project experiences. Agile purists better stop reading ;) Looking back I can’t really say that applying more Agile methods gave perceptible better results. We did, however, spend more time thinking about the development process while applying Agile practices. During these times we strongly focussed on the sum of all the parts. I felt as if everyone in this big team had an equal share in the joint success.
Success equals the sum of all the parts.
Years ago I was very strong in advocating Agile over the Waterfall approach. Today I don’t care so much anymore which process is being applied as long as we all realize that success equals the sum of all the parts. My advice is to focus on the connection between your work and the work of others. Have great projects!
The Patterns & Practices team is working on the upcoming release of its Application Architecture Guide, 2nd Edition which should arrive late summer this year.
One of the areas the team seems to be concentrating on is Domain-Driven Design (DDD). A how to guide is publicly available since January. Skimming through the comments it appears that developers/customers are challenging the original authors how to apply the ideas and experiences published in books (Evans, Fowler, Nilsson).
Implementing a domain model in a general purpose language (Java, C#, etc) is challenging. Key to success is to have as little distractions (from the development platform) as possible. The set of design principles and patterns will help to accomplish this goal. I learned that, after discussing ideas with attendees during my “Applying Domain-Driven design in .NET” talk at SDC 2007, there’s a strong focus to overcome the technology use/constraints in applying DDD in our target platform.
My advice for the Patterns & Practices team is to focus on:
Which principles and patterns should be applied (as a coping strategy) for the distractions in the development platform?
Please realize that this is different from guidance on how to implement DDD-patterns with the .NET platform.
Language workbenches are well underway to completely change the way we do programming, so we might not this guidance anymore ;)
I love the summaries on InfoQ. Earlier this week I received a presentation by one of the customer’s developers. Basically they used MVC for a spreadsheet type application. The answer to the question “what made you guys decide to use MVC for this applications” was interesting “because we wanted to learn something new, and because it’s cool!”. That’s when my architect alarm bells start ringing. What I’d like to add to the whole ASP.NET MVC discussion are these two questions:
1) Why do you need an MVC in your application?
2) Why is the, compared to other alternatives, ASP.NET MVC the best MVC solution for your application/environment?