Your Framework, Probably Won’t

It has happened to just about all of us. Your customer has a requirement X. You recognize that you can satisfy X as well as Y and Z and innumerable other needs that you are certain will be the the customer will have in the future easily if you just build the proper framework. (Please take a moment to appreciate how useful it is that you can see the future).  It’s a satisfying feeling. You’ve taken the whole project up a level. You are writing code that is useful to both you and your customer. You are flying high (while still taking care to stay below the stratosphere). This is what software development is all about.

There is just one problem. There is disappointment in your future. Maybe for you or maybe for your customer but probably for both of you. Odds are your framework won’t actually do the job. Either your customer is stuck accepting compromises in their needs for the software because the range of achievable functionality is constrained by the framework. Or you are forced to make nasty compromises in the framework and code in general because the customer holds fast and demands the functionality that they actually need despite what your existing framework easily supports.

As Jeffery Palermo says, creating frameworks and libraries is very satisfying to developers because you essentially get to be your own customer.  However, frameworks and libraries are also some of the hardest code to get right.  I have seem many fail with this same pattern.  I’ve written more than I’d like to admit that failed with this same pattern.  If you write the application that your customer needs you will get the satisfaction of delivering working software that enhances some one’s life or work.  If you do spot a repeatable pattern in functioning software that can be used elsewhere than by all means extract it and create a reusable framework.  If you try to build the framework first you will probably find only disappointment.