Development Philosophy : The Framework approach

Warning: Long blurb about what is in my head right now
 

Ok so I have been pondering the role of architecture and its current relevance. In some organizations it is ignored in others it is a hindrance. It is very hard to measure its impact. This is a thought that came from that exercise.

Development should not be difficult; so keep it simple for the majority of things and hide the complexity. One of the key things business wants is to be more agile and get what will add business value as quick as possible. This allows them to have a completive edge over the competition. 

As for maintenance it is a hidden cost at time of development and will cost many times more than the cost of the initial development over time. This is kind of where my passion lies bringing down the cost of maintenance and upping the speed of development.

One of the tools I use to address the above is Framework based development where you don’t just provide a blueprint but a working fully functional framework for you development team to use that provides an increase in development speed and increased maintainability. 

The responsibility for the creation of the framework once tools have been decided falls to the team. You generally don’t have much choice when it comes to toolset (.Net, Java, Oracle blah) so it is best to accept it and create the best and most productive tools around the chosen technology to make everyone’s life easier. I have never come across a tool/ product which was so mature and such a good fit that no custom development / reporting etc was needed.  That custom development should take the guise of a framework for want of a better word. A set of tools, generators, standards and code that guide a developer into creating the 80% (of the 80/20 rule) of the application and that allow development to be a simple process.

Take note: The following points will take a decidedly Java flavor but you can replace these ideas in any technology.

Prototype – You start out with a prototype that proves your ideas and structure. This is a key element to any framework because it first provides the base for what will come and addresses any technical problems. Also it allows the team to understand and embrace any new technology.

Project structure – What does your application look like what code is common and how is it structured. Do you have separate teams that work on separate parts of the system? How will it be deployed? You need to address all of these kinds of questions to get the right fit for you team and how you work.

Standards – Naming standards and code usage patterns must all be documented on a wiki.

Tools – What can you create to make the developers life easier?

Build, CI, Unit tests – Imperative to set this up as part of your framework. This will allow you to test any changes to your framework with confidence.  

Persistence, Visualization etc developer tools – Object structure to abstract the complex repetitive code. Templates to allow uniformity in UI, Custom tags. This is where the meat of any framework lies the patterns an abstractions that allow for speedy development. Things like how can you have a standard interface into your model layer. How can you ensure that Bean code is generilaized enough that a developer has to do the least amount of work.

Data store – Do you check in packages and procedures and sql stuff into version control and how is this managed.

Team structure and process – Everyone should understand the framework and why documented in wiki and how the moving parts fit together. Code reviews are helpfully keeping everything on the right track.