How Developers Can Fight Creeping Mediocrity 133
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?
QMS (Score:5, Funny)
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
Re:QMS (Score:5, Insightful)
That's only true because you can't get ANYTHING done anymore. Of course that also excludes the creation of any shitty code. If you can't get ANY coding done, it can't be bad...
Re: (Score:2, Insightful)
Please mod up. Any shithead that throws up one of these frameworks as a solution shouldn't just be fired, they should be taken out and shot. These frameworks always get corrupted to sell more management process and wind up being worse than useless - they become destructive because you keep repeating the same shitty ineffective safeguard procedures and filling out more and more paperwork for more and more teams only to waste time and find you have none to actually build anything. FUCK!
Re: (Score:2)
Please mod up. Any shithead that throws up one of these frameworks as a solution shouldn't just be fired, they should be taken out and shot.
Sadly, they usually get promoted to project management... :(
Re: (Score:2)
Ain't they on vacation now? Weld the doors shut and hope for the best.
We already knew that ... (Score:1)
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 !!
Re: (Score:3)
Seems to be a common trend in a lot of software nowadays, especially with GUI design and forced obsolescence of local storage.
Re: (Score:2)
In fact you will have 8x process per line of code, but you can't write shitty code or have shitty retirements
Sure you can, as long as your process specifies such things.
Re: QMS (Score:2)
You've just invented a language with built in support for multi-processing.
Re: (Score:3)
Good call - you cant' write shitty code if you're stuck in meetings all day. ;)
In all seriousness though, there is a solution against featurization:
1) maintain main product as usual w/ a team dedicated to it.
2) build plugins and/or add-on packages for it that incorporate the new features that management craves. Charge some small nominal price to cover dev costs and maybe a few pennies above that.
3) if the add-ons or plugins really sell (or at least have a ton of demonstrable interest), you incorporate them
Enjoy your... (Score:1)
...pink slip
Why Fight It? (Score:5, Insightful)
Re: (Score:2)
If the company is getting a lot of no bid government work why change the system? Thats years of quality pay for running around trying to keep the contracts, working with consultants, networking, making friends..
Re: (Score:1)
Related- why the hell would you want to innovate at a place that looks unfavorably upon independent thinking? The absolute best thing that could happen is for that business to die a flaming death, consumed by their own ineptitude and bureaucracy. Taking matters into your own hands only extends their reach, propping up their inefficiencies to suck the life out of even more people.
Mooch a paycheck if it is the only thing available, but definitely keep your best work under wraps. They've made it abundantly cle
Re: (Score:2)
Don't go that far. Intentional sabotage due to dislike might be emotionally satisfying but also both illegal and morally wrong.
Also, bad organizational cultures are so destructive because they slowly become the invisible default against which everything is judged. And they become invisible by encountering no resistance from those who can see them
This right here is the truth (Score:5, Interesting)
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.
Become a contractor (Score:2)
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.
Re:Why Fight It? (Score:5, Interesting)
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.
Re: (Score:1)
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.
It goes a bit further than that. In Japan and northern Europe some companies are more or less extended family, or at least there is a reasonably close friendship between workers and management. While you might be replaceable it isn't something that necessarily is expected.
While the situation has slightly changed the last couple of years it's not surprising if someone starts at a company when they are very young and works their entire life to retirement there.
Re:Why Fight It? (Score:4, Insightful)
This is true, but the problem is that our economy is not setup to care about compassion. Just look at the continuing problems in the Bangladeshi clothing industry. People are generally aware of what is going on, but in the end they still buy the clothes from Primark (that they don't even need). People just don't really care and so the company that skimps on worker compassion wins out in the end.
The only reason industries like technology are insulated from this sort of harsh reality is that there are still lots of tech companies that make obscene profits, so they can afford to pay workers good wages and absorb some inefficiency while keeping shareholders happy. However this does not characterise the whole tech market, and there are certainly areas now that are coming under ruthless competition.
Capitalism has always been a race to the bottom limited only by the extent to which society accounts for externalities, like paid vacation time or limited work hours. Otherwise you eventually just get the crazies on the margin dictating how the majority must work. It is really madness, especially now that the economy is largely generating pointless jobs through the whole legal/advertising/corporate industries.
Re:Why Fight It? (Score:4, Informative)
Japan has the most long-running companies in the world. Treating your workers well is essential for keeping the company going for decades, although tends to result in lower profits in the short term.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Perhaps I'm ignorant but what European companies have innovated like facebook, twitter, square, nest, etc. I'll take the trade-off of easily leaving your job to take your ideas into a new environment over investing one's life with a current employer. Simply put, loyalty can stifle innovation because successful firms have a vested interest in not rocking the boat.
Re: (Score:3, Insightful)
Re: (Score:2)
Okay, so whyTF did the company decide to fire the guy without going through the agreed-on procedure? The union may have had good reason to fear arbitrary firings (people are fired for illegal reasons all the time), and written consultation on firing into the contract. Instead, the company decided that it was more convenient to break the contract they signed rather than comply and take further steps if the union didn't do the intelligent thing, and that's the union's fault?
Unions have caused abuses, alt
Re: (Score:2)
Because Mr. Someone living Somewhere never lived anywhere, or existed for that matter. It's just an urban legend someone decided to believe because it confirms their political beliefs.
Re: (Score:2)
Yeah, but I found the urban legend offensive. The fact that GGP thought I might be influenced by a stupid made-up story that would be obviously irrelevant anyway is an insult to my intelligence. If you're going to lie to try to convince me of something, give me a little credit and make it a plausible lie.
Re: (Score:2)
They aren't trying to convince you, they're trying to confirm their beliefs. They're making a big show about believing absurd propositions because they think - rightly, in all likelihood - that they'll be rejected by their peer group if they deviate from its dogma, and also because they get ecstasy - feelings of transcendence - when fighting their chosen enemies. That's the downside of secularizat
Re: (Score:1)
Kinda hard to do at this point since, as you say, they're all the same. Finding a job where you can 'do what you love' is also bullshit. Employers want to turn creative endeavors into life sucking factory work that can be done by migrants for pennies. I suspect we're already suffering from it considering all the stupidly designed software coming from the big players. I remember a time where software from the giants might have had bugs, and the occasional design blunder, but otherwise worked well enough for
Re: (Score:2)
We fight mediocrity, fight poverty, fight cancer, etc.
Shouldn't we be looking for solutions to our problems, instead of fighting them?
Software engineer fails to understand business (Score:5, Insightful)
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.
Re:Software engineer fails to understand business (Score:5, Insightful)
And then this developer blows away existing code supporting existing users because they truly believe that the team is catering to the wrong users (despite those users being both more numerous and more lucrative), leaving them to find another solution, destroying the team from within. No, I've never seen that happen, why?
Re: (Score:2)
There is a risk to profit sharing as well. As your paycheck is linked to the quality of the others. Bad sales or marketing dept can fail to sell the best of ideas, and hard work.
In the mean time you are working with below average salary.
Re: (Score:2)
Re: (Score:1)
Yup, narcissism rules the day for this guy.
When I found out I couldn’t commit CSS without headaches, I rewrote the entire front-end. There were dozens of ways I could have dealt with this problem, but I chose to rework the entire codebase because this particular solution solved future problems as well as current ones. If I didn’t care about Responsive Web Design or prepping the code to be more flexible and capable of handling the use-cases that future stakeholders might have, I could have just c
Re:Software engineer fails to understand business (Score:5, Insightful)
If programmers are left to their own devices, no code will ever get released, because complex systems have too many variables to test, take a long time to code, by the time you get to the end you realized you could have done the beginning better.
There are so many times I go back to my old code and say to myself what was I thinking? There is a much easier way to do this.
Sometimes it is cheaper to leave the bloat and use more hardware to compensate.
I have a lot of half done apps in production. There are thing I want to do to make them better, however I probably won't get to them by EOL because the customer is generally happy with it, and I have other higher priority projects in my queue.
Re: (Score:2)
That's true, especially in GUI land. Another example is an insane customer who read about some bullshit paradigm on the net and wants his project to use it, even though it makes no sense, will cost more, and kill performance.
No (Score:2)
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.
Solution: (Score:1)
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
Re: (Score:3)
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.
Re: (Score:2)
Talk to the users about the problems. Talk to a User Experience designer about the features to solve those problems. Talk to a developer to implement those designs. Programmers are too analytical to solve the problem in a way that makes sense to the average user (which is why so many of the older programs were deemed difficult for lay people to use). User Experience designers do a lot of A/B testing to figure out what visual metaphors make sense to the users with guidance about what A and B can be from
Re: (Score:2)
Re: (Score:2)
If you're working on a solution for a user problem, then, yes, the user knows at least what the goal is. That's not how Apple became that rich.
Suppose Jobs noticed people with MP3 players and asked them what they thought would be better. They wouldn't have described the iPod. If he'd asked people with smart phones, they wouldn't have described the iPhone. The iPad is somewhat different, as I've seen a lot of similar concepts floating around (Star Trek, for example), but a focus group concentrating on
Re: (Score:3)
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.
Cycle of life (Score:1)
Re:Cycle of life (Score:5, Interesting)
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.
Re:Cycle of life (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:2)
There is still such a thing? I thought they have become a piece of our mythical history. Like work ethics, or customer service.
Re: (Score:3)
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
Great - except for one thing (Score:3)
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
Re: (Score:2)
Re: (Score:2)
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.
In my experience, this tends to happen when marketing gets involved in the design process, and starts asking for previous_product++. One of the reasons Steve Jobs was so effective is that he understood the technical side of things well enough to help make design decisions.
They tend to not even really understand how to tell if a time estimate is BS or not.
The best way to get good at estimating is doing a couple of fixed price contracts that end up working out to you making less than minimum wage. Then you either get good at estimating, or you go out of business.
All managers who've worked
Rogue != Cowboy (Score:2)
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.
The "damn the torpedoes" quote (Score:5, Informative)
Regarding the "Damn the torpedoes" quote: According to this military.com article [military.com],
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.
Re:The "damn the torpedoes" quote (Score:4, Interesting)
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.
Bravo (Score:5, Insightful)
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.
Re: (Score:2)
Another ass-hat !
Real developer fix existing code, and don't resort to a re-write except as a last resort.
Re: (Score:2)
Re: (Score:3)
Chasing features (Score:2, Redundant)
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.
You will never be supported (Score:2)
That's the difference between a developer and an innovator, you will only be supported when you succeed.
Re: You will never be supported (Score:2, Informative)
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.
Quit (Score:2)
martyrdom. (Score:2)
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.
Remove features as well (Score:2)
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 t
Re: Remove features as well (Score:1)
Not going to be feasible at a publicly traded cmp. (Score:1)
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).
Who knows best? (Score:1)
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, squan
Re:Who knows best? (Score:4, Insightful)
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.
Re: (Score:2)
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."
Re: (Score:2)
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
Why I quit my last job (Score:4, Interesting)
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.
Re: (Score:2)
Nothing lasts forever (Score:2)
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 goi
good luck with that if you do agile / scrum (Score:2)
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
Fuck that: most developers are customer-ignorant (Score:5, Insightful)
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.
Re: (Score:2, Informative)
management (Score:2)
Developer unfriendly companies (Score:1)
Re: (Score:2)