Utility libraries

While everybody is thinking of frameworks when it comes to rapid application development (RAD) needs, my experience is (and I used RAD tools in times where nobody was talking about that and I either didn't know that it was RAD ;-) ) that all kind of frameworks draw several borders that limit your flexibility. - Well, if you look at it, the name already says it and I can't avoid thinking of a photo frame - it has a certain size and if your picture doesn't have that size it doesn't fit...

There were application development frameworks like dbase, Magic II and Microsoft jumped onto that train later with Microsoft Access - which now is the most popular tool in that realm. I worked with all those mentioned above and while I found the Magic II was the most effective and efficient framework (back in the late eightees and early ninetees) it was also the most expensive one. The Magic II seems to have evolved further and is now named uniPaaS - I have not tried it yet but from the screens it looks somehow a little familiar to me :-) .

Anyway, while working with those RAD tools in the past I was very fast creating first application versions but sooner or later when it came to particular special customer desires, I was limited by the frameworks and often had to tell the customer that I cannot do it in the desired way. Mostly I found different acceptable solutions that were ok also, but nowadays there are two important changes in IT world here:

• In former days IT was built of a lot of different isolated applications. Today everything must be highly integrated and plugable.
  
  
• Customers (or CEOs) assume that nowadays "everything" is possible in IT. So when you tell the customer you can't do it, you are out. You must be able to do it (but furtunately you have the consultants to tell the customers or CEOs that what they desire is not the best solution to their problem :-) ).

Both changes make life hard for RAD tools. My experience from the last about 15 years is that there is another - better - approach to increase development speed and still keep being flexible:

Build utility libraries on different levels

What I do mean with this is:

1. It sounds strange but every programming language lacks of very basic functions needed in nearly every application. - The best example I stumbled upon lately is that there is no one-liner to copy a file in Java. Can't be, you think? - I browsed several hours through the library documentation and searched the internet, without success. But I found several samples of ways to do it (and wondered how many options I have to copy a file...). Finally I wrote two methods with different focus: One method to copy a small file in a single step copying everything into the memory and a second one to copy a large file using a buffer. You need to build a library of very basic methods that you often need and can reuse in whatever type of application you are going to create. Try to have no or very, very few dependencies on that level.
   
   
2. Logically - as many things are already missing on basic levels - when it comes to higher levels, even more is missing. Maybe having those levels served with utility classes would result in a bloated language core. But anyway, you need this stuff - we are talking here about having comprehensive toolboxes with utilities for particular realms that are not necessarily used in every application.
   So Build several specialized libraries that offer utilities for different needs like database access, GUI building, sending/handling email, transferring data over the net and so on.
   
   
3. Having different libraries often results in more effort needed to put everything together. This is a major goal that frameworks try to solve. But if you consider the connection issue right on the beginning of building your libraries you can create your own interface objects that the different libraries on different levels know to handle. An example is to use an array or list of key-value pairs (Map) that you can pass around to different libraries so that you can receive data in such a form from the GUI library (after displaying a dialog for instance) and pass it to the database utility library to have the set of data saved to a table.
   So create interface objects and make them "well known" in all your libraries to easily connect your libraries together.

Especially when building more specialized libraries prefer convention over configuration (of your modules or components).

The big advantage of the utility library approach is that you can put things together from different levels as needed but also do things different where you like it (for instance to improve performance for particular tasks). So you have a tool set but you stay flexible.

Related post: The IDE and the libraries.