Software Engineer’s Blog

Software Engineering weblog

All too familiar management myths

  1. The Myth of 100% Utilization
  2. Management Myth #2: Only ‘The Expert’ Can Perform This Work
  3. We Must Treat Everyone the Same Way.
  4. Don’t Need One-on-Ones.
  5. We Must Have an Objective Ranking System.
  6. I Can Save Everyone.
  7. I am Too Valuable to Take a Vacation.
  8. I Can Still Do Significant Technical Work.
  9. We Have No Time for Training.
  10. I Can Measure the Work by the Time People Spend at Work.
  11. The Team Needs a Cheerleader! 

 

January 2, 2013 Posted by | Agile, lessons learned, Management | 1 Comment

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

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

Lesson learned in cloud computing

Cloud computing is here to stay…
Cloud computing helps you reduce cost….
Cloud computing helps small business run without adding avoidable expenses on infrastructure…
Cloud computing helps business focus on their core competency rather than worry about infrastructure …

……… and so on goes hype about cloud computing.

I was working with hosting services on cloud, with a cloud platform offered by one of the major players in Indian IT industry, and key attraction was that it relieves us of worry about setting up and managing platform

I have seen a couple of inexplicable outages, without any advance intimation whatsoever, in last three months. This happened during business hours, and not resolved for a couple days even. Call to ‘customer support’ resulted in more experimental suggestions which ended up wasting my time further; I learned hard way that even service provider is in learning phase and service seems to be of early beta quality. Luckily, all this happened during an experimental phase though definitely at significant business cost. Now, in retrospection, I am glad that issues were exposed much before going live.

I am very skeptical on delivery of high promise. Strength of cloud is as good as the weakest link and I have a dangerously weak link when I am working with a faceless entity.

I am not arguing against possibility of cloud computing. My contention is that cloud computing platform must necessarily prove its trustworthiness as platform before business can depend on it!

July 30, 2011 Posted by | cloud computing, lessons learned | Leave a comment