Tuesday, May 27, 2008

evolution of a programmer...

To Quote Edsger W Dijkstra

If something goes wrong in the field of Physics or Geology or other natural sciences you can blame the nature. But if something goes wrong with your program you cannot blame anyone but your own brain.

An IT application generally evolves like a human civilization until the technology is able to support the changes in business environment. Once technology is no longer able to support the business, it becomes obsolete.


Consider this – the application I work on, was built some decades ago using CINCOM’s rapid application development tool called MANTIS. Those were the times of mighty mainframe machines, and elegance of modern day servers and MVC architecture was only in the visions of computer engineers. MANTIS is a straightforward, down to earth tool with hardly some twenty commands and an inbuilt compiler which sits on CICS. One of those tools, which experts say can be mastered in two hours. It has no inbuilt garbage collection or exception handling, and front end is very unfriendly compared to today’s sleek and funky JSP. You have to write some 100 LOC to implement the page logic, there is nothing to scroll. There are no date operations like Oracle. What the redundancy of code means becomes very conspicuous when one looks at the source code. On and all, MANTIS is now obsolete given the pace with which business is changing. It is full of known bugs, which can no longer be fixed. So the business is gradually making a shift towards Siebel CRM. Eventually, I have to start looking for a job elsewhere.

When a new person is inducted into the application, given the attrition rate of the ambitious people, the first question s/he asks is ‘Why don’t we write the whole code in J2EE again?’ That’s a valid question, and a smart, futuristic proposition. Who wants to listen to a gramophone record in the times of iPOD nanos? But consider this – you bought a gramophone record somewhere in 70’s and since then you have been collecting the records religiously like a music aficionado. Now you have a library of thousands of records, which has eventually developed an emotional bond with you. You can’t just throw away all of them and buy one 100 GB iPOD nano and download all the songs from Apple’s music store. Business, too, has this unrealistic attachment to the obsolete applications which, though highly inefficient compared to latest technology, give correct results. You cannot expect them to shift immediately; it is a gradual evolutionary process of business transformation which promises exorbitant jobs for enterprise architects.

Moreover, hardly there will be a business which runs on a single technology. Mine, runs on Mainframes, J2EE, VB, and all of these talk to each other through another middleware technology called WebSphere MQSeries. Ideally it looks like a stupid mess from neutral perspective, but for a support provider it is a blessing. Support providers are always in hunt for bugs which they can fix to bill their clients.

Conclusion: When looking/working at an application it is imperative to understand that application is not just the lines of code or the number of java classes. It holds in itself the history of how business rules have evolved, the frustration of restless programmers, the limited knowledge of overqualified application architects and ignorance of pandemic project managers.

No comments: