{{blog.title}}
{{blog.date}} | {{blog.stars}} stars
Author: Kiran
• Saturday, June 07, 2008

Having worked for more than a year in an environment ‘infected’ by Agile virus, where dogmatic managers don the role of Agile evangelists, preaching the Agile religion – blessing the faithful souls and forcibly converting the other hapless infidels, I have come to believe that Agile is not the way to go; for, the reasons are one too many. Wary that I might incur a curse from the Agile priests, I venture out to indulge in blasphemy.

Agile is all about developing software iteratively, with iteration spanning a few weeks and involving the whole community (clients, who consume the deliverables, testers, documentation writers, UI designers…), throughout. Making frequent deliveries is meant to add value to the customers and somehow enable you to deliver in ‘Internet Time’. Further, it would also enable the team to cope with changes in requirement, and in minimizing the risk.

No Panacea
This is like the software development conundrum has been cracked; “Software development is easy! Huh?” Perhaps, they have happily forgotten or never heard about the ‘No Silver Bullet’ prophecy.

Of course, the whole idea seems noble. But, that iteration thingy is nothing but a small project in itself – starting from requirements and design, to coding and testing, and making a full-fledged release (with all that bureaucracy involved). It does make life more miserable, for one has to bear the stress that is involved with an official release. It is much more than just checking in code, and running some test scenarios.

Mad rush
Quicker releases need not necessarily imply qualitative releases. To satiate the ever-demanding customer and the greedy management, iterations are packed with new features to be delivered; and, resolving bugs take a back seat. Again, the hapless developers come under heavy pressure.

It is a mad rush out there. These companies have become factories producing sprinters that are just happy to run, and run faster. The only purpose of their existence is achieving the iteration milestones. Nobody has enough time to mull over various design alternatives, let alone writing a spec. At any point of time, a kind of reply would be “Well, that is how it would eventually be, an independent adaptor. But, for the current milestone, such a dependency would be acceptable. We are yet to figure out how to realize interaction with such an adaptor”. Things are never in a reasonably presentable shape.

Chaos Reigns
Come next milestone, the whole idea would have changed. Adaptor concept is now replaced with a full-fledged pluggable framework - A new layer of abstraction that is generic; for, it can allow third party tools to plug in as well. Isn’t that cool? Obviously, this means, trash all that you have done until now and write more code for this coolest feature. Yeah, you are privileged enough to be working on coolest framework!! Needless to say, this would eat away few more milestones in the schedule. In bigger projects, such scenarios show up almost every milestone, messing up the whole thing. Chaos rules!

Couple this style of development with globally distributed projects, and it’s an implosive mixture, capable of bringing down the project or transform it into a treacherous beast. Of course, each of these sites would like to be credited with the delivery of the coolest feature, and on time. There is more to it; teams are keen to prove they are worthy and that they can design ‘independently’. Why else do they need those fancy-titled architects for? Yet, nobody has that single big picture. All in all, the conceptual integrity takes a beating. Naturally, the seamless user experience or quality of product suffers.

There is every chance that one of those Agile bigots around might stumble upon this article. Fearing that, they would barge in anytime, fully armed, and that I have incurred their wrath, am reserving the rest of my Agile thoughts for some other time.

Shhh!! Time to put on that Agile-loving mask and wear a friendly smile! :-)
Author: Kiran
• Wednesday, May 21, 2008
Time and again, the technology pundits have predicted that the Microsoft era is over. They had reasons of their own – owing to onslaught of Open Source software, anti-trust lawsuits, and the Linux threat. But, it has proved to the contrary. Let alone the fear of Microsoft’s decline, it is nowhere near the beginning of its end. Or is it?

However, with the beginning of the Internet era, the software landscape has dramatically undergone a transformation, jolting Microsoft off its monopolistic position – perhaps, the software bellwether has begun to wither and lose its sheen.

Paradigm Shift
With the industry riding high on the web technology, much of the ’action’ shifted to the server, with desktop becoming leaner and meaner, by the day – a clear paradigm shift. Another dimension to this shift is that a variety of electronic gadgets have gotten smarter; smarter that they run on software. I am not saying that the desktop market is going south. But only that the growth is not as huge as it used to be – there was a time once, when the number of new desktops added was more than what already existed, a triple digit growth. It is not such a hunky-dory picture anymore.

From its early stages, Microsoft has dominated the desktop software category. Irrespective of the number of products it has in its portfolio, the Windows OS and Office Suite are still the cash-cows for Microsoft, raking in almost all the moolah in their respective markets, and covering other loss-making or marginally profitable products. No matter, whatever the support for Internet that is built into these products, they are only superficial, at best; simply because they were not designed for the Internet.

Traditionally, it is so that many companies have tumbled when confronted with a paradigm shift, let alone retain its (dominant) position. Such paradigm shifts are like huge tidal waves that strike the industry, periodically. And, in the aftermath, those who started off riding on this new wave emerged the leader. Similarly, in the new world where Internet and Electronic Gadget rule, companies like Google, Apple are in vogue.

Much of the senior leadership at Microsoft is grey-haired (meaning: they are wise; no disrespect intended). And, they understand and acknowledge the paradigm shift. Consequently, Microsoft has diversified its portfolio; launching competitive products like Microsoft Zune to take on Apple iPod (and iTunes), MSN and Live Search to take on the ubiquitous Google’s search engine.

The paradigm shift has brought with it new business opportunities and hence new revenue streams - Online advertising, running to tens of billions of dollars. Umm… Yummy, can those at Redmond sit idle? Somehow, their technologies have failed to dominate in this new domain. They desperately seek to gain a footing, even if it means to shell out a whopping $47 billion to gobble Yahoo!, and borrow money to do so!

Microsoft leadership claims that they have had such competition before; and that it is only a matter of time that they surge ahead. They have survived the Linux and Open Source scare, threat from Borland (developer tools), Sun (OS and Programming languages like Java) and Netscape (browser), to name a few. But, somehow the paradigm change that the Web has ushered in is different!

Falling Engineering Quality
Face it. Microsoft is getting obese. It is a well-known folklore in the industry that Microsoft religiously practiced hiring the creme de la crème, who in turn hired smart people. Probably, this has been one of its greatest asset and the cornerstone for its success. However, if the insiders are to be believed, Microsoft is putting on weight; and is probably becoming less punitive upon its competition. Another interesting piece of hiring philosophy is to be found here. Had the merger with Yahoo succeeded, it would have become a mammoth of an organization. Perhaps, it would have crossed that threshold where in implosion could not have been ruled out.

Perhaps, as fallout of the cancerous growth in headcount that they are witnessing, it is possible that their hiring culture has got diluted; or it was diluted to make room for the sufficient hands to avert a talent crunch. Consequently, if you go by inside news, the overall engineering quality has taken a beating.

Microsoft 2.0
After about 30 years at the helm of it, Bill Gates slated to retire on June 30. Microsoft is set to reboot itself into the new era of leadership. The baton will be passed on, and the steering will shift hands. However, will the philosophy and values with which the company was founded remain intact, when both the founders are not around?
Author: Kiran
• Sunday, November 11, 2007
Software development is usually done incrementally. With multiple iterations, there is a release after an iteration, each adding new features (and defects too!) to the product. Say, if there are two features, F1 and F2, where in F2 depends on F1. In such a scenario, given the progressive development, the features are ordered such that F2 is planned in the release after F1. Or, if you have the luxury of sufficient testing cycles, both are clubbed in the same release.

If software developers are to build an airplane, more likely they would resort to the same life cycle. Having said that, lets say, F1 corresponds to 'TakeOff' and F2 being 'Landing', By same logic, F2 occurs in a later iteration than F1 - for the airplane cannot land without taking off. Poor Tester! (whoever is assigned to test F1; it has 'Take Off' feature, but no 'Landing' feature).
Author: Kiran
• Wednesday, October 03, 2007
Developers and Testers are undoubtedly at the very heart of a software development effort. They constitute majority of the team’s head count. To make things more 'interesting', these two groups are not always amicable. Quite often, they are at loggerheads, for various reasons. An unwritten gospel of software development is that there exists a psychological chasm that separates these two groups – a divide so deep that many teams have failed to bridge, no matter to how many 'team building activities' they are subjected to (which have proven to be superficial).

The False Notion
The reason for such a divide is primarily socio-psychological. Undeniably, there exists a popular notion that development offers a 'better' prospect – one of a higher esteem. Naturally, driven by such a notion, fresh graduates aspire to become developers.

Ego Conflicts
Another fallout of such a notion is that testers who missed out on becoming a developers, vent out their ire on developers (Yeah, Of course, The Grapes are sour!) – whether it is being fussy about trivial bugs or reserving all the complex bugs till the fag end of the release, just to gift developers their nightmare. On the other hand, developers are no exception - that false air of superiority might sometimes prompt them to look down upon testers, only serving to widen the gap.

It is true that developers and testers require very different skills. Development requires one who has good technical domain knowledge, enjoys writing code and technical specs, good debugging skills. On the other hand, Testing demands one who has that innate trait of running into problems with whatever they use, nitpick into the code and dig out those nasty bugs. Emanating from their job profile itself, is the notion that developers are more technical, (mis)leading to the assumption that being more technical is being superior.

Well, the fact is, such a distinction (although, it exists; and the management is reluctant to acknowledge it), is fairly trivial. And, it does come at a price - given that developers spend a lot of time debugging problems (Huh! those late nights, working weekends are more of a developer thing) while the testers are having a life. Also, the compensation package is not so drastically different, making testing all the more attractive – for it is not worth to distinguish such trivial differences from the overall perspective of life! Decide for yourself, what you want to be.
Author: Kiran
• Monday, August 06, 2007
As the software industry evolved (and continues to), it has devised several processes to formalize the software development life cycle. Some popular methodologies meticulously define every step to be followed in the software development lifecycle, failing which, the resulting output is non process compliant and is supposed to be of lesser quality. Clearly, (IMHO) it is an overhead. Of course, there are bigot organizations who invest huge amounts of time, energy and money on this. On the other hand, there are those who are blithely banging away their keyboards and 'puking' code, day-in and day-out. Do not be surprised, if some of the big brands are working this way, full time. This is what I call 'Carefree Software Development'. So here are a couple of contrived examples, but nevertheless they are close to real-life.

Cowboy Style of Management...
Enter the Cowboy-type Manager. This jean-clad guy is indeed a high-flier. Of course, attending to the cattle downplays his stature. "Enjoy folks, and be ready when I am back" he orders to the cattle. "Mind you, do not cross that line". And off he goes riding on his horse, whistliing a country-side tune.

He returns only to find chaos, utter chaos. "Oh, Gosh! What a mess", he screams. The cattle is all over the place; of course, they had unknowingly crossed that line. He is furious. He slings his gun and fires a shot in the air. "Don't you all know your limits? Don't you know how to graze?" he vents his ire on that hapless sheep standing nearby. Again, the next day, the same story unfolds.

Moral of the story: These cowboy-type managers are incredibly successful in de-railing the project. And when it is about to crash, they use their authority with full force and try to put everything in order, causing undue stress on those unfortunate subordinates. Naturally, the output is not of high quality.

... And the Clique of Lumberjacks
A group of lumberjacks were handed over a task of building a sculpture - the statue of a unicorn. No doubt, they were all thrilled at this prospect. They worked hard. Time passed... Trees fell, axes slashed the wood, and some shape began to emerge. One day, while gulping coffee, one of those said "Hey folks, isn't it great to have the horn a bit shorter. That would make it more affable". Another fellow, who is usually dominant, shouted "No. Never!. That would make it look like a horse. It should be more profound". "Yeah... way to go!.. Lets add more flesh to it to make it look stronger", cheered the others.

So now they had a new design. Nothing seemed to be in their way. They were 'almost' artistes. Time flew... After a couple of months later (needless to say that the project was running 100% behind schedule), the sculpture was 'almost' ready. A few weeks later they were finally done with their sculpture. The unicorn had evolved into a rhino, at the hands of these lumberjacks, defying the laws of natural evolution. (Excuse me, if that sounds a little exaggerated!). Not to forget, the team received an award too - for demonstrating the commitment, applying their innovative ideas and enduring against all obstacles. They were worshipped!

Moral of the story: Some say software development is as much an art as it is science (or engineering); Much like a carefully carved wooden sculpture. Of course, it was made of wood. Basically, all that was required to get this job done was to cut wood into pieces and later glue these pieces!. Bingo! you have a sculpture. Who says lumberjacks can't be sculptors or carpenters?