Software Engineer’s Blog

Software Engineering weblog

About consulting experience: Health practice & Software Engineering

There have been many hypes in the market and, therefore, many die-hard loyalists for all of them. They often advocate and consume solutions at their own discretion. Quite often, it may work out as well; but at times, it also proves to be fatal.

Would you say that it does not happen so in medical field? I agree that it is true; by and large…. But, there are many instances of patients allured by the glossy advertisement and scientific-like reasoning….. Often, less educated, rural folks are the gullible victims, though once in a while.

Part of the reason there is that we are more careful in our decisions; after all, it affects life of our own or our dear ones.

I would say, from my experience, is that caution is rarely exercised in software development. There was a trend towards that immediately after the dot-com collapse; but now that the market has recovered, it is all back to the same old practices.

Decisions are driven by the hypes; rather than the compelling need to solve a business problem; in my experience, a business problem is rarely solved by a particular medicine alone; it involves a combination of factors; people, process, methodologies, tools, … and they influence each other. Die-hard loyalist of one may deride another; vendors of new technologies may suggest these as things of past. But, no matter, what tools, processes and standards come in, if caution is thrown to winds, result would always be a chaos.

I shall be more specific; for instance, object oriented approach & UML has been around for almost a decade. But, percentage of successful adopters are far too low if you pose a fundamental question like ‘Why did you adopt this approach? Did you actually derive that benefit from this adoption?’. I just took object oriented approach as an example just because of the hype (that was) around it; you could replace that with automated testing, total quality management, business process re-engineering, CASE tools, ISO, CMM, CMMI …. Often, these are used for marketing, by the producers of the technology naturally; surprisingly by consumers as well!

Be warned that market is set for yet another transition; in terms of processes, methodologies and tools. I shall probably discuss some time later, as and when the time permits. I do not mean to deride or belittle the quality of new solutions; they do provide definitely a quantum jump. The point is, jump to what? Do we really need it? Can we afford it? In terms of cost, learning, ….? Can we defer? Can we gradually adopt?

Innovators and creators of the technology has all reason to hype up as they need to leverage their the competitive edge but for the followers, it is invariably a constant chase of a mirage, the hard way. Almost as one seems to learned something and is ready to put into use, the very core of what he learned is undergoing a change….. but for what benefit? Is it realistic? Is it the solution that we really require? What would be involved to make the transition? Believe me, it is never instantaneous…. Because, as of now, every organization, every project, every team, every customer has their own specific differences…. Retention of the knowledge and assets will not happen at the click of a button!

Well, in medical service, usage, positive & negative effects, contra-indications etc of a specific medicine is well-documented and available, at least with the doctor. He, or she, is supposed to where one can effective, where one may not be and where it could be counter-productive! What is our equivalent?

Argument could be that hazards of a wrong medical practice is too high, to tolerate slip. When we take pride in pervasiveness of software, it is high time for us to accept that, quite often than not, ours is no less…. Only difference probably being that damage is incurred much later and we could probably diffuse it in time …. In reality, we never get prior information for disasters and, in the world where the developer works more than 10-12 hours a day, we rarely have time to complete our work; leave alone anticipate and diffuse a problem; the moment a code is shipped out, focus shifts to the next functionality to be coded or bug to be fixed!

Marketing hypes around new solutions would continue to be around for time ahead as well. Also, the pace at which changes happen would continue to be too fast to absorb. Unbiased information would continue to be hard to get. Given these facts, what are our choices? …. We cannot be blind to changes; as changes will any way become more and more inevitable, as the time goes by …. Anyway adopt? That is like, self-medication without any knowledge of effects and contra-indications of medicine.

I am intentionally not proposing an answer; My intention was only to share the concern …. If you share my concern, ponder over; solutions may seem obvious but it is truly not; it is not all that easy…. Had it been, solution would have naturally come … do share your thoughts …. If I have got you thinking on this, I would consider that the purpose of writing this is met.

March 28, 2005 Posted by | software engineering | Leave a comment

Hectic schedule; just getting back to routine

Had a hectic schedule for last two/three months …. travelling around the country with training & consulting assignments

My team members have started picking up the threads and hence, I look forward to some slackening in the pace …. and hopefully, sometime for the blog!

With the Atlantic release from IBM & forthcoming VSTS release of Microsoft, market is set for a quantum leap into a new era in software engineering.

Nevertheless, the basics would remain essentially the same …. process, methodologies and tools are more of a means to an end; rather than an end in themselves ….. This fact often gets lost in the marketing din

Hope, as an industry, we would learn from the mistakes of the past….

More in subsequent blogs… I am yet to recover from exhausting assignment that I went through

March 14, 2005 Posted by | Uncategorized | Leave a comment