The Open Source movement

Economic crisis seems to boost the demand for Open Source solutions, at least if you look at the news, blogs and articles in magazines.

For me it seems as one of those keywords that is put as headline to IT fares, like DMS, CMS, ECM and others in former years.

On important thing I notice is that even IT people often do understand: open source = free - This is not necessarily the case. Open Source means that if you get the product, you also get the source. That open source = free only applies for software that is licensed under GPL or the like. Especially now as open source topic is on the hype, many companies search for a way to put that keyword on their sites so the get found and so I stumbled upon a lot of open source products that cost a big amount of money to own.

Today I had a look at Google trends comparing search terms "free software" and "open source software". Surprisingly for people it seems to be important to be free and not to be open source. - Although this is a sample that market analysis often not fit real world. In this particular case I think the difference here is because of the private users that do search just tools for their own use and they know that they will not go to hack into the code (besides those who either do not know what open source is).

Although open source is a very good thing, a company thinking about to use open source alternatives, should ask the following questions:

• Will I ever hack into the code or let others hack into the code to apply changes or will I just use the product as it is?
• Do I want to heavily rely on the product?
• Is there a long-term future for the particular product I am thinking of?

From my point of view Open Source supports long term IT planning and investment. It gives you the opportunity to support, fix and adapt a product to your needs even if nobody else is using it any more. This gives you somehow an independence from market evolution.

But there are some concerns:

• It might be a big effort to implement the Open Source product - this might come along with high costs for buying services from other companies who will install and/or support the product.
  
• If the product is not well documented and the code is not clean enough then there can be a huge effort necessary to do code changes.
• If there is no company behind doing the main development and support for the product you do not have anyone to blame or take into charge when you have a serious problem with the product.
• Depending on the community it might happen that the product evolves in a direction that creates incompatibility with your own changes.
  
• You may need to have the manpower and knowledge for developing the product in-house (depending on how the product evolves over time).

So Open Source includes no guarantee to be cheap or to exist for a long time. But it gives you the opportunity to do everything yourself and with a large community the chance is higher that you find people who have knowledge on the product.

Related posts: IT investment, Economic crisis and IT, IT project costs explosion, The License keys, Paying for free and Open Source, The Open Source idea, The community, Ignorance of the different, Microsoft & Skype.

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.

IT Outsourcing

Outsourcing of IT services - especially software development - has been a very common behavior of companies. We can either see separate outsourcing of support so that you have finally a local call-center with a lot of students just picking up the calls and taking notes plus software development very far away in a very cheap eastern country.

I never really understood the big benefit of outsourcing as there are serious drawbacks on the other hand like

• Know-How is pulled away from the company.
• Communication channels get inefficient (e.g. several people involved while nobody is communicating in mother tongue, physical distance, different time zones, ...).
• The cheaper employees often do have less qualifications.
• Cultural differences may introduce additional obstacles during the collaboration.
  

One major fact, that companies should understand: Good software developers are difficult to find. You can find a lot of cheap coders, but there is usually a difference in the output quality (clean code, sufficient comments, good component design, ...). This applies for other IT services also but especially for software development.

Outsourcing can make sense under the following circumstances:

1. There is a clear and compact technical specification of what to implement.
2. The project is smaller and/or not to be tightly integrated into a lot of other projects.
3. Few dynamic adjusting of the application at the customer necessary (so the far away from the customer the better suited for outsourcing).

I have experienced that the time from the need to the finished implementation of a solution is much shorter, when development is moved towards the customer (so doing the contrary to outsourcing). The response to changes in the priorities and goals are much shorter - even more, if there are no consultants in the middle. From the productivity point of view the direct connection from the developers to the customers is the best - but attention: There are prerequisites and pitfalls:

• For a developer that is in close contact with the customer there are more qualifications needed than just being a good coder and being a good software designer: There are communication skills, project management skills, understanding for the business point of view etc. necessary.
  
  
• The biggest mistake that is made often at this point is to act faster than to think! What I mean is, that both sides should think double before ordering and implementing a change request.

While in big software projects (or in big software companies) often the progress of development slows down massively, in very small projects and companies often there are shortcomings in software design.

Related posts: IT project costs explosion, The features, The small software vendors.