In the beginning, The Founder had a vision. He hired Manoj P. to develop a shiny brand new system that would embody The Founder's vision. He would have the freedom to design and build it any way he wanted. He could choose his own languages, tools and methodologies. The Founder laid out his vision and Manoj started typing. Thus was born Team WTF at what would become WTF-Inc.

Over the next few years, Manoj would encourage The Founder to hire his comrades to help. And help they did; they copied and pasted each other's code hither and yon, over and over. Features were added. The code and functionality grew at an astounding rate. Unfortunately, none of them had ever heard of the concepts of scalability, threading or aging off data. As features and customers were added, the database grew geometrically. Along with the hardware requirements to support it. And the cost. It was at this point that The Founder had an epiphany; let's hire someone who has more than 2 years of experience to help sort out the mess. Enter Snoofle.

During the past several years on Team-WTF at WTF Inc., I've made numerous changes to the architecture and underlying code to simplify, parallelize, dramatically reduce the memory footprint and speed up our primary database and application, and the other applications that depend upon it. It's still a POS, but it's orders of magnitude better than it was. Manoj moved on to build a new application in our department, which he munged up royally with the same missteps he made on our project. Then he was moved into a purely architectural role to redesign the entire suite of applications. A year later, nothing had been decided except for the highest level UI layout.

Then my boss got promoted. For whatever reason, they put Manoj back in charge of my team.

Naturally, after reviewing all the changes we've made, he wants to undo everything to put it back to the way he designed it.

I resisted and pushed it up to senior management: "You're a consultant; do what he wants!"

I was finally making some headway into fixing this place and they pull THIS?

In parallel, The Founder learned a new word: Agile. It was to solve all of our development problems. It would shorten the time to add new features to near zero. It would reduce hardware costs because of the efficiencies in software design. Management introduced Agile as a mandatory way of doing everything. They would even teach us how to do Agile. Starting with not scheduling more work than people could actually do. They managed to whittle 118 projects down to 14 staffable "important" projects. Each of those projects would be broken down as follows:

    Gather customer requirements   - 2 weeks
    Functional Design              - 2 weeks
    Detailed Design                - 2 weeks
    Developer Ramp Up              - 2 weeks (familiarizing themselves with the specific
                                             code to be modified, new libraries, etc)
    Coding                         - 2 weeks
    Developer Testing              - 2 weeks
    QA Testing                     - 2 weeks
    Integration Testing            - 2 weeks
    Stress Testing                 - 2 weeks
    Customer acceptance testing    - 2 weeks

So now coding is a whopping 10% of the total effort in what they have proudly touted as a new STREAMLINED 20-week-per-sprint process.

A few phone calls and a couple of interviews later, I have another job. I tell my former boss (now B+1) who goes nuts. He bucks it up to his boss (B+2) who wants to talk with me:

  B+1: We need you
  Me:  I appreciate that, but if this guy is going to undo everything I've accomplished 
       and management is going to back this foolishness, then there's no point in me being here
  B+2: You CAN'T leave...
  Me:  (Tongue-in-cheek) "Emancipation Proclamation"!
  B+2: What about the delivery schedule?
  Me:  Assign my work to others
  B+2: Eveyone is overloaded now, we assigned this work to you
  Me:  Pretend I got hit by a bus; you'll need to prioritize the work and delegate it accordingly
  B+2: We already suspended all the non essential projects: everything that's left is top priority!
  Me:  "Everything"?

The conversation went nowhere from there, but it was decided that I should spend a week offloading knowledge on how the multithreading in the application works. For this, they designate the most junior developer on staff to sit with me (apparently because a programmer is a programmer is a programmer, and a programmer 6 months out of school has skills comparable with those of a 30 year veteran).

  Me: The main processing of the application is logically single threaded, 
      but several threads run this task in parallel for massive speed improvements;
      a publisher/consumer model feeds each of the threads and connects various
      components with simple JMS queues and map-messages for various data attributes
  JD: How do you handle singleton resources?
  Me: There are a handful of synchronized methods wrapping critical sections
  JD: So I can just synchronize all the methods in all the classes; that 
      will keep things coherent, right?
  Me: That would probably yield lots of deadlocks; at best it would kill performance
      by effectively forcing the application to run only one thread at a time
  JD: But it COULD work, right?
  Me: Not the way you'd expect
  JD: But I CAN do it that way?
  Me: I wouldn't, but once I'm gone do whatever you like...

In the past, I've walked away from places where this sort of idiocy set in. This time I tried to stick it out and see if I could make a difference. I was able to fix the code; it was the management that was the problem!

It was my own fault for thinking that I could fix "stupid".

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!