Today at lunch, I had a conversation with Kevin Hurwitz about developer tendencies.  Kevin related a project he consulted on.  He came in after over a million dollars had already been spent by the client, and he found the following:

• Not a single feature had been delivered (save a few half-finished screens)
• The team had spent all the time creating an application framework that, when finished, would make the application practically create itself.
• The development manager was the one who instigated the framework frenzy, and was eventually fired.

Clients typically engage us for actual software.  A client isn’t interested in software that can be used to create software (frameworks).  They have a problem, and a software system can help them solve the problem. 

I, along with Kevin, have encountered the common mindset of falling from application mode into framework mode.  I find it’s common with really smart programmers who take pride in their technical ability.  Creating frameworks is fun because the programmer is the customer of the framework.  Writing software for yourself can be more fun than writing software for someone else.  Writing a framework is writing software for yourself.  On a client’s dime, this is typically not acceptable. 

The customer needs to see the software come to life before his eyes.  Every week, the customer need to see new features working. 

Playing devil’s advocate:  _If_ it were possible to create the magic framework that would make the application practically write itself, communication is key, and it’s a bet, a strategy, an approach.  If this were possible, and you’d successfully done it time and time again for many clients, then it should be discussed with the client beforehand.  Ultimately, the framework becomes property of the paying client, so the client ought to know what is happening, and the client needs to be ok with it.

Back to reality:  Frameworks are better harvested from several applications that ended up using similar patterns.  Writing a framework before an application is BDUF (big design up front).  There are so many assumptions that go into the framework that some of them are bound to be wrong.

The real, repeatable satisfaction.  With many programmers preferring framework development, a client-centered process can bring joy in working on the client’s application.  Delivering new builds of the software frequently will please the client, and that level of customer service brings satisfaction back the other way.  There is nothing better than an elated client who loves what he sees unfolding before him.

What about all the common junk that the application needs?  Chances are that there are already libraries that satisfy your needs.  Data access. logging, authentication, caching, indexing, builds, UI controls, etc.  There are both commercial and open-source offerings that make great buy vs. build decisions.  For the needs that don’t have offerings yet, do it first, then when the exact same need comes up again, it will be easy to create a library that satisfies this common need now that you know _exactly_ what the need is.  Then, the library or framework can be created _without assumptions_ because you have experience to back up the uses.

For more, you can subscribe to my feed:  http://feeds.jeffreypalermo.com/jeffreypalermo