18.0 Introduction

Developers love to write frameworks. There are no business requirements or users to deal with, and the complicated code that they typically require is the most fun to program. The problem is that most people who are writing frameworks are usually wasting their client’s or employer’s money (unless you work for Microsoft), for a couple of reasons:

  • Writing a framework before you write an application is similar to telling a business to collect all its requirements before you start writing an application. In the same way that the business never knows everything it needs beforehand, neither will you. Chances are your framework will include lots of functionality that you don’t actually need and lots of functionality that won’t do what you actually need it to.

  • The functionality you are trying to write probably already exists in one of the frameworks discussed in this chapter.

You can deliver much more value to your client or company by using an existing framework and tweaking it to your liking rather than trying to write your own from scratch—the source is available, after all!

If you do decide that you need to write your own framework, the best way to accomplish this is to write it while you write your application, and then at the end extract it into an actual “framework” for reuse in later projects. A great real-world example of this is Ruby on Rails, which was developed as a way to create the online service Basecamp (discussed in Chapter 13) and then later extracted for ...

Get Windows Developer Power Tools now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.