Frame-of-our-work

Working with a software and repeatable tasks, teams walk form a hard-coded solution to a generic framework and back with confusion. Let's search for the third way.

Table below presents some attributes of those two types of approaches:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Frame-of-our-work

If both of extremes are wrong what is the third possible way? This is: don't build THE FRAMEWORK. Build THE FRAME-OF-OUR-WORK instead. Please, pronounce these two words: framework and frame-of-our-work. I am serious. So now:

• What a responsibility do you you put on framework and frame-of-our-work?
• What is possible to do with framework and frame-of-our-work?
• What is impossible to do with framework and frame-of-our-work?
• What would you give up changing a focus from framework to the frame-of-our-work or opposite?

You know, naming is important. When you label a project you give a team the direction of work and it determines what kind of work will be done or undone. Focusing a team on building a framework you are at lots of cognitive biases. A framework word is so imprecise that you may do more work than you intended to. Besides we do really like to build frameworks - check Source Forge or Google Code :).

Frame-of-our-work focus you on what are we really doing now? You need to inspect tasks a team do, before you start building a frame-of-our-work. This is nothing but Single Responsibility Principle.


I put a characteristic a frame-of-our-work into the table:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
frame-of-our-work	fast	easy	needs some work but it's acceptable	it's sensitive on rapid changes of business processes because it's highly coupled with them
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Although a frame-of-our-work is not so sexy as a framework does, my observation is the cost of redesigning a frame-of-our-work is mostly lower than the cost of maintaining a generic design of a framework.

A simple example

You build desktop application and you search for a good way to implement the GUI logic. It's not trivial in Java:) Focusing on framework you might decide to implement a generic Presentation Model with fancy widgets binding. This is very flexible solution, but...what kind of flexibility do you really need in your project?

On the other side, building a frame-of-our-work you might decide to prepare very simple Presentation Model where you have one stupid POJO per one user screen.

Both are well known approaches, but the difference is how much work will be done.

At last...

What if you really discovered a generic domain and a generic framework would be very useful? What then? Fork the project, find a sponsor in your organization and build the framework. But never ever build a generic frameworks as a part of your regular workflow.