Article: Battle of the frameworks »
FERDY CHRISTANT - JUL 1, 2008 (08:43:37 PM)
New frameworks and components are arriving rapidly. It's quite a jungle out there...
In this article, I will not tell you which framework or component is best. Instead I will share my experience in working with frameworks, selecting them, and sometimes even building them. I've witnessed both success and failure with frameworks and will therefore focus on what worked for me and what didn't. I will use the term "framework" loosely, it can be a full framework covering many application development needs, or a single component or code generation template. In the end, their purpose is the same: improving the software development process.
Why a framework?
The reasons you would use a framework are quite obvious. Still, it is good to review them and keep them in the back of your mind at all times. Consider them to be the requirements for selecting or building your framework. You should not use a framework to be cool, instead you should use them for a business reason. The primary business reasons for any project, IT-related or not, are typically:
- Lower costs. Through code reuse, code generation, and tooling, developer productivity increases. Another cost-saving factor is that frameworks typically result in consistent application architectures, making it easier and thus cheaper to maintain them.
- Decrease time-to-market. Directly related to code reuse and code generation is the shorter time to market that is accomplished by the increased productivity.
- Increase quality. Code reuse, consistent architectures and code generation can contribute, but not guarantee, to higher quality code, which in turn leads to less defects and costs.
In addition to these primary reasons, other advantages may apply:
- Predictability. A good framework can utilize a factory-like approach of software development, leading to a higher predictability of deliverables, better planning and happier customers.
- Scalability. By carefully selecting a proper reference architecture, you can make sure all your applications that are based upon the framework are scalable.
- Consistency: in deployment, maintenance, logging, security, documentation, etc.
Suffice to say, there are a lot of advantages in using a framework.
Every framework and situation has a set of characteristics that determine the suitability of a particular framework for your situation. Whether you buy, build or assemble your framework, these characteristics ought to be investigated in order to come to a proper choice. The list below shows a number of important characteristics, but is by no means complete.
- Organizational scope. Are you planning to use a framework as a single developer on a hobby project? In that case, you have a lot of freedom in selecting a framework. Or, are you selecting a framework for an entire department or even enterprise? In that case, a lot more characteristics apply. It is key to know who the framework users will be and what their key needs and characteristics are.
- Technical scope. What kind of applications will be build with your framework? Frameworks are typically optimized for a certain type of application in the same way that a factory is optimized for a single product. There are frameworks where business logic is key, and some where business data is key (domain-driven versus database-driven). Will you build intranet or internet applications with the framework? Or perhaps even desktop or mobile applications? The smaller the technical scope, the more effective and explicit your framework can be. The larger the technical scope, the more loosely defined it should be.It is quite tempting to select an advanced, sophisticated all-round framework, but I can tell from experience that it will fail if all you need to build are simple applications.
- Framework size. This characteristic is not to be underestimated. Most developers prefer to develop close to the core platform and not be limited by a huge framework that restricts them in being productive. You should be skeptical of large frameworks, they are hard to maintain, learn and sell to developers. The larger the framework, the more choices the framework has made for you. Exceptions will always occur however, and developers will need to work around the framework's choices many times.
- Flexibility. This relates to the previous characteristic. Frameworks that inflict an inflexible architecture upon developers is likely to fail, for various reasons. First, there are always exceptions to the architecture, making it painful to work around the framework. Second, while you are using the framework, the industry continues to develop and parts of your framework will become obsolete. A good framework is loosely defined, allows you to plug in your own components, and even allows you to swap entire layers of the architecture. For example, Code Igniter, a PHP MVC framework, allows you to do classic SQL data access, or a full-fledged ORM solution, like Propel. Likewise, you can choose which template engine to use and plug in your own components, libraries, hooks and helper functions. A great example of a flexible framework. Flexibility and extensibility will also increase the buy-in of the framework towards you developers.
- Learning curve. If the learning curve of your framework is too high, all else fails. I've seen this happen to a very advanced framework with awesome code generation technology. The framework was great, and had huge potential for success. Even though it would take a new developer only days to learn it, it failed. It was considered too hard to learn, non-intuitive and too different from core application development. This concerned a situation in an enterprise team, where all kinds of resources worked: payroll, local timehires, offshored, interns. In complex situations like this, use the lowest common denominator: your framework should be easy to use for all, including the new and inexperienced. Looking back at the situation, I'm still surprised. In my perception, the framework was not that complex at all, and fairly standard. Still, I learned a valuable lesson: keep things as simple and standard as possible.
- Support. This one is kind of a no-brainer, but worth mentioning nevertheless. If you use an open source framework or buy a commercial one, it is obviously important to know what weight is behind the framework: is it supported? Is it a one-man show or an active community? Will the framework be around three years from now? Is there a roadmap? Are bugs being fixed and are there new releases regularly?
- Compliancy and Interoperability. Does the framework comply with industry standards and your own standards? For example: in your company you may have a company stylesheet, a particular authentication mechanism, a company portal, or a SOA service repository you need to integrate with. Is the frame flexible enough to allow you to build towards company-specific standards? What about security and accessibility standards?
- Cost. A framework is not without cost, even though its purpose is to reduce costs. Consider the cost of acquisition, training, maintenance, communication and more. I've seen an advanced framework, a combination of public and self-developed components fail in this aspect. The promise of the framework was high, as were the adoption costs. Although it saved time in each project, the total costs of the framework were higher than the benefit made across the projects. Do not underestimate the costs of a framework, they do not only lower it.
- Architecture. This characteristics relates strongly to the technical scope. In other words, what kind of applications do you build, and which architecture applies best to it? This is a tough cookie to crack. In a framework selection round, I once asked three major suppliers to come up with a reference architecture for ASP.NET applications. All three independently came up with a similar architecture: one with four or five abstraction layers. In hindsight, all three were wrong in that they were proposing a reference architecture for enterprise-scale applications, whilst in reality we were building simple data-driven web apps. The point: there is no single architecture for all types of applications, architecture needs to scale towards the type, size, complexity and nature of the applications you build. I've learned the hard way that less architecture is also architecture. A quick tip to avoid making the same mistake: for each layer in the architecture, make a business case. What is the business benefit of tha layer, how likely is it that you will have to change that layer in the future? Make the case real and explicit, instead of relying on the personal technical preference of some architect.
- Buy-in. Developers typically have strong preferences for the way they develop an application, by deploying a framework you are touching the heart of their daily work. Therefore, you cannot simply dump a framework on developers, you need to sell it. Explain how it makes their life easier, why you're doing it, how they can learn and contribute to it, how this frees up time for them to focus on innovative parts, etc. If developers do not truly accept the framework, it is likely to fail.
We've now covered some selection criteria for frameworks. Beteen the lines, you may have noticed some best practices. On the other side, there are also worst practices. Here's what I've learned to be worst practices and pitfalls in using, assembling or building application development frameworks:
- Not invented here syndrome. Please, by all means, keep the amount of self-developed code in your framework to a minimum. The larger the codebase, the more you need to maintain, document, train and carry around. Use public components and public standards as much as possible. Only provide custom components for business-specific aspects. The principle "as default as possible" applies.
- Speed of innovation. Frameworks come and go. This is why you need a light, flexible framework. Otherwise, major parts of your framework will become obsolete as technology progresses. Example: We once invested a lot in a ORM solution with custom code generation for the mapping files. In the meanwhile, the platform has a native drag-and-drop ORM solution that is intuitive to use and considered a standard approach. We did not earn back the initial investment for the custom ORM layer, as technology caught up, and we did not have the time to benefit enough from it in projects. Now, the custom solution is obsolete.
- Learning curve / Simplicity. I have stated it before: keep your framework as simple as possible, or better said: as simple as suitable. Simplicity will beat sophistication every time. Make sure your framework is intuitive for developers, and close to regular application development. A simple and obvious tip is to let developers participate in the framework acquisition process.
- One framework to rule them all. The larger the scope of your framework initiative, the less likely it is that you can come up with a framework or architecture to serve all stakeholders, unless your framework is loosely defined, standard, and highly extensible. A rigid, all-or-nothing framework cannot cover various application types.
- Developer religion. The selection of a framework can lead to emotional discussions between developers, architects and the like. Avoid these non-constructive discussions of personal technical preference and mindset. Instead, challenge all to come up with business reasons why a certain choice is better. Architecture and frameworks exist to serve the business, not the techical commander in chief.
- Versioning. A bit of an operational issue with frameworks concerns versioning. First, how will you version a framework if it is made out of several components. What happens if I release a new version of the framework? How will I release version-specific documentation or templates? Is it possible/required to upgrade existing applications to the new framework? How will the support organization handle multiple versions of the framework across applications? How do I apply bug fixes to multiple versions of the framework across applications? Versioning is complex, and there are no easy answers. The important thing for now is to be aware of this and to design a plan to handle the above questions.
Framework design/acquisition principles
In summary, here's a short list of keywords to look for in your selection of an application development framework. A good application development framework:
- is "as default as possible", close to core application development.
- is loosely defined, allowing for exceptions, extensions and customization
- uses convention over configuration
- is agile and simple to use, learn and deploy
- is backed by an active community
- is well-documented and supported
- delivers on the business promise (costs, speed, quality)
I will end this article by listing a few suggestions on how you can successfully deploy a framework in an organization once the selection has been made:
- Supply virtual machine images with the IDE, framework, related tools and examples all installed. This way developers have a ready-to-go environment that lowers the barrier for trying out the new framework.
- Provide developers with self-service training material. A good practice is to supply online videos that walk through the development of a simple application using the framework.
- Provide developers with a reference application. The reference application is an example application that is built using the framework.
- Encourage everyone to contribute to the framework:
- by having the documentation in Wiki format
- by giving everybody full access to the source code
- by having a component repository where developers can add their own components
- by rewarding top contributors
I realize this article is a bit messy, but I hope it helps you in avoiding some of the pitfalls of application development frameworks. Please leave your feedback in the ratings and comments section.