Many development teams struggle with using a consistent approach in delivering quality software. By delivery, I mean the iterative build drop to the customer up to the final release.
Should the task assignment to a developer be use case based or component/feature based? Should we focus our build drops around use cases or components? Should we just let it be in a lassais-faire environment where delivery is haphazard and to each his own?
To know the best delivery method we have to go back to the basics. To a user, the internal components of the software are a black box. A software is developed to satisfy certain human goals and actions, not just for the bits of it.
So a characteristic of the correct method to follow is to be centered around the elementary business process that the user is trying to accomplish. Components do not exist in vacuum.
A user goal or use case is a vertical execution path that spans multiple components. Therefore, to be more client-centric, our deliverable must be organized, tested and delivered to execute use cases. The benefits of this vertical delivery approach include:
1- Early delivery of functional and observable code to the client
2- Early delivery of value for the customer’s investment. The “get-hit-by-a-bus” factor is always their concern
3- Effective testability where it is in line with user goals
4- Early discovery of integration issues, since we’re always integrating
5- Forcing the creation of a base-line architecture early
6- Forcing the early discovery and resolution of architecturally significant issues
As you can see, the vertical or use case based delivery approach enhances software quality dramatically, mitigates risks and increases the sponsor’s return on investment.
When it comes to assigning development tasks to team members, we should also apply the same reality criteria we used above to arrive at the answer. To start with, software is an ocean of specializations where each one hosts a deep well of knowledge and issues.
Except for small, experimental and throw-away code (.com era comes to mind) projects, it is counter-productive and detriment to quality software to have a team of “do-it-all” developers. Those “do-it-all” developers should be on the way up their career ladders to become Development Leads and Architects.
It is impossible to be an expert at everything. A developer cannot be highly knowledgeable in the intricacies of development technologies such as WCF, Multi-Threading, BizTalk, GUI design, security, compression, web etc… all at the same time.
Plus, the professional maturity level of developers differ. You have the programmer who is a routine coder, then you have the component coder then the application coder etc…
A development dream team is the one that is made up of specialists. A database specialist, a performance specialist, a work flow specialist, a communication specialist, a security specialist etc…
Based on the above reality, the best implementation method that aligns with it is horizontal, not vertical implementation of software. The architect usually determines the needed components and assigns the specialist developer that task (maybe with the help of the development lead). In long standing teams, it is critical to the productivity of a team to have that same developer own that component.
Typically, at the beginning of the software project, the architect builds a matrix of use cases (vertical) vs components (horizontal) needed and adjust in every iteration.