Software Engineering weblog

In my tenure in IT industry spanning more than two decades by now, I have seen rise and fall of many buzzwords. Some of them are: Artificial Intelligence and Knowledge Base Computer Systems in 1980s, Rapid Application Development and Object Orientation in 1990s, Use cases and Stories in 2000s, … and the list goes on… debate goes on ‘object oriented or structured?’, ‘agile or CMMI?’, ‘agile or UP?’, ‘use cases or stories?’

I am not disputing the value of these but rather questioning the hype that comes around these as they emerge. These hype help business of promoters but adversely affect their proper interpretation and implementation. It is equivalent to percolating modern innovations and approaches in healthcare through marketing machinery, skilled in marketing than healthcare.

Hardly any scientific analysis can happen without demystifying buzzwords first, and that requires going to its very origin. I do this regularly, try to see through these hype, just as I am sure many others like me in the industry also do. In the process, I have also noticed a pattern to meteoric rise and fall these buzzwords, going through different phases as below. Quite often, this is carefully orchestrated for obvious reasons.

Discovery: Each of these emerge out of experiments in a relatively small group; some one or a team taking extra care to pull out key factors those helped and those worked against. Those helped soon are packaged into best practices, spiced up with adequate marketing masala .

Evangelization: At this point, it takes a curious turn that marketing machinery is now active looking for ‘nails’ for this new found ‘hammer’ . That is, inventing problems for new found ‘silver bullet’ is a business imperative to justify cost put into packaging the solution!

Adoption: This effort, in general, is richly rewarded, finding fertile ground in the minds of ‘managers’ looking for ‘quick-fix silver bullets’.

In most of the cases that I have come across, problems are project specific though might have some resemblance to problems elsewhere. Solutions from outside, based on experiences in solving similar problems elsewhere, can help providing objective assessment and guidance but cannot simply solve these problems, by themselves. It is so because problems, in their very nature, are unique, intrinsic and integral to the project. External agencies (consultant, contractor, methodology, tool, ..) can help to identify but uprooting must necessarily be internal act.

At Mount Everest: What follows is a war of buzzwords; at times, one winning over another at times in terms of mind share to become ‘de facto’ standard…. Curiously, this is beginning of decay and rotting starts within, largely unnoticed… Each buzzword acquire new meanings far away from its original form….Originators are now caught between dilemma of what they created or dumping it…They go about issuing clarifications and revisions, further adding to noise…

Big Bang: What follows is disillusion and decline. Horror stories of failure emerge out of cupboard and world is on the look out for a new buzzword … and the life starts all over again.

Particularly interesting, looking at it from India, is the prediction that ‘India-centric IT services companies will represent 20 percent of the leading cloud aggregators in the market by 2012’ is interesting.

Prediction that ‘mobile phones will overtake PCs as the most common Web access device worldwide by 2013’ indicates a changing landscape of computing. Computing was once a terrain for techno-geeks; it is now an irreplaceable aspect for everyday life, tool for business and platform for collaboration. Is it not yet time we get serious about it?

If one were to hibernate for about five years, world of software that you see would be quite a lot different. Changes may not be fundamental but there are significant changes. Well, as always, devil is in the details.

Let me elaborate going a little more specific now. Let us look at from two perspectives.

i) Analysis and design: Object Oriented Analysis and Design was quite in the hype early 1990s. I too joined the bandwagon, going around with the hammer looking for nails. Books on object orientation from those days talked at length about finding abstractions (identifying nouns etc) from requirements but these provided no scope for working with technical solutions. This was largely left to the discretion of individual practitioners. Experience of these practitioners were absorbed into standard Object Oriented Analysis and Design methodology taking it to its present bloated form. This happened in a span of 5-10 years

ii) Software Testing and Software Test Automation: Way back in 1990s, when popular testing tools like IBM Rational Robot (then called SQA Robot) and HP (Mercury) WinRunner came into being, popular success of web could hardly be envisaged. What was started off as tool to testing Windows GUI application had to extend itself into test web based application. These challenges continue as web 2.0, SoA, SaaS and mobile applications emerge. Point here is, when projects are undertaken in respective technologies, necessary tool support is not yet in place often. It is left to the individual teams to create custom solutions, which subsequently get into available tool sets.

These details are rarely look into, at decision making levels. Management of software development business are still desperately looking for mythical silver bullet solutions. Tool vendors still continue to promise magic wand solutions without looking into details before making such promises; well, it is again business! Developers are caught between …

I am not proposing a miracle solution. No such solution exists. My effort all along my consulting practice has been, and will be, to get business into sufficient level of details in decision making and helping them implement the same. With the scope for factoring in “Success Critical Stakeholders”, I find Value Based Software Engineering to hold potential as framework for such a deliberation.

As a software engineering practitioner, I had been trying to apply software engineering practices in my daily business life. For instance, I started working with object oriented approach from 1993. I started use case modeling from 2002. I had started adopting agile practices since 2003. I started using function point estimation since 2004. As a subject matter expert, trainer and consultant, I had been helping my customers adopt these, and many more.

I help my team and my customers adopt because I do believe in these practices, and its business value. That said, my observation and experience has been each of them has evolved as the way of doing, through success in specific projects, then generalized and applied in many similar ones. Absolute care is called for when applying to a business context to be successful, because each context is different; people, business imperatives, priorities, technology, customer, user, … these differ.

Success here refers to business success. For example, when a project team is enabled on requirements definition, compliance to a defined standards is incidental; Compliance to a standard is rarely a real business objective/benefit. It, in turn, for another business objective/benefit. Actual success would mean achieving business objectives of well defined requirements. It may ,for instance, be a better communication across the team, control on scope creep etc. There are many cases where documentations are created but never referred except for process audit. It is pointless if compliance to standards is achieved but not the business objectives

Why am I saying? If you look around, you will find many situations where hours, or even days, are spent on creating documentation to convince an external auditor. I have seen this happening many times over. What is the business value delivered? Valuable productive time is being spent on a work item that should have been in place. These should have been part of the process, or by-product of the process, is being created for the sake of review. If it is truly valuable, why not account for it? If realities of business does not allow time for such documentation, why create them in the first place? Why recreate just for the sake of process compliance?

What is the issue? It is conflicting stakeholder interest, not mapped, not assessed, not tracked, not managed, … well, all stakeholders are not the same, and all stakeholder interests are not the same. Nor these remain the same; it may change with time. Practices which does not realize this, sooner or later degenerate into a ritual.

Let us accept. Practices of software engineering are not universal as in case of other engineering disciplines because underlying principles are not universal as in case of underlying scientific principles of other engineering disciplines; say scientific principles in mathematics or physics.

Software is a construction of human mind and software development is a teamwork. Therefore, management of software development business includes, but goes much beyond confines of, traditional science. Some of the underlying scientific fields are physics, mathematics, organizational behavior, economics, management science, and sociology

That makes it more than what a everyday business can chew; it is more of a potential research area. But life is not so complex either. We balance these forces everyday; we do it more out of experience and gut feel. Dynamic balancing is done in the context of everyday business. What interests me in value based software engineering is that it gives me a context and a framework for such balancing and a reasonably scientific analysis

The Standish Group‘s report, “CHAOS Summary 2009” indicates that only 32% of all projects are succeeding. This represents one end of the spectrum with the gloomy picture of failing projects. On the other end is pervasive influence of software in every walk of life and burgeoning business of software development.

Since 1968, many has professed software engineering. Software engineering defined as “systematic, disciplined, quantifiable approach” has been both wide accepted and questioned. Fundamental questions remain unanswered:

1. Is software development a craftsmanship an engineering discipline? Why should the question be either/or ? I think it is both
2. Is “systematic, disciplined, quantifiable approach” important or delivering value NOW is important? Again, I think the question is not either/or. It is interesting to see the definition of engineering from Merriam-Webster Online Dictionary. That is, meaning is given as the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people . More than “systematic, disciplined, quantifiable approach” in itself but ensuring value is delivered to business, ensuring success of success-critical stakeholders is more important.
………………………………………… and many more

Value based software engineering seems to be providing a framework for assessment. It answers many questions and it is throwing up many more questions. These questions are poised to take software engineering to new heights

I am getting set to explore the space of “value based software engineering”. I plan to dedicate my new year for “value based software engineering”

Again, another year is coming to a end. It is time for a new beginning.

Personally for me, 2008 represented a successful completion of a journey commenced in 2002, and 2009 was a new beginning. Foundation is being built yet for my new dream, and realization of that is a long journey; a journey that may probably take about 10 years. Therefore, 2010 represents a continuity for me personally rather than totally a new beginning

Yet it make sense to look back into the times gone by and then look ahead. Year 2009 started on a gloomy note with the world in the grip of recession. As we see the world gradually wriggling out of recession, the coming year 2010 promises to be better.

2009 was a mixed bag, in general. As I look back into 2009, what comes to the top of my mind, on a positive note, is Oscar awards coming to India for the first time. What I recall on a melancholic note is the unexpected loss of an icon of our times ‘Michael Jackson’

About

Software engineer referred here is not a person with designation “software engineer” or similar but a practitioner in perpetual quest in balancing academic interest with business priorities.

This is blog of my forays into software engineering!! Indeed, software engineering is not new; it is there for decades now… to be precise, since NATO conference 1968. But does it make sense? does it have practical relevance? in the context of business imperatives? what does practical adoption involve? … and many more questions follow

In my business, my endeavor to deliver business success to my customers leveraging software engineering principles, best practices, tools, technology and so on… and my learning and experiences are what I seek to share here