...
Design methodologies do not imply a waterfall-based development methodology. A Service Design Methodology can compliment an Agile approach.
| Table of Contents |
|---|
Agile Requires Planning Too
The Agile vs. Waterfall debate is often framed as an argument of extremes. People experienced in a variety of development methodologies understand that a tuned process is more nuanced than the this vs. that blog entries described.
...
Upfront planning is essential but the trick is to know what needs to be determined, how much detail needs to be known, and making sure that the plans evolve in response to experience gained from successive iterations. Mistakes will be made. It's better to make them fast and adjust than to follow out a predetermined plan through to absolute failure.
Refactoring is an accepted practice in agile development. This is how we incrementally improve based on what we know vs. what we are assuming. The risk is that a software project hits a wall where a major refactoring is required. Code is branched. It takes months to complete. Then it doesn't merge back in. This happens when there is no designated stable point in the system design on which everything can depend and evolve around.
We see this when a system depends on a framework to such an extent that replacing that framework requires more work than be be tolerated in iterative cycles. An example is the hot and cold relationships people have with ORMs and DAO/DTO frameworks.
Service Design To The Rescue
Some architects oppose agile-based methodologies. These tend to be the architects who are more design oriented who distrust an iterative and/or distributed development environment without solid well-thought out blueprints to follow. Again, the issue is how much needs to be determined on the blueprint and what can be deferred to iterative cycles where experience and re-prioritzations dominate.
...
- Service Design Methodology favors separation along service boundaries. Services define such boundaries as interfaces and as such provide a natural breakdown that can be developed in smaller chunks. This limits the scope and impact of refactoring.
- As technological choices such as application frameworks, ORMs, rules engines, identity management, etc. changes through the course of a project, changes can be prioritized and implemented on a service by service basis. Change gets a lot less scary when an entire project doesn't need to be redone all at once.
- If the impacted service providers are determined on a feature by feature basis, these boundaries can be used as collision avoidance ina distributed development environment.
...