Build Your Framework On a Good Foundation

If you have been following any of my presentations at various NI events lately, you’ll know that one of my big focuses lately has been on the development process and frameworks.  I just recently inherited a project from someone, let’s call him Developer Dan. Dan taught me a very important lesson:

A framework, no matter how well it is designed, can’t make up for poor design choices made by the user.

I used this photo in my presentation on choosing a framework.  I used the steel beams of the skyscraper to emphasize the structure that is provided by a framework.  What I totally missed and what has now become apparent, is that there is something way more important than the steel framework going on in this picture.  There is a very important element of this structure that is not readily visible.  If you haven’t guessed it yet, I’m talking about the foundation.  In terms of software, that foundation is following good software design principles.

Now a good framework should already be built on a good foundation.  The developers of the framework should have thought about things like encapsulation, dependencies, SOLID principles, etc… BUT as developers using the framework, we still have to think about those things.  We can break encapsulation and add additional dependencies if we are not careful.  Then we end up with a real mess.  No framework can prevent that completely.

So don’t think that simply using the latest and greatest framework will solve your design problems.   You still have to do design. What your framework should buy you are efficiency and reuse.  You should be more efficient because the framework and its tooling do a lot of the boilerplate for you.  You should be able to get more reuse because all your programs are now following a standard structure.

So the moral of the story is don’t be like Developer Dan and don’t rely on the framework to do the design work for you. More on Dan’s misadventures in the next blog post…