Slashdot Mirror
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?
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.
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.
In speech it is easy to distinguish between the two meanings, but the difference is in intonation that doesn't translate directly to writing.
Right. Suppose I ask you if x > y, and you reply, "I think so." That sounds straightforward. But consider the way you say it. If you're 90% sure that x > y, then you'll say "I think so" quickly, in a higher-pitched voice. But if you're only 60% sure, then you'll say "I think so" slower, in a lower-pitched voice.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
At my last job, I spent three days coding up a solution which would save us days of work on every client-facing project. I had been thinking about the problem for a long time and saw a simple and elegant solution. It was ready to go, including testing and documentation. When I demoed it, folks were impressed.
Unfortunately, management had the idea that the way to contain costs was to have the Product division develop these kinds of tools. My division was supposed to focus on deploying Product’s solutions to clients, not build solutions ourselves. Management could see the value in my solution; they just didn’t like the fact that it had come from me, not from Product.
So I was told to write up a spec for the solution I had already implemented, and give it to Product to reimplement. I did that, but Product was notoriously slow and ineffective. They had way too many masters to serve, and they weren’t immersed in our day-to-day work to understand our needs.
Two and a half years later, the solution was still not rolled out. I was still trying to get Product to fix the fatal bugs in their crappy implementation. I had escalated it multiple times.
I ended up quitting that job in disgust. The case I just described was a symptom of a large and serious organizational problem; I kept running up against it. In my resignation letter, I did the math to show management how many hundreds of hours we would have saved by now if we had adopted my solution when I wrote it. I sent that letter around to a bunch of senior managers. There was a belated plea for me to stay, but I already had another job lined up.