How Developers Can Fight Creeping Mediocrity

Nerval's Lobster writes: As the Slashdot community well knows, chasing features has never worked out for any software company. "Once management decides that's where the company is going to live, it's pretty simple to start counting down to the moment that company will eventually die," software engineer Zachary Forrest y Salazar writes in a new posting. But how does any developer overcome the management and deadlines that drive a lot of development straight into mediocrity, if not outright ruination? He suggests a damn-the-torpedoes approach: "It's taking the code into your own hands, building or applying tools to help you ship faster, and prototyping ideas," whether or not you really have the internal support. But given the management issues and bureaucracy confronting many companies, is this approach feasible?

Comments

Re:Cycle of life

[justaguy516]

I was once working in a software company, doing maintenance on a product (an embedded telephony module) which was pretty much going to be end-of-lifed soon. It was one of the most enjoyable times of my career. There was me and two other guys, all of us junior engineers and no supervision whatsoever. We were able to make radical changes at our own discretion; I was a young man and didn't really mind spending nights and weekends working on that stuff. We got some things wrong, but we also fixed very very old bugs and re-wrote an entire module to test out some ideas we had about performance bottlenecks. The customer, who was basically running out the clock on warranty was somewhat surprised at all the releases he was getting, but didn't seem to mind. His test and field staff were actually quite happy.

The whole thing didn't put off the inevitable, because nobody in the company paid any attention to the fact that the product had actually been re-engineered into somewhat workable. In any case, there was no follow-up planned, so eventually the entire product line was closed down and the customer was migrated to something else. But we had fun while we could and learnt a lot.

This right here is the truth

[melted]

As a developer, you're typically not in a position of power. In large companies as long as you're obviously not going to leave, you're pretty much universally perceived as a cog. Sometimes as an expensive cog, but a cog nevertheless. The most power you can have is when you vote with your feet and go work elsewhere.

To a company this means they'll have to replace you with an unknown dude, who is difficult as heck to hire, and they'll likely have to pay quite a bit more money as well. So some tactical effort will likely be made to keep you (assuming you're valuable). This never leads to any kind of long term improvement though, so whatever irked you before this tactical last-ditch thing will continue to irk you in the future, and you should leave anyway.

Re:Why Fight It?

[AmiMoJo]

I get the impression that this is the prevailing attitude in the US. The company is just something that you use to get what you want, and the company treats you the same way.

My experience in Japan and Europe is that the better companies look after their staff and you end up feeling invested in them. You want them to do well so you make an effort to fix and improve things. Not all companies are like that, but some are.

My advice to the OP is to state their concerns clearly to management, along with solutions. Explain how things can be done differently and how it will benefit the company.