You’re Fired! – Redux

I walked into the office this morning and was called “downstairs”. The official line was “Due to the economic downturn, blah blah”… You get the idea. I know better. I was working on a project that was grossly underbid as a fixed-price deal by a company - designated  “architect”  -- which consequently forced a few of us  developers into an impossible position, under extreme time pressure, on a new technology that nobody in the office had ever used before. The schedule was virtually impossible to meet. Anyone with an above room temperature IQ could easily see this, and I had been vocal about it from the beginning, so what happened to me was no surprise.  Management was in a state of denial.  One developer who was brought on decided to quit in the very beginning. Then, they scrambled to bring on two other developers from another office and another project.  The client was not very helpful, although they could not be blamed, really. This particular  project was destined for problems from the beginning, in my opinion. Of course, one could make the case that the company was in a position of attempting to do anything to keep business in the pipeline, “due to the economic downturn”. Still, when you are bidding a project, you don’t want to shoot yourself in the foot, but it seems to me that’s what they did.

To add insult to injury, the “architect” person refused to allow the developer team to use multiple checkout in TFS (that’s the default) –- causing hour upon hour of delays, and on top of that – refused to allow us to include the client’s base class library project  in the solution so that we could debug through, claiming it would “add complexity” – which makes no sense, since it was the  identical source code the client gladly  provided us with and used to  build the assembly to start with! It actually got so bad that developers started working offline to be able to get stuff done. I have never – I repeat NEVER – been put into this kind of arbitrarily restrictive environment in developing an application!  Developers were not consulted in advance about this project and its risks. Only after I got involved did I realize that one of the scope requirement our “architect” had included -- of WCF enabling the client’s entire library-- was virtually impossible, and I successfully got them to remove this requirement after screaming bloody murder about it. What am I talking here, Greek? I said what I believed was right, and i got shot down! We had an environment where you were supposed to be able to provide input – but when you did, it became a “good old boy” network and you would be quashed. Not cool at all! What’s more, if you are the architect on a project, you have NO BUSINESS tinkering with the codebase and checking in untested code that breaks the application and causes even more hassles for the developer team!

This is a key fallacy in presenting and proposing a project to a client – when somebody who has been designated  the “project architect” decides to do  everything “on their own” -- without prior consultation with the actual coders who will be tasked with building it—intelligent people  who can usually offer valuable input. This is “Ivory Tower” development proposal methodology, and it’s just wrong. Since when is the “architect” supposed to be the guy that tells the developer team how to handle their source control? I think that when people get into a position of “defending turf” – they can become extremely threatened by other people who question their authority, even in the slightest way.

Actually, I like this person – but it became “political” because I opened my mouth and said the obvious.  I don’t  care at this point;  I’m blessed because I’ve built up a substantial income with my eggheadcafe.com partner over the last nine years (to his credit, he seems to be able to put up with my idiosyncrasies just fine…).

When companies are stressed, managers often make bad decisions -- it’s the guys who are making six figures that get chopped first, even though they are often the people who can help the most – but only if they are asked to do so. I certainly was not asked.  If companies do not take concrete  steps to have a proactive policy of LISTENING to the people who will be  producing the product,  then  they will fail.   Managers  don’t always think logically – they are too often motivated by the concept of “protecting their ass” – and it degrades into  a political “good buddy network” process. I’m sure if you’re reading this post that you may have already been exposed to this.

When I see a process that’s flawed, I’m gonna speak my mind about it. When you stick to principles and do this, it may get you branded as a scapegoat and then you’ll be the first to go, illogical as it may seem.  So be it – I can sleep well now. I’m so relieved that I no longer have to spend 2 hours of my day driving into Orlando and back to put up with this B.S. every day.  Now I can focus on what I do best – writing good code and articles, making presentations, building the business. If I find another “day job” – you can bet I’ll choose it carefully.

The bottom line is, “To thine own self be true” --  I would likely have been out of there looking for a better spot  anyway. As a friend and co-worker said, “They have kicked out an excellent developer and team member”.  That’s comforting to hear, but in this case it just wasn’t working for me –-I now believe the company  actually did me a favor. Thank you! (BTW – here’s my current resume!)