Forums
Depending upon how long you've been in this industry, you've seen your fair share of bad design, bad code and bad users. Darren A. explains his dealings with bad management, and how a string of edicts there-from can crush kill destroy an organization.
In the past, before management decided to, well, manage, Darren's company was able to complete 15-25 major projects each year. Then they hired a new Head of Software Services, who felt that he needed to actively manage all facets of how things were done...
To: <Team>
From: HOSS
Subject: Project Progress Charts
Hi Team,
Now that our offices are finally redecorated, we can no longer allow any of those
pieces of paper stuck to the walls. They look untidy and don't put forth the
impression that we want to give to our customers. Henceforth, all project tracking
charts are banned.
Hmmm, so we can no longer track the progress of our projects? No problem, we all know what we're doing and more or less how far along we are. We can guess at the deliverable dates.
A couple of months later, the project reporting from the team fell afoul of HOSS:
To: <Team>
From: HOSS
Subject: Burn-Down Charts
Hi Team,
From this point on I really must insist that those burn-down charts no
longer be used. None of the senior management team can understand them
and I cannot allow this situation to continue. I'm therefore banning the
use of burn-down charts; you will just have to utilize another way to
demonstrate progress on your project.
OK, it's possible to do all of this electronically, albeit a little harder to view huge project time lines on even the largest computer monitor. But it's doable...
To: <Team>
From: HOSS
Subject: Unit Tests Testing Tool
Hi Team,
I'm pleased to announce that we have now purchased a fantastic testing tool called
SOATest (at no small expense). The test team will now take over this essential function
so that the development team can stop wasting time writing unit tests.
From this point forward, all unit testing is banned and only our new tool should be
used to test our systems.
So now all developers are supposed to write, but not test code - at all? I wonder how this will turn out...
Fast forward a few months and not a single unit test had been written by the highly qualified test team. Not to worry, there were still highly qualified architects on the projects. These folks had spent a great deal of time working with users, support people, managers, auditors and even bean-counters to make sure that each project was designed to perform the necessary tasks at the required speed with the requisite redundancy and support the appropriate level of growth. Until...
To: <Team>
From: HOSS
Subject: Developer Input
Hi Team,
It has come to my attention that senior team members have been making decisions
and forcing things to be done their way. From now on, all team members, regardless
of level of experience, will get an equal vote in how things are done, and are
free to change the project architecture as they see fit.
So all the effort that the senior architects, business users, support teams and auditors put in to agree on an architecture that will provide the necessary features, throughput, resilience and scalability could now be overridden by any junior developer who thinks he knows better?
Ah well, at least the applications would still be able to scale for the expected growth in the business:
To: <Team>
From: HOSS
Subject: Software Scalability
Hi Team,
I have noticed that development teams aren't finishing their work on time because
they're spending an inordinate amount of time getting the code to work for far
larger transaction volumes than are needed today.
From now on, we will only build what we need today, and no longer worry about
future scalability; we'll deal with those needs when they happen.
...even though the requirements specify two orders of magnitude growth within 12-18 months. Then it became apparent why he was no longer concerned about making software scalable.
To: <Team>
From: HOSS
Subject: Software Scalability
Hi Team,
The company has invested a great deal of time and money in building a distributed
grid computing environment for computer work. From now on, all applications will
be deployed on the grid.
...but all of the applications are essentially fat batch-type clients, that won't ever be able to leverage any of the capabilities available in a grid computing environment.
With the entire suite of unit tests trashed, four new products and a large API (that lacked even the most basic unit testing) ready for use, they embarked on a large deployment to jam all of this untested fat-client software onto a grid environment.
It. Took. Nine. Hours.
The fallout took over a month to resolve and involved a great deal of weekend work, plus so much Mon-Fri overtime that the entire team turned pale from lack of sunlight.
In the years since HOSS' team embarked on this brave new software development methodology, they've 'increased' their output from 15-25 projects per year to... 3, and lost nine of their most competent developers, including Darren.
[Advertisement]
BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!