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
...pink slip
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.
Just move on to another company.
Once management has set their failing course, there is little to stop the ruination.
Do what Apple does. The end user doesn't know what they want, but you do. Make the decisions for them. Don't be held back by the people that are buying your product. Charge a higher price for what you are offering, even if it doesn't have what your competitors are offering (most people think that if something is expensive, it has more value). Also, make your programs compatible with mice that have only one button, and if you sell your products on DVD or BluRay, you can sell the regular versions cheaply, but if you make certain install discs out of gold or platinum, you can charge 10-50 times as much. Also, produce everything "in house", using your own technology, no matter how shitty or defective it is. Your loyal customers (hahaha) will pay for these things no matter how terrible they are. Don't forget to let your customers know that they are too stupid to know what they really want. Remember, Steve Jobs knew how to make money, and you should follow his example. Sure, he didn't create Microsoft, but what do you really expect from someone like Jobs?
A mans comfortable self-loathing in well adorned mediocrity is not to be trifled with lightly.
All things are born, grow up, grow old and die, corporate citizens are not excluded from entropy. I guess you need to decide if you are a cell in the parent organism, destined to stay the course until the end. Or you're a bacteria destined to spread yourself and your progeny around to ensure your genome survives. Or your a virus destined to steal all the useful DNA and jump to a new host, whilst ensuring the ultimate demise of the old one. Or you could just go with the one that hires the youngest secretaries with the biggest tits.
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
A rogue as described in TFA prototypes, demonstrates, estimates the effort remaining, and gets buy-in. Getting the time comes from the same place where tech debt reduction comes from. In contrast, the cowboy pushes to completion and commits it.
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.
...then GO FOR IT!!
Short of burning yourself out, or closing off other opportunities, or wasting your energy on a project that won't help you increase your knowledge and skills, just take your implementation ideas and execute to the best of your ability! Almost any project can be transformed in to both a success and a great learning experience.
Ignore any negativity. Work around other developers if you have to, but remember that they're on your team, aiming for the same ultimate goal; so, if you can, try to win their support for your vision. If some people just won't collaborate on your vision, then secretly fork the code base, and continue to work in parallel with the mediocre version until your fork is essentially complete and demonstrably better in all respects (like correctness, reliability in the face of adversarial input, code clarity, maintainability by average developers, and speed). I believe you really need to clearly show the superiority of a solution, leaving no questions, even as days go by and people can consider the less evident, but crucial, aspects of your work (particularly, reliability in the face of adversarial input, code clarity, and maintainability by average developers; qualities which oftentimes aren't given the attention they actually deserve). If you do this, though, make a renewed effort to win the support from any developers who doubted your vision, to see if they will join your virtual team within a team, a day or two before debuting your work to management. Make it clear that you just think this design would be beneficial to everyone, and you'd like to give anyone the opportunity to buy in to it before presenting it. Meanwhile, anticipate that there might be negativity from colleagues, or lack of recognition of the virtues of your work from management, and keep an open mind about moving on to a new company. But, I really think that if you see an opportunity to do great work, and you know you could actually do it with the resources you have without exhausting yourself, and you think there's some chance that it will help other people (like fellow developers, or, even better, all of the end users!), then go for it. Yes, go for it! Do something awesome.
I wasn't exactly sure what he meant by "Chasing Features". Because building features into your product is often a good thing, it makes your product better. After reading the article, what he meant was, "We built features the users didn't want." Which of course is a problem.
His point has nothing to do with that, really. His point was, "instead of being a mindless drone, try to figure out how to make the company better." Good advice, poorly written article.
"First they came for the slanderers and i said nothing."
That's the difference between a developer and an innovator, you will only be supported when you succeed.
My ism, it's full of beliefs.
Quit
But how does any developer overcome the management
You don't. The most important question you can ask yourself is: what's in it for me? The answer more often than not is that there's nothing in it for you. Why work at something just so that others who contribute less will benefit more? The best thing you can do is find better employment that delivers you more return for your investment.
and most of our bugs are over seven years old! If getting paychecks wrong every month doesn't slow down new feature development, I don't know what will.
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.
Pruning the tree, so to speak. I regularly identify features that are candidates for pruning:
- Because they are disruptive in the code base (needing an inordinate amount of developer effort to keep them working in a changing environment, or because they make testing much more difficult, etc.)
- Because they are disruptive in the user interface (needing a lot of screen space while barely being used)
- Because they are disruptive in the user manual (if you cannot properly explain it, perhaps because it relies too deeply on internal knowledge, or because the set of conditions that cause the feature to work is just too large)
Some of these I propose to the customers for removal (I work on a rather specialized industrial application, so the number of customers is not that large). Others I break in a subtle way and wait to see if anybody complains. If they don't, the feature is gone in the next version.
Writing software is a lot like gardening. You shouldn't let your garden grow wild, it's ugly.
As the Slashdot community well knows, chasing features has never worked out ...
Those of us who have been here for quite some time already knew that fact, unfortunately Dice doesn't
They kept trying to turn /. into something that's totally incoherent, adding features which don't make any sense ...
Who suffers?
Everyone !!
you'll get fired.
Just stop working for these people, they have no business running a software business on nothing but buzzwords ignorance and gut feeling. Their just morons with money who like to play dress up.
Start your own business
They have controls in place that require executive approval of all changes. Any unapproved changes are a firing expense. So the little tuning changes we always used to do for "free" can't be done. Likewise, the changes won't be approved since by management point of view, there is no value to the activity since it is not a feature (this is true at small companies too- had a developer bend my ear on this issue literally today a few hours ago).
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
So the developers think they know better than the management what the company should be doing? OK. Four points.
1/ Welcome to the working life. Whatever the industry, the staff always think they know better than the clueless bosses.
2/ If the developers really know better than the management, then the company is doomed whatever they do.
3/ If the developers are wrong, then ignoring management and doing their own thing is a sure way to either get fired, or sink the company in a pit of missed deadlines, squandered budgets and undeliverable product no-one wants.
4/ Who do you suppose might have the greater amount of experience in the company's market?
Why would you do that? Your work will be sold for ten times what you get back, and if it does really well, you won't get paid more, it just means bonuses for the owners. So why the hell would you put all that effort into making a kickass product against the wishes of the owners of the business when the benefits of ignoring them go to the owners and the risk of being sacked is entirely on you?
When productivity and your wages went up together, there was reason to work harder. Since the late 70's, the productivity has gone up pretty much consistently,yet wages are flat and now even going down. It's even more like the "ruinous taxation" that rich fuckers whine about, except it is over 100% tax.
Yet when our work isn't resulting in more wages, it's made OUR fault because we're not increasing productivity enough to entice people to invest in job creation.
I THOUGHT THAT WAS THEIR FUCKING TITLE!!!!! JOB CREATOR! As if they're fucking creator of the frigging universe!
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.
Even "Blue Chip" companies like IBM are a pale shadow of their former selves. Microsoft has lost billions on failed acquisitions and "new technology" that never took hold of the market.
The point is, former success and profit are no guarantee of the same in the future. Companies come, and companies go.
Expecting to be employed by one single company for an entire career is a fools game in the internet age. The sooner you wake up to the fact that even if you do save a company from itself, you're not going to be appreciated nor rewarded for your efforts, the sooner you can start planning a career of moving from one interesting job to the next.
Anyone who is targeting the executive levels of business knows damn well they are going to get their next "promotion" by jumping ship for another company, leveraging their current skills and position as the experience needed for a higher level position. You just flat out don't get promoted into those positions by companies any more, because they don't want you to leave your current role if you're doing a good job. And if you're not doing a good job and are replaceable, they're going to replace you anyhow with someone who isn't replaceable, or they're going to farm out the work of your position to some agency that uses cookie-cutter staff to fill the role.
Companies don't owe you anything, and you don't owe the company anything -- especially not "loyalty."
Get over the idea of "saving" the company. Do your job, do it well, find a better position, and get the hell out while the getting is good.
I do not fail; I succeed at finding out what does not work.
> that drive a lot of development straight into mediocrity, if not outright urination
this may solve it: San Francisco's Public Works Agency Tests Paint That Repels Urine
This idea sounds great... do the right thing, convince management of your brilliance. Except, with the "agile process", particularly with scrum, you are managed almost minute by minute... certainly hour by hour. The only way you are going to have time to do any cleanup work, prototyping, etc is if you starting padding your estimates. If your manager is remotely good, he's going to smell a rat.
In general I like the concepts of agile... do things incrementally, rethink priorities, get early feedback. But it does tend towards micro-manangement and that can kill any chance you have to improve code.
That way you might still be a cog, but you're a cog paid somewhere between 50-100% more than the permie staff plus you don't have to put up with any of the political BS that you find in every company. Do your work, get paid, go home. Done. Ok, it has its downsides but in general I found the upsides outweigh them quite considerably.
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.
The software industry has fallen head first into rampant mediocrity, if not downright abysmal quality.
RE: Crap like this is why people around here hate Unions.
Right, because the slashdot geniuses all know that anecdotes trump data. Every time.
40 hour workweek. Safe worker conditions and overall worker safety. Weekends. Abuse and harrasment protections.Reduction in debt prisons and indentured servitude. (Now coming back. H1-B is not much more than a modern version of indentured servitude.) The list of union benefits goes on.
Fewer unions, like undocumented workers = more control and abuse by the management class. It's simple human behavior.
Yes, Unions, like every human organization, have their faults and issues and cases of abuse. They are also necessary to avoid complete domination of labor by management. On balance there is no better force, with a better mix of negotiation and violence, to offset the natural greed of the oligarchy.
management often only posses like it knows what it is doing. responsibilities are given. power is taken.
Any guest worker system is indistinguishable from indentured servitude.
Stop being mediocre.
Seriously.
Just stop.
Stop sitting around blaming bugs on everyone else.
Stop sitting around waiting for someone else to fix them.
Stop rushing your code to meet deadlines when you know the code does not work.
Stop accepting bad code just because your bonus depends on meeting a date.
Yes, management sucks at setting dates, but it is your responsibility as a developer to provide good code. If you do not have good code to provide, do not provide it. Period. Put something in your nutsack that resembles balls and do the right thing.
The business side doesn't know a for loop from their assholes so it depends on who ever is the bridge between business and tech. If this person just does the things described in the article and doesn't ask if they can do unit testing or apply a new framework etc. No one is the wiser. All the business side knows is they get products faster with less bugs.
You can almost never change a company but you can change companies.
I don't know about your management, but if I do a prototype, they take it and put it into production. So, everyone looses.