links for 2005-05-27
This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.
Actually, the top-down vs. bottom-up thing isn’t “obvious” to me.
A purely top-down approach to analysis is suitable for a single simple application, but it doesn’t work well at producing a solid domain layer that can be used with multiple applications. The domain layer needs to be analyzed first (but not necessarily designed and built). After the domain layer is understood, then one can approach the process of analyzing applications in a top-down or use-case-driven manner.
One can certainly argue that the analysis of the domain layer needs to be informed by a general idea of what application(s) are going to be built on it, but I don’t think that makes it a truly top-down operation.
Following the analysis, the design and construction of both domain layer and application tends to take place in vertical slices - use cases, user stories, features, or whatever your favorite process calls it. I’m not convinced that top-down or bottom-up construction makes a whole lot of difference. Personally, I lean toward bottom-up construction so that I can perform testing on the evolving slice without resorting to mocks and stubs.
Doug, I see your point. Still, I believe that even if multiple applications are to share a common foundation, it’s a mistake to build that foundation from the bottom up. I think it’s more useful to extract the foundation after the first application has been built. Granted, you’ll pay a price because you will have to change some things that are based on assumptions that only hold true for the first app; your chances for success are large nonetheless.
I’ve seen quite a few projects where the bottom-up approach has led to a rather perfect and complex set of base libraries that nobody ends up using in the end, while the main goal - a running application - is never achieved.
But refactoring a production application is often impossible. Most of the companies I’ve worked for in the past 20 years have forbidden changing production applications without an approved Change Request (or whatever the local terminology is). Refactoring is all well-and-good while doing green-field development, but you can’t count on using it once an application gets approved to production.
The trick is to do the domain analysis based on the application at hand and the projected future applications. But building the actual domain libraries - and their underlying database tables - happens incrementally, as needed by the slices (use cases, user stories, features, whatever) being developed.
The “fully agile” alternative typically ends up with separate (and often incompatible) domain implementations for each application. Attempting to control the incompatibility results in one of Michael Koziarski’s points about the difficulty of enterprise sofware development, where a new application is required to conform to existing database tables that were poorly considered and are not well-suited to the new application. And with each new application that twists itself to use the misfitting tables, those tables become ever more resistant to being changed. http://www.koziarski.net/archives/2005/05/21/enterprise-development
Granted, in a situation where change is virtually impossible after you’ve shipped a first release, you’ll have to act differently. Most large-scale apps I have seen developed went through several “major” releases, where each release offered the opportunity to introduce rather drastic changes — which is OK, in my opinion, provided you know what you are doing (which is admittedly not always the case).
What I have seen way too often, though, is the other extreme - things are kept so general-purpose and generic that they take into account a multitude of possibilities that are never really needed — the system is built with a flexibility and an attempt at future-proof structure that never pays off.