quick and dirty...

I am currently a small drop of tasteless technical skill in the large ocean of strategic migrations. Among big waves of business process analysts, programme managers, solution architects, implementation managers and project managers, I exist as a tiny insignificant and expendable ripple that’s called a developer. By a random divine decree, which some people call fate and others coincidence, this tiny wave got a chance to whirl along with big waves and behold the glory with which they exist in this corporate valley.

Data cleansing is an important part of any migration exercise. It’s like letting go of the old and useless, and adapting to the new and useful. Migrating from an old technology to a new technology, from an old business model to a new business model always requires data cleansing to be performed on the source data.

Some of the data currently under the scope of migration needs to be migrated ASAP because it has intricate dependencies with timelines and budget. To clean and data-migrate this piece, a poor developer (not me) had come up with a ‘quick and dirty’ approach. As soon as projector projected the slide on the wall with ‘QUICK & DIRTY’ written on it, there was a burst of laughter among the members of the elite solution club. Visibly, everyone could comprehend the hidden vulgarity. For those of you who are naïve and unaware of the latent dilettante (which I hope will be very few) when someone says ‘quick & dirty’ in an American accent, it feels more like coming directly from the Sunny Leone’s or Sativa Rose’s mouth from an X rated movie. (WARNING: Please be careful if you get curious and start google-ing these names in your office systems.)

Dirty minds, if you ask me. Or may be naive big-shots who don't have knowledge of programming terms. Because according to Wikipedia, “Quick-and-dirty is a term used in reference to anything that is an easy way to implement a kludge. Its usage is popular among programmers, who use it to describe a crude solution or programming implementation that is imperfect, inelegant, or otherwise inadequate, but which solves or masks the problem at hand, and is generally faster and easier to put in place than a proper solution.”

Well, the poor person who made the slide had other intentions, in line with the wikipedia definitions. Intentions were to “quickly” set up the data even if that meant data was “not so clean” or “dirty”. Well, obviously he was misunderstood by the elite cabal. Idea was simple – given the data has no use for future processing, is static and drives no revenues or reports and needs to be set up one-off just for the reference in the database, there is no point spending time and money on cleaning the data to give it a correct & meaningful shape. After intermittent bursts of laughters and grins among all big waves, the plan is (still under review) to keep it quick and dirty, until ofcourse the management cabal comes up with some "calm and clean" ideas!

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.