Software Engineer’s Blog

Software Engineering weblog

Pioneer, par excellence

I believe it would be a gross mistake to talk about computer science and software development without talking about  the pioneer par excellence Alan Turing. Yet it is harsh and ironical that the person who is considered as father of computer science and artificial intelligence had to traumatic times for reasons that had nothing to do with his contributions to society in the world of computer science and artificial intelligence

May 25, 2013 Posted by | History, Sociology, software engineering | Leave a comment

An old but interesting Feynman lecture on computer

I came across an old but interesting  Richard Feynman lecture on computers

World of computing has changed  drastically since then yet much of what he mentions remain true even now. There was hardly any means or possibility of predicting, back then, what future world of technology would be like.

Yet, his insights even decades back were pretty sound, his observations and speculations were very close and his explanations and illustrations are so simple to understand, though he was more of a physicist rather than computer specialist. Therefore, I believe this remains a useful lecture for students of computer science and software engineering even today

May 24, 2013 Posted by | History, software engineering | Leave a comment

Discipline in Thought

This is an interview with the software engineering guru Edsger Wybe Dijkstra; I consider this as one of the greatest videos that I could locate in You Tube.

Of course, I must admit that he is  much more than a software engineering guru given that  his contributions to mathematics and other related topics are equally profound. Still I refer to him here as software engineering guru as software engineering is my subject, specialization and profession. More than that  I find  much of he discussed decades back about software engineering remain very relevant even now (perhaps more relevant now than ever before). That too when everything else about the industry keep changing!

Well, there are things that don’t change even in an industry which is highly dynamic and evolving. That is, fundamentals don’t change, and it pays to know them well… and that is the reason for me to share it here

May 23, 2013 Posted by | History, software engineering | Leave a comment

Ada Lovelace, the first computer programmer

Interesting to know the world’s first computer programmer was a lady when we look back  in the context of  emerging ‘brogrammer’ culture

May 23, 2013 Posted by | History, software engineering | Leave a comment

Secret History of Silicon Valley

Computer History Museum video on  ‘secret history of silicon valley‘ tracing evolution of computer and software industry


May 22, 2013 Posted by | History, software engineering | Leave a comment

Perspectives on Tech Leadership

Computer History Museum video of a lecture on Perspectives on Tech Leadership by Google’s Eric Schmidt


May 21, 2013 Posted by | Google, History, software engineering | Leave a comment

About being agile

A decade or so back, agile community was small.. It was a community that knew what they do and how, and focus was on core values. But now, that does not seem to be the case any more. It looks like, agile has become struggle for learning handful of terminologies, following ritualistic practices, and getting certified for many!

Back then, common refrain when talking about being agile was “what you are talking about makes sense but, you know, our situation is different. We have our own ‘process’ certified by … and we follow the process’. Strangely enough, when I look around I find that most of them have joined the bandwagon, claiming to be agile. Yet how they go about their job remains essentially the same! That is, either they bypass documenting altogether even the very critical information in the pretext of being agile or get bogged down by documentation for compliance to standards. Adapting to change has become more of a knee-jerk reactions and continuous firefighting. Honest communication suffers with routine bullying. Unfortunately, world has not changed much for them, except for the plight of having to deal with a new set of terminologies and technologies as well and getting ‘certified’!

In this context, it is interesting to read article ‘What makes you agile‘. Indeed, it is important to bring focus back into what agile stands for.

I believe they are:
1. Being with the customer, and delivering value to customer continuously
2. Documenting information as we develop software but not getting bogged down by documentation
3. Delivering working software, and ensuring customer is able to use software to meet their needs continously
4. Working as a team with proven practices and effective level of automation
5. Adapting to change as customer needs change
6. Working as a team with honest communication all through

Technology and practices could be help these but not at the cost of these.

January 7, 2013 Posted by | Agile, software engineering | 2 Comments

Making of a professional software developer!

I came across an interesting lecture on professional software development by Robert Martin, a promotion part of video lecture series on clean code. I would recommend every software developer, and aspiring ones, to listen to. I believe that you will find this as quite thought provoking, and inspiring, just as his many other lectures are.  You would find it gently nudging you out of comfort zone into challenges of evolving into a true professional

Head count of manpower involved in software development has multiplied manifold from the time I started my career in software development more than two and a half decades back. Technology involved has changed, and software development environment has changed as well. World of software, and its role in the world, too has changed quite a lot since then…. and, as software reached out to every walk of life,   complexity and expectations too has increased manifold.

As we have reiterated many times over, software is essentially a construction in mind in first before it is executed in computer. It gets created in the minds of users, customers, developers, testers, … and often these do not connect breaking dynamic equilibrium of balance as software evolve. Making it still harder, complexity and disconnect increases exponentially with increase in the number of minds involved. It does not make any sense to wish these complexities away. These are here to stay. It can only get more complex and challenging, as we depend more and more on software.

Key to being a professional is to get on top of these. That is, a true professional would stand up for what he believe in, what he likes to do, take up the initiative, own up the commitment and deliver to the commitment. A true professional will see commitments as extremely important, not a casual word. We work as we work as a team, and a whole chain of commitments depends on your commitment. Many business, and many lives, depends on it and if commitments are not honored all of them are affected. It is your responsibility to see that commitments made by you are honored within time, budget and quality expectations.  That is, you are absolutely in charge of the situation, rather than its victim.

Note: Video of interviews with a super star from Indian film industry and another one with a master batsman from Indian cricket embedded here, both worked their way up fighting many odds. Both are involved in a profession which calls for individual excellence and team work for success. Both are professional who made indelible in their space, and are reflecting back on their rich experience. I believe spirit of professionalism cuts across many disciplines. It may differ on details but fundamentals remain the same. It is about conviction, self belief, working hard for what you believe in, working as a team and and winning against many odds, in the right spirit

I believe, technologies, processes, methodologies and tools have evolved to a great extent by now and these can help us address the key challenges, if we can put these together in the right way, as people/team enabler. Well, it is important to get it right.

Also, it is important to stay clear of dogmas, and realize that when we direct attention towards moon by pointing in that direction, the pointing finger is not moon. It might sound trivial but it is common to see finger being confused as moon. What do I mean by that?

I have seen process quality standards like CMMI degenerating into a compliance ritual. Insistence (by whom? It is interesting to know) on excessive documentation leads to outdated, and even lack of (gets postponed as it is time consuming), documentation. Later documentation is done purely to satisfy auditing needs. That is, an initiative intended to help you manage collapse on its own weight. The real problem is not with CMMI but in its adoption

I have also seen free and honest communication getting compromised in so-called ‘agile’ environment with regular meetings turn into witch hunting and ‘save my skin’ interactions. That is, the term ‘agile’ gets stripped of its core values and gets used as a matter of convenience rather than any good. Again, what fails is not ‘agile’ but its adoption

Automation initiative, that starts with purchase of a commercial software for software development, get stuck in learning some esoteric aspects of the tool rather than addressing true automation needs. Again, problem is not automation rather how automation is approached and implemented

It is curious to see the patterns of wrong adoption repeating itself. While technologies, processes, methodologies and tools can help us in addressing key challenges, often, it is the related technical details grab attention through advocacy of vociferous loyalists and marketing machinery, rather than applying them right. The fact that these are enablers in the first place is conveniently forgotten

Looking around, it look forward to a phase in software development, a phase that physics had gone through between Galileo Galilei and Isaac Newton … a phase of consolidation, period of drastic and intense changes with far reaching impact. We have seen some of these continuing even into early 20th century through Albert Einstein, Werner Heisenberg , et al…. and as an industry, we continue to deal with more unknown factors than known ones, till the dust settle

I hope to see software development eventually settling down to become a profession, in its true sense… It has changed over years but still it needs to go a long way before it can truly be called a responsible profession.

April 21, 2012 Posted by | Agile, Business, Collaboration, lessons learned, Management, Sociology, software engineering, Software Engineering Career, Software Testing | Leave a comment

Software Engineering, and town planning analogy

I have seen many literature discussing Software Engineering relating software development to building construction, and a very few comparing it with town planning. Of course, I am no expert on civil engineering or town planning. My observations are from the perspective of observer.

Comparison with building construction is probably easier for any one to relate but I think it is quite a simplification. It helps to convey role of process formalism, team work and automation depending on scope and scale of project. Major point of disconnect, as I find, is in the epilogue. I think only a few, if at all any, building would need to adapt to change as a software must in its lifetime.

Let me clarify here that I am not referring to Software Development Life Cycle but rather time from its initial release for use till it is withdrawn from use, along with all its variants.I have not seen a natural death of a software so far. Either it is killed by its manufacturer by formally declaring End of Life, or it is killed by market and other forces. Well, then there are cases where software is continued to exist with its manufacturer withdrawing support. In general, it amounts to withdrawing ventilator. Is that a natural death or a forced one? I am not sure where to classify it

Coming back to town planning analogy, I find it is closer to software development, than a building construction, in the sense that it starts off in an ambitious plan and in a systematic manner. Over a period of time, town is goes through many changes as it change hands. People who are in charge of town planning, administration and management changes, each of them having their own ideas on how town should be. Market dynamics changes bringing in new possibilities. People living in town changes, and their needs. If you consider a modern town/city, what it was a few decades back and what it is now, you will realize changes and its impact. Town infrastructure had to adapt to accommodate evolving world. This is more visible in developing economies, partly due to ‘ad hoc’ town planning measures and often being at the receiving end of technology changes.

What makes software development further more complex is drastically shrinking timelines and its intangible, invisible nature.

August 3, 2011 Posted by | Software architecture, software engineering | Leave a comment

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