TonyBibbs^2.0

I was at a local PHP User Group meeting last night and there was a fantastic discussion around frameworks. I'd been inclined to go to this meeting because it is a topic I'm intimately familiar with. However, by the time the meeting was over I'm not sure the real value of using a framework was touched on. Shame on me. So here it is, one lowly software guy's view on frameworks and the real value they have to you...a developer trying to simply find a way to get work done.

What nobody seems to want to talk about is the fact that frameworks, be it in PHP, Java, .NET or even Python, have a bunch of valueless rhetoric around them. Their value is often discussed in terms of coolness and how easy it was to learn. If you are talking to a manager-type, balding, high strung, concerned about his or her budget you will quickly learn they could care less. Their focused is on the business. The bottom line. Achieving results. So let's talk in tangible terms on how a framework in any language should be evaluated and how it directly addresses the needs of the business.

No talk about the use of a framework, or programming for that matter, makes any sense without having a software development process (SDLC) in place. I always hear people talk of how frameworks can give consistency to the quality of software produced which is true. However, if you have a crappy software development process then all your new, cool framework will do is ensure you can consistently produce crappy systems. Ah, but see, nobody talks about the SDLC anymore...why? Because it's extremely boring, it's opposite of cool and let's face it...developing a good SDLC is hard, glamor-less work.

So let's assume for a moment you have an SDLC or you plan to work towards establishing one. So what is the goal you've set for your new framework? In my world, the rock-star life of a public servant, the goal is to commoditize the software delivery process...make it operate much like a automotive assembly line. That's right, software delivery isn't an art. It's a thing, a widget, and should you fail in delivering your quality widget on time, it will produce a long line of other vendors waiting in line to take your business. To put it another way, don't overvalue the task of programming.

Now let me put some perspective on this so-as not to completely strike a nerve with every developer reading this. I'm responsible for delivering critical software to government entities. No, it's not near as much fun doing some ajaxified social networking site or innovative mash-up. We're talking *boring* stuff, stuff like ensuring restaurants get inspected, that health facility workers are qualified, that your doctor gets adequate continuing education and managing the location of sex offenders. While I know that vision is far from grandeur, it's a very important job and one I take very seriously. So the last thing I want developers doing is spending a considerable amount of time playing with the new, hip framework on the market. I want them concentrating on the business requirements and finding innovative solutions to the business problems at hand. How do we do this? By making the process of programming as straightforward and trivial as possible.

Ok, so back to frameworks. The number one quality of a good framework is the time it can save your organization...not over the first one or two projects that you use it but over the lifetime of the framework. Take any framework...PRADO, Spring, Symfony, CakePHP, Rails and before you start coding estimate what it would take using conventional code. Then go off and produce that first project using the framework you picked and you'll find one very striking fact. The first time you apply a framework to a project the cost will likely exceed your estimate by around 20%. Why? Well, there is the ramp of getting all the developers up-to-speed on the framework, the time developing best practices, integrating unit testing, planning for the first ever deployment, etc. There's a lot bruises you'll take on that first go round for sure. To the untrained eye of a manager trying to meet business objectives this could be looked as a waste of time. The frustrations of using new technology often has the impatient developer or software architect looking for a new replacement. What a shame!

See, because what will happen on that second pass is you'll be more efficient. Your framework, if it is any good, will speed up your software delivery process. First you'll recover that 20% you thought was wasted on the first project you tried. Then you'll find more efficiencies and before you know it you'll be saving money. Not on just one project, but on each subsequent project. The value of a framework is proportional to the amount of time it saves you over the number of times you use it unchanged. My point, once you select a framework be willing to stick with it and be sure you are adequately collecting the metrics needed to assess it's value to the organization.

So now that I've covered my number one point let me run down a quick list for assessing a framework you may be looking in a way that has quantitative value to your business:

1. Does the framework fit well with your SDLC? Do you even have an SDLC?
2. Does the framework save you money over time? It better and if you are switching frameworks like the funky socks on your feet you better re-evaluate what you are doing
3. Does your framework allow your better developers to excel and innovate new ways to address a business problem? If the framework only handcuffs your better talent you may find keeping them around near impossible.
4. Does your framework keep your not-so-good developers performing at an acceptable level. Sure, you shouldn't have hired a dud in the first place but if you did and the developer can at least write code and follow directions they should be able to positively impact your project plan
5. Can you iteratively improve your framework. There's a lot of all-or-nothing frameworks out there and if you can live with the constraint of doing things how your vendor tells you then more power to you. For me, if I can't swap out key components like, say, the MVC implementation or the ORM to take advantage of better technology then the framework lacks any real luster.
6. Can you choose not to use parts of your framework to work around performance bottlnecks? As an example, some frameworks don't even give you the ability to issue raw SQL to the database? Using tools like an ORM adds a layer of abstraction that slows performance and sometimes you will need to squeeze out every bit of performance you can. Your framework should facilitate this, not hinder it.
7. Finally, do you even need a framework? If you are building a system with only a handful of screens to address a really small problem do you want to eat the setup and implementation time of your framework when you could have been done hours earlier with a bit of time, some coffee and a blinking cursor in your IDE?

Don't get me wrong, I advocate the use of frameworks but the industry buzz around them is deafening and the real value of a good framework has been lost. Our basic framework has been in place for nearly five years now, before Zend Framework, before PRADO, before many of these other new and cool frameworks were even stable. Is it the best? No, but it address our list of issues above and has allowed us to successfully deliver quality systems to our customers on time. And, simply put, that's what I get paid to do.