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.
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?
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.
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
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 !!
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.
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.
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.
Management knows more than I do about how to manage a business. I know more than they do about how to build technology.
Management is paying for the use of my brain. Good managers will give serious consideration to what their hired brains are telling them.
Of course, in any real-world situation, plenty of poor decisions come down, even if your management is pretty good. So when that happens, you have a few options:
1) You can follow orders, even though you know it's a bad judgment call; or
2) You can try to convince management differently (which sometimes works); or
3) You can do something rogue to mitigate the effects of bad decisions.
Anyone in a technical industry is regularly engaged in this balancing act.
I'd note that there is rarely a very clear dividing line between doing something rogue versus exercising judgment within the range of your own authority. There have been plenty of times when I've undertaken efforts which were neither authorized nor prohibited. I've never gotten in trouble for this. Of course some efforts get silently ignored, but others get adopted and praised.
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.
Entirely different situation. The question posed is more like "I'm a NASA engineer and I think we should be building a rocket to Venus, not Space Shuttles. So I'm just going to do that instead."
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.
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.
A programmer's productivity is relatively static. What's important is the quality of the code that allows the programmer to multiply the productivity of others. Code quality becomes very important as each layer of dependencies compounds the complexity of the system. 80/20 rules great until you're 3 dependency layers deep and 0.8^3 is only 0.5.
You can almost never change a company but you can change companies.