Read Vs Think

The software industry has been fascinated by the idea of reusable software

components for a long time now. The earliest programmers working in assembler

and FORTRAN dreamed of having universal libraries of functions that could be

used time and again. Three decades later, thanks to the widespread adoption of

object oriented visual programming environments, this vision seems close to

becoming a reality. Has this vision worked? I don’t think so.

There are several problems with designing software with the help of class

libraries, object frameworks, or what you will. I will take up the problems one

at a time.

The continuous learning problem A modern-day development framework can

consist of hundreds of objects, each of which may have a dozen key methods. Many

programmers that I know spend a lot of time just looking up the help files for

the method they need or for information on the way a particular construct works.

One would think that learning how a framework operates would be a one-time

effort, but this is not the case. No sooner have you mastered one facet of the

library that another problem crops up. Add to this the burden of keeping up with

new releases of an existing tool or learning brand new tools and you realize why

continuing education is becoming a way of life.

Badly designed frameworks I have never met the people who design class

libraries or object frameworks but strongly suspect that they have never really

designed application software. No object ever seems to work just the way you

want it. Features are either too simplistic or too cumbersome. One can literally

spend weeks fixing the most trivial of interface problems.

Over-ambitious frameworks Products like Delphi or Visual C++ come with

frameworks that aim at encompassing everything. The theory is that you can use

the foundation classes to design everything from Internet applications to

communications software to sophisticated database applications. Unfortunately,

this flies in the face of having a small, neat, elegant, and orthogonal set of

routines in a component library.

A standards/middleware explosion New standards are being created

virtually by the day. Just keeping track of the acronyms is becoming impossible.

Development tools are struggling to keep pace by supporting every standard that

they can. This leads to a very strange situation–you may have mastered every

core feature in a language such as C++ or Java but will not understand half the

built-in classes because you are unfamiliar with the standard.

Increased programmer apprenticeships A fresh programmer now needs at

least six months with a new tool before he can be counted as a productive member

of the team. There are two implications of this fact: One, you are constantly

paying people to come to the office to learn and, two, a lot of valuable man

hours are lost in the process of mentoring.

Super-specialized resources It used to be that a

programmer was, within limits, a general resource. You could take a person and

assign him to varying projects with the knowledge that he would become

productive pretty soon. This is no longer the case. These days, to get the most

out of a programmer, you have to assign him more and more projects in the same

environment. There are serious repercussions on cost; you may have to hire more

people despite having idle staff because the existing staff has specialized in a

different environment.

Is there a simple way out? I, for one, don’t see much

improvement in the short run. It is only with the due process of time that

development tool vendors will begin to understand the diminishing returns in

providing too many features.

The bottomline Information overload is the single biggest factor that must be

addressed by software development houses today.

Gautama Ahuja, a contributing editor

of PC Quest, runs a turnkey software development company, AHC Infotek, in Delhi