Why is it that in almost every IT company, or even every IT project, the inevitable question pops up “whether we should write our own application development framework (ADF) or not?”
Even when there probably are already more ADF attempts in the world than successful IT projects!
So let’s look at it more closely.
What are the driving forces behind the decision to go for a home made ADF?
1) Managers
- It’s cool.
Managers like the term framework. It sounds fancy without being too technical. So it’s a term they can use whenever they see fit (most of the times to impress potential customers), and look like they know what is going on in the development world. - Reusability!
An ADF also holds the promise of reusability.
When it’s ready, it’s a peace of cake to build new projects on top of it.
Just plug in the ADF, add some project specific code and yes, a new project is ready to be delivered on time, in budget to a happy customer.
Ha-ha, one investment, and the rest is just easy money! Nice. 🙂 - Standards!
We must have a standard way to do things in our company. For everything.
So also for application development. For every application, regardless the requirements. - It sells.
If the manager is CEO of a company that sells IT services, he will instruct the guys/girls from sales to mention the framework at least 5 times, in any conversation with potential customers. If a customer has any doubts, these will surely fade away when he hears about our own framework. Make sure to add some extra buzzwords like Certified, Standardized, Extensible, Modular, Pluggable, …
2) Developers
- It’s fun!
It’s fun to write a framework.
Most developers really love writing frameworks. It gives them the feeling they are the creators of life. (Yes, most developers like to speak Biblical. It’s their twisted sense of nerd-humor! I guess that’s why they like epic movies or games as well.) - Don’t trust other code.
By design, developers don’t trust anything created by other developers.
Mainly because they are convinced that whatever is created by someone else, they can do it better!
This is a dangerous quality of developers, because it is so strong it even works within companies.
=> Even a company ADF is very likely to be ignored by teams that didn’t contribute to it.
The only code, written by someone else, a developer will ever use (without being held at gunpoint), is code from some community open source projects.
So, apart from the sales argument, reusability promise and the intention to standardise things, the main driving forces are mostly irrational.
And why shouldn’t you write your own ADF?
- First of all, it’s very, very difficult. It takes some great designers/architects to make a framework that supports different scenarios and is still easy to use.
Even some community open source projects have a steep learning curve (like nHibernate) or don’t support all features your project needs.
Unfortunately, most developers/architects think they are great. But it’s more like in Matth. XXII, vs. 14: Many (think they) are invited, few chosen.It’s an example of what I call my 90/90-principle:
90% of the people think they are more intelligent than 90% of the people. - They are doomed to fail.
Usually the ADF lifecycleis like this:- Young IT company X has its first big contract for a custom development project: project A.
- It seams like a good (and fun) idea to write their own company framework for this project.
So they start with a simple framework, supporting all the features they think will be necessary for project A. - As they start developing, they detect some missing features in their framework, so they add them along the way.
- A new project is started, project B. This project has some requirements that require some extra specific features. Unfortunately, the framework wasn’t designed with these features in mind.
So they have to work around some design decisions to push these features in. Or they rewrite some parts of the framework. - But then project C starts, and it has yet some other requirements. These are completely incompatible with the framework.
But it’s company policy to use the framework, so there is no other option. This team will be fighting the framework, finding workarounds, trying to solve things using the framework in a very creative way.
At this point, company X starts losing money with the framework. Instead of reducing the development time, it’s increasing it! - For the next projects, it depends on how much damage the framework did in project C. If it ended in complete disaster, it might be dead and buried already.
If not, there is still a small chance it will be reused for other projects. This depends on the requirements, and the number of developers from the original framework team. (Remember, developers don’t trust/use code from other developers) - This moment is often the trigger for someone to propose a complete rewrite of the framework, and the cycle can start again.
- And once again: Developers don’t trust other developers’ code!
Other developers will NOT use the ADF designed by another team, unless you hold them at gunpoint.
So as you might have guessed by now, I’m not a big fan of ADF’s.
Where I do believe in, are building blocks, or a tool belt.
Small reusable peaces of code. Sometimes a dll, sometimes just one class.
Things like, for instance, a logging framework. It is in no way an ADF.
It is just a dll you can use if you want to add some logging capabilities to your project. Nothing less, nothing more.
It doesn’t have any influence on the rest of your project.
You can use it in winforms, ASP.NET, business logic classes or, even better, put it in aspects if you use AOP (See e.g. Postsharp).
And that is how your building blocks should be. Simple blocks you use to build your application.
You want logging? Just add a logging building block.
You need an ORM supporting some specific features?
Just look around and use the ORM that best fits your needs (nHibernate, Entity Framework, LLBLGen Pro or even a micro ORM can suffice).
And prefer community open source projects above writing your own block because it’s the only external code accepted by developers.
Conclusion
You don’t need an ADF, you need building blocks.
Because every project can have its specific requirements, you need to be flexible.
Never underestimate the creativity of a customer!
They are very likely to have just that requirement that really doesn’t fit into your ADF.
You might consider an ADF for simple CRUD applications, but that’s it. Don’t go any further.
A framework is like Playmobil: it’s easy to build what it was designed for. If you want to build something else, you’re stuck!
And even when the framework supports practically every scenario, it usually is so complex to use, you need special training to be able to set it up and use it in your new project.
Custom development is much easier with Lego-blocks.
Just take the (simple) blocks you need, to build exactly what the customer asked for.