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.

The character Hoss from the show Bonanza

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!