Mitch Denny’s and Paul Stovell’s posts on frameworks are thought-provoking, especially because I’m in a beginning phase of a rather big project. We have layered architecture with UI, complex middle-tier that talks to a number of external systems and DBs.
We have a number of developers on the project with the same number to start in next few weeks. After initial launch I expect 50-60-70% of staff to be moved to some other projects with new (and, most likely, junior) developers taking over their positions.
Do we need a custom framework on top of what .Net provides? Yes.
Do we need a framework even if it’s going to be outdated tomorrow? Hell, yes!
Why do we need any framework at all?
1) Consistency of development process. I don’t want new starters to invent a wheel and create their own solutions. Framework can be verified, tested, performance-tested, approved by architects. Do I have a luxury of trusting every developer’s judgment on everything? Not on a large project.
2) Efficiency. I want developers to productively write code (mostly UI and business logic) and don’t worry about plumbing, validation nuances, etc.
Are we going to write everything ourselves? No. We’re going to re-use as much as we can. This brings a second question:
Adopting external frameworks. Is it good?
.Net provides a lot of stuff out of the box, however, not everything. Validation, Data Access and control library are obvious weak points that require addressing on pretty much any project. Tracing and logging can be extended way further than standard implementation in order to be really useful in n-tier systems.
So, re-use third-party or write your own? I have seen projects where everything was written in house as a principle, including reporting engine. It took a lot of time and was inferior comparing to what’s available on the market. Yes, the framework did almost 100% of what’s needed and was written with specific project in mind, but it had its own limitations, just like any other framework in the world. It would have been more efficient development-wise and beneficial to customers to utilise existing libraries.
YAGNI principle teaches us that we should not over-engineer for future as we won’t need it most probably. I think this principle is being violated more often during in-house framework development rather than during third-party framework re-use. Given a choice between utilising 20% of Enterprise Library or writing these 20% ourselves, I’m going to opt for the first option because it’s faster and does the job. I’d rather use it as a base and write a little bit of custom tweaking code on top of it when required; it’s more efficient this way. For example Enterprise Library Validation block doesn’t support cross-field validation. Fine! I can write it within the scope of my project, but at least I don’t need to write the entire validation framework.
Seriously, what’s the problem with utilising 20% of a large-ish third-party framework? After all, code re-use isn’t such a new concept.
