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?
Find a way to have your customers demand that you develop your software under a QMS. One that is aligned with ISO 9001, 21 CFR part 820 and eudralex part 4 and GAMP 5 and you can have good process all day. In fact you will have 8x process per line of code, but you can't write shitty code or have shitty retirements
Just go somewhere that sucks less. The company you're working for (Doesn't matter which one, they're all the same) would butcher you for organs if they thought it would be profitable enough. I guarantee you their marketing guys are still trying to figure out how to put a positive spin on it. You don't owe them anything, and they don't owe you anything. They understand this quite well, and you need to do the same. If you don't enjoy the part of your relationship where you get to solve neat problems and write cool code, find a job where you do enjoy those things. Or at least one that gives you enough bread that you can swallow their shit sandwich.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
No shit, the company's going to die because an insane brogrammer asshole decides the codebase needs to cater to the whims of the twentysomethings who read about something neat on the internet. Then he burns through the development budget rewriting the code to fit the new paradigm while simultaneously failing to provide the deliverables.
Is going rogue feasible? Generally no.
It is one thing to help find better ways to meet your objectives, but if you don't have the support of your management, you better tune up your LinkedIn profile.
Find a way to get aligned with management objectives and give options. Speaking as 'the man', fighting the man will not get you very far in your job.
Learn to manage your boss. Google it.
The business side is why the company exists. When they add feature creep etc, it's generally because they don't really know what the customer wants and are trying to see what lands. They don't understand the cost of changing the design / refactoring. They tend to not even really understand how to tell if a time estimate is BS or not.
It comes down to trust and working relationships. The business side almost never bridges the tech side - it's up to tech folks to bridge that gap and help them understand. Often times they simply won't care.
Sucky but that's the way the industry generally works. There are a few bright spots but they're few and far between. However the attitude of "I'm going to be a lone hero and push this out!" is just setting yourself up for more frustration and failure. There's a quote - "in writing, you must kill your darlings". Same thing applies to softdev, be prepared to write elegant code you are proud of, only to have it rot away and disappear. Your options are basically;
1) stay professional, do your job, collect your paycheck
2) try to find some startup with ideals like fogcreek (when it comes to valuing individual developers)
3) simplify your lifestyle and financial requirements and write code for your own projects, do a little contracting or take a job in a different field
Regarding the "Damn the torpedoes" quote: According to this military.com article,
The heavily guarded bay entrance was filled with mines, then known as torpedoes. Farragut's cry of "Damn the torpedoes! Full speed ahead!" is now the stuff of legend, but it was also good tactics. All but one of the fleet's 18 ships passed safely through the channel ...
I heard a speech by a military historian, who said that "Damn the torpedoes!" did not mean "to heck with the mines, let's ignore them". The historian said that Farragut was cursing the mines, like he was saying, "Damn those torpedoes". Then he ordered his men to go full speed ahead, to get out of the dangerous minefield ASAP, before a mine blew up a ship.
So Farragut was being prudent, not reckless.
When I found out I couldn’t commit CSS without headaches, I rewrote the entire front-end.
Says the guy who bitches about unrealistic deadlines.
lucm, indeed.
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.
Quit
For companies is it not quite the same. Reliable older company treats it's staff and customers well. Along comes the psychopath vulture capitalist who works out they can buy the company for more than it is worth and the dress it up for sale by trading on trust while delivering cheap crap, getting rid of expensive stuff, wiping out after sales service and support and voila big profits for a few quarters until it all goes boom but then it has been sold by then.
Reality is companies pretty much keep going until the slick psychopaths take over all full of charm and bullshit and try to fill their own pockets for as long as possible until the company goes belly up as a result of their total incompetence beyond their skill and getting employed. They of course focus all their efforts on blaming everyone else for the problems created by the psychopaths.
Want to keep companies going longer, really easy answer, start testing for psychopathy before letting new executives in the door.
Chaos - everything, everywhere, everywhen
Unlike the rest of your snarky post, this part is most certainly true. An end user rarely knows what they want.
Of course, if you ignore what they say they want, you have to actually be able to deliver something that scratches that itch. Basically "fulfilling the exact spec from the user" is just the least culpable way of failing.
Your ad here. Ask me how!
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.
That is what it takes. Be ready to be reprimanded. Be ready to be fired and blamed for the problems you were trying to fix. Be ready for your former boss to immediately turn around and accept the credit for the fixes you worked so hard on in your free time. If you love the company that much, be ready to sacrifice your job to save it.
Just a word of personal advice though; don't do it. History is written by the winners.
That's not what the shareholders want. They are in on the pump and dump scheme, the last thing they'd want is to end it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
No, credit will be stolen from you if you succeed. That's the only thing modern idiot MBAs are any good at besides firing people to pump up stock prices.
Counter-argument: Obviously management knew much better than the engineers how to run the Space Shuttle program, so they were entirely right to ignore the engineers' warnings about how freezing temperatures would affect the SRB sealing rings on Challenger and how ice strikes would affect the leading edges of the wings on Columbia.
Seems to be a common trend in a lot of software nowadays, especially with GUI design and forced obsolescence of local storage.
This is the mentality that's made modern software easier to use for very simple tasks at the expense of making it a lot harder to do complex tasks (or simple tasks with different options). Today's answer to 'the customer doesn't know what he wants' is to strip out all the advanced settings and flexibility and give the user a fisher price turd. Fuck that.
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.
I work with an application where the VP of engineering burned 6 man-years on dynamically loadable plugins, a feature nobody IRL actually gives a shit about. It made the code unreadable, caused all kinds of work due to the total refactoring of the application, and caused performance to degrade tremendously.
In addition, it is practically impossible to tell what version of a plugin is correct or if it's loaded.
Why? Because he thought it was cool.
So, when developers tee off on upper management decisions that kill companies, I can swing right back on dumb engineering decisions that kill companies.
If the guy was a VP, he had already strayed too far into management to be much of an engineer. That's still a poor management decision.
All things are born, grow up, grow old and die, corporate citizens are not excluded from entropy.
The oldest continuously running company is Kongo Gumi; it was founded in the year 578. Not dead yet.
FWIW, there are 5,586 companies older than 200 years. Like the Stiftskeller St. Peter restaurant in Austria, which was founded in the year 803, or Sean's Bar, an Irish Pub, founded in the year 900. Even the U.S. has gotten into the act; Shirley Plantation is a farm founded in Virginia in 1613. A surprising percentage of them are alcohol related, although there are also a lot of hotels, confectioners, and other businesses.