A site devoted to discussing techniques that promote quality and ethical practices in software development.

Monday, October 4, 2010

Management never learns

Let's wind the clock back to year 2000, not long after the Y2K had been vindicated as hoax of the millennium, I was working as a senior software developer in a software company called Mincom that has a product called LinkOne in its product suite. At that time I was not associated with this business unit but was being enticed to join it to redevelop to exploit component technology.

Suddenly, the lead developer resigned and next the product manager. The tide continued and eventually the whole team resigned en masse, include the clerical assistant. Leaving behind was a pile of undocumented C/C++ Win32 SDK code. Business Units in Mincom were, and to a large extend still is, very disjointed groups with very little cross pollination of knowledge. In the mean time, the product had a large users base world wide and they obviously weren't happy being left with an unsupported product after heavy investment in entrusting their data to this product. It is not like swapping Microsoft Word with OpenOffice.

The management at that time speedily mounted a rescue mission, which I called Rescue ver 1, to deal with this product. I was one of the two senior engineers ordered in to take charge to rebuild the team and to take control of the product. At that time, Mincom had the luxury in terms of availability of resources to mount an effective rescue mission and the process went smoothly even though it took a long time for the team to get on top of it.

It was not exactly clear what spooked the team so badly that they resigned en masse but one rumor had it that they did not like the management initiative and the pasture was greener outside. Consultative process and listening to staff/developers were not the forte of the company and still is not. Hence this rumor has credence.

Now fast forward to post GFC era in 2008, which by then I have parted company with this business unit for over 4 years, the company used the GFC as an excuse to begin shedding staff giving rounds of redundancy. LinkOne was not treated any differently even though it was pulling in a respectable income for the company.

Once again, people in this team gradually left the company either through redundancy, disenchantment or simply tossed it in before the ship sank. By 2010, the team, including the key architect who transformed the product from a Win32 product to a respectable .Net product, suffered a bout of anorexia reducing the number down to 1 person with a manager! To this observer, it is a case of Deja Vu.

The remaining person was a product support engineer and obviously they desperatly need a 'team'. While keeping the news quiet from their customers trying to prevent the riotous reaction of the first episode, the company tried to mount a rescue, Rescue ver 2, albeit a vain attempt given the company was now depleted of resources; they had easily more managers than developers. It could only mount a vain mission using time-shared resources. The ineffectiveness of this management style has been well documented by DeMarco. Having worked in this product and knowing what resources remained in the organisation, the future looks bleak not only in terms of supporting the product but to enhance it. It is in precarious position because they cannot afford to lose any more.

Perhaps it is their desire to wind up this product without telling the users by natural attrition.

Once again, Management could have stemmed the loss of unquantifiable resource if they are more consultative and treat their staff with respect. There are other well-known cases of people doing the right thing for ending up being sacked when the company is not exactly flushed with resources. Truly a last act of desperate death throe.

When we mounted the ver 1 rescue, we had the luxury of a pool of resources and knowledgeable long term users to guide us and to show us how the product was supposed to perform. Not anymore. All those knowledge has gone out of the window. The only consolation they now have is this team that left was keen methodologists leaving them with a product source code in a much better shape than when I inherited in ver 1 rescue. I wonder how long this will last before it degenerates into a mess as management presses the poor soul to rush out the fix as his time-slice is over spent.

From this vantage point and from my personal involvement, it is a case of management never learns and never knows how to manage. I am wondering if the loss can be translated into an entry in their profit and loss statement, will their board of directors or share holders still take such a quiet sheepish position.

No comments:

Blog Archive