IT's NOT rocket science..

Well, all you there in the IT world. Just understand that it's not rocket science. I am not trying to discourage but that's the truth, and sooner it is accepted the better it is. Here simple layman ideas find a better place because the people you are serving don't like rockets and scientists. All they are interested in is 2 + 2 = 4 and NOT how it is calculated. And when time budget and resources are burrying the projects and your tired IT arse further down in the ground you don't think about rockets, you think how to escape.

It sounds sh** but I am talking from my experience. So we are going through a data migration exercise and we have to migrate addresses from one system into another. And in the source system the addresses are present in free text format which can hold 4 lines and 160 characters in all. But the target system accepts the data in a particular format - Street in one field, Building in one field, Town, Region, Post Code etc etc - and can hold only upto 120 characters. And no existing functionality had to be changed in the target system. So these sources addresses had to be formatted and accommodated in the target format.

And since the source addresses were free form text and users being ethnically, psychologically and emotionally different, each of those 20,000 addresses had their own way of being written there.

So yours truly thought why can't we clean such addresses and migrate them across to target system by automating the cleaning process instead of asking the users to clean the whole data. I thought like a rocket scientist. While entering an address how a person usually thinks? He writes city the last, before that street, before that building and before that first line of address like c/o So and So. Oh no. There can be just two lines of address also, not necessarily all the lines will be present. Wait, some lines may be more than 30 characters, some more than 20. Some lines will have explicit house (Flaunders House, Westminster House..) or street (Fleet Street, Dame Street, Park Road..) phew!

And so I started building this cleaner routine in REXX and the code kept on becoming fatter and fatter. At last out of those 20,000 addresses this routine cleaned up around 90% of the addresses. Phew! I thought this will be my magnum opus of this year. Two days before production rollout, business users tell me - we are not able to map the address of source system properly to the target system. I said what the f*** (in my mind) - that may not happen always because addresses are not structured properly and need lot of readjustments before they are migrated across. They say - no, we want one to one mapping because our dim brains cannot understand what you are talking about. Somehow, we escaped saying "You didn't recognize this during UAT and previous testing sprints, now suddenly you are waking up from your slumber when we are two days away from going live. We cannot change code at this stage and this has to go the way it is now." We had to hold them on ransom and get them to accept it the way it was.

But it triggered in me a thought that we shouldn't really think so much when it comes to data migrations. There should be one to one mapping. Forget about intelligent address deciphering routines which might have taken inputs from psychology, ergonomics, ethicity or even evolution. Ultimately what matters is your audience should understand what's really happening.

It's true. Because now when I look at my magnum opus, I myself cannot understand what it does!

Keeping the logic simple and understandable is very important, so that in future if someone looks at the code things become clear in just an instant. That's the reason, I think, someone once said - it is very easy to write in difficult words, but very difficult to write in simple words.

the text book strategy...

It's been long. I could not understand what to write. When mind is so obsessed with thoughts NOT related to work, then nothing can inspire to write about work. Today, somehow I have shrugged away all laziness and insecurity to try to discuss the basic "don't" of the IT industry which everyone knows at finger tips but still does not follow when it comes to it.

Here is a real life example of a project during its definition phase when the manager from client side asks the manager from vendor's side: "...I would like to know how you will mitigate against the risk of getting to mid August for the start of development and delay to development completion." And the manager (vendor) had this idea in mind - "We will put more resources (people) in case we see project getting delayed."

True story and a typical text book situation.

First of all, if the definition of the project has been done with earnest thought and sensible facts, then such questions MUST not arise. Goal of definition is to understand the need, scope in the possibilities, scope out the undoable tasks and estimate the design. Definition gives a foundation for the start of development.

That does not mean that post-definition the risks are not present. There are known risks for which already there should be a plan in place. Also, there are (sometimes) unkown risks, which arise during the later stages, for which mitigation plans have to be improvised using experience.

But here, the question is - in case the project is getting delayed can adding more resources (people) to it accelarate the progress of the project? Text books always say 'negative'. But I think, it cannot be generalized for every situation. In some cases, it might work depending upon what is delaying the project and which area of the project will be supported by the newly added enforcement. The strategists and leaders have huge responsibility for the success of it in any case.

old is bold...

Young Indian IT professionals prefer to get into Mainframes because there are more chances of getting relocated to the client locations and harvest pay-checks in USD’s or GBP’s. But at the same time they are paranoid that their skills will become obsolete soon because one day distributed computing will take over Mainframes. Also, they have this notion that there is no real development work in Mainframes; most of the tasks are maintenance and support. Real development work now goes into distributed or open systems platforms. Is it true that Mainframes is dead or it is dying a slow death?

No. Mainframe is not dead, nor is it dying. To the surprise of all, it is coming back with a new look. It is resurrecting. This article and there are many such essays evangelizing the come-back of Mainframes. Only problem with mainframes (when viewed from programmer’s perspective) is that they are not very docile for the application development. But when viewed from a CIO’s eyes, Mainframes are around 80% cheaper than distributed systems (Total Cost of Ownership) and at the same time very efficient to handle heavy workloads.

It’s true that organizations are trying to modernize their old business critical applications. And in doing so, many of the antique applications are getting re-written into distributed platforms. IBM is investing a lot of time and money in reforming the Mainframes and has already done a lot to bring z series. New AD tools are being developed to ease the application development on Mainframes. One thing to keep in mind here is that applications developed easily might not be the best applications developed.
Meanwhile, change is around the corner. Truth is 'old and weak perish and new and strong survive'. Mainframe is old, but it's strong and has a bright future. But there will be changes in its core working style, which hopefully, will be for the good. As a wild guess, there will be new cocktail architectures – Mainframes and Java, Mainframes and Linux, Mainframes and Eclipse etc. Now, it is up to Mainframe professionals to align their career path with the changing Mainframe environment if they plan to thrive along with the changing times.

whither the Indian IT...

Let me open my mouth with a defensive cliche 'life doesn't like straight lines'. Young, restless and 'virgin' Indian IT professionals are making their way into the new world - which also cannot be in straight lines. This global osmosis of talent, skills and potential is happening slowly - and will remain invisible to the eyes until one day it explodes forth an abrupt result (something like information technology Tsunami) which touches every corner of the latent dice. Until then we can only be part of the change and hang on a little more.

James McGovern has written an inciting blog (thankfully on my request)which gives great insight into current IT scenario in India. It is a must read for every Indian IT professional, in or out of India; especially at the time when yearly appraisals are on along with rising inflation and slowing GDP growth in the country.

why managers...

CPU’s now run at millions of instructions per second. Size of primary memory has increased manifold. New tools, IDE’s have arrived to reduce the involved human effort. But still, IT projects go on as if eternity has their names written on it. IT projects are no longer as much about the technology as they are about people. When it comes to an IT project - people plan, execute, control and hang around without any purpose. People are the primary bottlenecks in a project which keeps overshooting the planned schedule.

Someone overslept in the morning, did not take bath, missed the bus to office, did not have proper breakfast, someone got late because she had to drop her kid (even worse kids) to the school, someone is struggling with the extra alcohol of previous night – and they are supposed to balance another important aspect of their lives – work. No doubt when there is a conflict between work and non-work life, non-work life takes precedence in most of the cases and consequently work suffers. In a way, people don’t suffer as much because of work as work suffers because of people.

People have now become the most conspicuous bottlenecks in the projects. Interdependency of a project upon different teams, different groups and different skills has gradually distorted the uniformity and smoothness of operations. Coordination between such islands of information/operations remains a challenge. Understanding the goals of every group is a challenge in itself and it represents most of the time actually spent during the project.

There comes the need of a charming handsome gentleman or a beautiful articulate lady to smooth the edges and bridge the gap between the otherwise isolated islands. There is a saying in Chinese that ‘if you don’t have a smiling face, don’t open a shop’ which can be rephrased for the present times as ‘if you don’t have a smiling face, don’t even think of becoming a manager’.

P for Process...

Processes are, by definition, the set of rules or standards put forth for smooth operations of a business to achieve desired results. There are bulky documents in every organization containing religiously written texts dedicated to processes. But, the question every process document fails to answer is ‘Why the process should be followed?’ And if this question is coming in the mind of a person who is supposed to follow the process, then it is a sure sign of a budding scepticism that, if left unanswered, can be detrimental for the organization in future.

The standards set by the policymakers of an organization, at any level, are delicate rules of organizational ecology. Meaning, for followers, these standards are not as undeniable as the law of gravity or the laws of motion. Reason - these standards are set up by the rationale of human beings and are very prone to becoming obsolete with changing business practices and within a very short period of time. The law of gravity never changes – so there is no problem following the law, every creature is born with the instinctive acceptance. Just imagine if the gravity was 9.8 N one day and the other day it changed suddenly to 6 N, how much effort it will require for the whole creation to adapt to the new law. Thank God gravity is intact but that’s exactly what happens with business rules; they are prone to fast changes. And changes in business rules give rise to changes in processes.

Process is an essential part of everyday life – be it making chicken curry or launching missiles. For a novice cook, it doesn’t matter whether she puts onion in the hot oil first or the asafoetida. But for a seasoned chef that does make a difference in the resultant taste of the dish. That’s the effect of processes – they reflect the maturity of the profession. But sadly maturity cannot come just by labelling it to the job titles of the professionals. It has to take roots in the vision of the individual, only then can it become meaningful for the individual as well as for the organization.

In words of James McGovern:

I believe that process is intended to "raise the floor" - that is to elevate the minimum acceptable standard across all participants. The process itself is designed to create an output of a particular (acceptable) level or quality. Process is also good for consistency.

Competence is about "raising the ceiling." The upper threshold of what I can achieve is dictated by my competence. As per above, my incompetence can be offset by process (to a certain extent). People of high competence may want to resist process, because it brings their execution down to a lower level than what they are capable of delivering. This creates the tension of "do I have to follow THAT process?"

Process is an organization-wide solution. Implement once and it touches all people (or is supposed to). Competence is an individual-wide solution. It is implemented one persona at a time. This makes it much harder to manage...

poor programmer...

Problem with the application programmer’s job is that no matter how hard I work and how smart I am, I can never become a mass celebrity or win a noble prize or a Bharat Ratn, Padma Shree or Padma Vibhusan. I am the meek supporter of a bold economy. I am the wistful spectator of a celebrity world.

I mean, a programmer cannot reach out to the people of this world. A journalist writes an article and hundreds of people read it and make opinions about the world. A programmer writes a program and nobody but the compiler understands it, and years later if someone actually dares to go through the source code (which is like the junkyard of a programmer's irrational thoughts), the poor programmer’s soul gets all sorts of critiques and curses, whereas a journalist receives the Pulitzer Prize for his years of service to the world, or even gets the Best Critics Award of the Year!
In a group of people of different professions, a programmer appears like a laid back citizen of an undeveloped world, an unevolved civilization. That’s the problem with the world of programmers. We don’t have role models. If one wants to become a great journalist or a sportsman or a politician s/he has role models like Thomas Friedman, Christiano Ronaldo and George Bush. But if one wants to become a programmer – there is nobody, everyone is on his/her own on the road to perdition.

But it is good for unambitious people who don't seek fame and celebrity status, those outcast self proclaimed geniuses who want to live unknown to the world of natural human beings and go as the tiny footnotes in the pages of history.

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.