Monday, December 1, 2008

Success is Failure. Failure is Success.

My company just went through a major production release and the only good thing I can say about it is, "Thank God it's almost over - hopefully." It has been one emergency after another, each more critical than the last. The executive team sent out a corporate wide email congratulating everyone's hard work and dedication. They also claimed that it was a total success with only a couple of challenges left to resolve. Either they are incredibly naive, incredibly lied to or just crazy.

I am just a lowly developer but I consider a release that limits our customers ability to effectively work with our system a failure; a complete failure. As always I can't go into detail as to what went wrong but I can reflect and try to identify why.

First, a corporate culture that cultivates deception and evasion is BAD and will always end the same way; badly. How does a company encourage such fraud? Mistakes always have a cause, but it takes a healthy corporate culture to look for the root of the mistake instead of the mistake maker. People are more apt to divulge mistakes and issues if they feel that they will not be harassed incessantly. Lets face it, everyone makes mistakes, any honest person hates making mistakes, nobody wants to admit they made a mistake, but if you feel confident that your mistakes will not be used against you in a court of blame, you are willing, if begrudgingly, to admit them as soon as they happen. The company I work for is okay at not flashing the light of shame on mistakes but it still has a long way to go.

Second, a common, unwavering and attainable goal is vital to identifying success and failure. A common goal is necessary to map the course of a all but the most trivial corporate initiatives. Without a common goal you might as well be herding cats, that is unless herding cats is your goal. To get everyone in the company going in the same direction they must know what that direction is. A common goal is necessary so that everyone has an objective way of identifying how well they are doing, or how poorly.

An unwavering goal is necessary in the same way that a common goal is but for a different reason. A common goal gets everyone going in the same direction, but an unwavering goal keeps them going and gives them constant feedback of their progress. A goal that keeps changing, for whatever reason, be it a revaluation of progress or a change to meet market needs is flux, and goal flux in a major project is a killer. If everyday you come to work you spend time discovering where the capricious decisions of executives are, then you're never able to make a conscience assessment of your progress. Did all that work you did yesterday, or last week, get you closer to the goal; If you don't know what the goal is from day to day how can you ever know?

An attainable goal is one that all stake holders can agree on. If every goal, initiative and time line arrives to the masses from on high, why in the hell would you expect anything but peasant work? The people who are doing the work must have a say in what is and what is not attainable. I realize that every executive wants it yesterday, and every developer would work an eternity to improve a sort algorithm but that shouldn't mean that a reasonable agreement can't be made, and a reasonable goal can not be forged. While reasonable is in the eyes of the beholder, I don't believe that should negate an attainable goal. Attainable goals will probably never make both side happy, a project will always take too long in the eyes of management, and will always be impossibly short for the developers. A goal must, I repeat, must be negotiated between all interested parties otherwise it is a dictate that will end up being a very quick pile of crap or a very slow pile of crap, but in the end it will always be a pile of crap produced by a bunch of pissed off developers who have no skin in the game (Thanks Darren for that apropos line).

Third, waterfall is dead; long live waterfall. If you are fortunate enough to work for a company that is truly Agile, congratulations you lucky S.O.B. If you are like most of the IT slobs out there you are still stuck with the drowning waterfall methodology. If you can, and by God try as hard as you can, adopt as much agile as you possibly can within the constraints of the falls. I know, I know, the purists would have you believe that you are either Agile or you are not. I don't believe in such hard and fast rule. I'm stuck in the Niagra Falls of waterfall methodology but I still practive test driven developement, collective ownership and simple design. I've tried several times to get continuous integration incorporated, and thus far I haven't had anything that can be called success, but I'll be damned if that's going to stop me. With every project I am getting my group closer and closer to being Agile.

Finally, if any of this sounds familiar, well, I'm sorry, but you are not alone. There are plenty of people in exactly the same boat as you are. Don't give up, you got into IT because you love solving problems and boy howdy is this ever a problem that needs solving. Keep fighting the good fight and tell me how it went, good or bad. Good luck.

No comments: