Software Engineer’s Blog

Software Engineering weblog

Lifecycle of a buzzword: A cynical perspective

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.

August 1, 2011 Posted by | Agile, Business, lessons learned, Management, software engineering, Unified Process, Value Based Software Engineering | Leave a comment

Software Engineering, and changing software development business

Pardon me if my statement “software engineering is hard” sounds like a cliche. Lest it sound like I am parroting what Grady Booch has already stated “software development has been, is, and will remain a fundamentally hard profession” , let me elaborate. Here, my reference is not about software development being hard due to inherent complexities and invisible changes. It is rather about doing business in a changing world. What does that mean?

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.

January 13, 2010 Posted by | Business, Collaboration, Product Engineering, software engineering, Unified Process, Value Based Software Engineering | 1 Comment

Architecting software in a new world

I came across an interesting O’Reilly web cast titled ‘O’Reilly Webcast: 10 Things Every Software Architect Should Know’. It is important ‘words of wisdom’ definitely for software architect

But, well, I believe much of it is quite relevant to many others as well, It is all the more so as software has become integral part of our every day life and software development is getting to be increasingly, as Grady Booch points out

December 20, 2009 Posted by | Business, IBM Rational, Model Driven Architecture, Rational Unified Process, Software architecture, software engineering, UML, Unified Modeling Language, Unified Process, Web 2.0 | Leave a comment

Elements of engineering discipline

As per IEEE definition, software engineering is “systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software”. There is still ongoing debates on how much engineering can apply to software development, and what would applying engineering mean.

Let us put it this way. Being “systematic, disciplined, quantifiable” is more of a business need. As software is getting increasingly pervasive to every aspect of life, business wants software development to be more repeatable and predictable.

Computing, business and software development environment has been undergoing drastic changes. We have attained some level of repeatability and predictability in software development though that may be far below the level desirable from business standpoint. This was due to untiring efforts of many great brains.

Looking back, what helps us towards being “systematic, disciplined, quantifiable”? “repeatable and predictable”?

I would classify progresses into following categories, with progress made in each of them:
1. Processes (who does what and when) and methods (how)
2. Standards (with standards like CMMI levels on one side of the spectrum and coding standards at the other side)
3. Proven practices (Harvest success patterns)
4. Tools (Software tools that help us do our work better and faster)
5. Metrics (Measures helping in objective observation and decision making)
6. Body of knowledge
7. Code of ethics

These are what I am calling elements of engineering discipline.

Let us not have any illusions.

Methodology/process wars are far from over. Proliferation of programming languages would continue. Computing technologies would continue to evolve.

There is a long way to go before software engineering would stabilize as a true engineering discipline but essential ingredients are getting to be in place and there is business need…

Let us move on

August 21, 2009 Posted by | Agile, Rational Unified Process, software engineering, Unified Process | Leave a comment

Consortium for IT Software Quality

As software permeates every aspect of daily life and as we depend more and more on software in all walks of life, quality of software gets to be of utmost importance.

World has come a long way from the early perceptions of quality as a natural consequence of following a good process. Agile community has asserted umpteen times, reflecting in manifesto of software craftsmanship and agile manifesto, quality of software that add value to users in their context is far more importance than religious, and often dogmatic, adherence to process.

People, process and automation are three different, orthogonal but often inseparably interrelated, factors of what goes into making of a quality software. These form different dimensions that call for attention of a manager of software development project, and not conflicting goals as they are sometime made out to be. Managing software development project is not progressing on one dimension at the cost of another but working with a dynamic balancing of these dimensions through the course of project

Three dimensions of software quality

Three dimensions of software quality

It is interesting to note, in this context, emergence of a consortium focused on software quality. It is a step in the right direction. I hope that this would help in making life better for its users and customers

August 20, 2009 Posted by | Agile, Product Engineering, Software architecture, software engineering, Software Factory, Software Quality, Software Testing, Testing, Uncategorized, Unified Process | 1 Comment

A picture is worth a thousand words

(Mis)Communication

(Mis)Communication

August 17, 2009 Posted by | Product Engineering, software engineering, Uncategorized, Unified Process | Leave a comment

The 4+1 views of game development

This title is inspired by an IEEE paper 4+1 view model of software architecture.

The referred paper on software architecture suggests five views to organize description of software architecture. This helps to separation of concerns, with each view addressing concerns of a specific stakeholder role like programmer, designer, integrator, and system engineer with usage scenarios being central to all.

Similar approach helps to understand and manage game development. Note that I am referring to game development; not necessarily game architecture. It helps to look at game development from various perspective with gamer perspective being central to all.

The 4+1 views of game development

The 4+1 views of game development

These are not necessarily orthogonal; rather elements of one view are connected to elements of another just as in case of 4+1 view of software architecture. Each view helps define focus on specific stakeholder concerns, and in turn, roles, skill sets.

August 15, 2009 Posted by | Game, Game Architecture, Game Engine, Gaming, IBM Rational, Product Engineering, Rational, Rational Unified Process, Software architecture, Uncategorized, Unified Process | Leave a comment

Art, Craft, Science or Engineering?

There have been many discussions in the past on whether software development is an art, craft, science or engineering. For convenience, I am listing below the major ones that had profound influence on my thoughts over years

1. Book Software Craftsmanship – The New Imperative
2. From Craft to Science Part 1 and Part 2
3. The great art and craft of software development
4. Software engineering and the Art of Design
5. The art, science and engineering of software development
6. Manifesto of software craftsmanship
7. The privilege and responsibility of software development
8. Commitment
9. What is software design?
10. Software that lasts 200 years

My view is that software development is a combination of all of above. My view is also that software is a construction of human mind or rather minds; and should I say human brains. Yes, mind and brain. Emotion and intellect. What is important to me is this human creation has pervaded virtually every aspect of life and business by now, unlike any other human creation, and hence business critical.

It is an art, it is a craft… beyond all that business depends on it; life and career of many depends on it. Hence, it is important to bring in continually better control, better quality, better transparency and better predictability into software development. Taking recourse to engineering is to this end. Engineering is not an end in itself but a means to an end. Engineering as a manager’s tool to have better control, better quality, better transparency and better predictability. From that standpoint, we find that apparently conflicting perspectives are not truly conflicting; they are different dimensions of software development.

Every successful software development manager knows this and manages his/her business accordingly. These fits into my overall management-engineering framework; result of applying learning into practice, and continually refining my learning based on observation.

August 14, 2009 Posted by | Agile, Product Engineering, Rational, Rational Unified Process, software engineering, Software Factory, Software Quality, Uncategorized, Unified Process | Leave a comment

Engineering game development?

When I look at game development, as a software engineer, is a striking similarity to what we have gone through in software development.

Most critical milestone was awareness of software crisis and decision to adopt an engineering approach to software development. That essentially meant applying principles and practice of engineering into software development.

Is it a right thing to do? There are pros and cons to the argument. Can we development software with a predefined process? Is software development process prescriptive or adaptive? It is very project specific question. There are software development projects which are very mundane and There are ones which are highly complex, and exploratory. There are simple ones where one could go very light and instinctive; small team, developers with good skills, great motivation, and synergy. In a well managed projects, even the latter ones tend to get predictable and prescriptive over a period of time. It is always a project specific judicious mix.

Where we successful? Yes, to some extent. Sure, there were many stumbling blocks. I value the initial commitment to engineering irrespective of whether one agrees to engineering approach to software development or not. Even such a discussion can take place only in the context of related learning from the practical adoption.

I am tempted to explore possibilities of engineering game development, on similar lines and learning from the mistakes of past.

August 13, 2009 Posted by | Product Engineering, Rational Unified Process, software engineering, Uncategorized, Unified Process | Leave a comment

Keep it simple

Life of a software engineer was rather simple, unusually simple with adoption of agile approaches; or so it seemed. Clouds seem to be coming back, and turbulence is back in the air

I have always looked at any change with simplicity as a yardstick, and that has helped all through. Any new change must be simple, because my business is delivering solution to my customer on time and budget; not learning technology, tools, standards or best practices, though they are of value as enablers. Indeed, enablers must be simple

Technology, tools, process, standards and best practices that you adopt must be simple to understand, adopt and use. If not, you have a problem in hand, for now and for ever. That is because software is developed by the team, not just an individual, and that team is bound to change over time. If what you are adopting is complex, you would need to get your team up to speed now and every time a new member comes in. Again, technology, tools, process, standards and best practices are bound to evolve. Tracking these, and ensuring that entire team is in sync, is a greater challenge. My experience is that these are not complex, in itself. Issue is made complex, by a myopic vision or dogmatic mindset.

My advice is: Keep it simple, always. Life is simple. Let us not make it complex

August 10, 2009 Posted by | Agile, Rational Unified Process, software engineering, Uncategorized, Unified Process | Leave a comment