Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Businesses Programming IT

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?
This discussion has been archived. No new comments can be posted.

How Developers Can Fight Creeping Mediocrity

Comments Filter:
  • QMS (Score:5, Funny)

    by Anonymous Coward on Thursday July 30, 2015 @12:44AM (#50211965)

    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)

      by Opportunist ( 166417 ) on Thursday July 30, 2015 @02:39AM (#50212249)

      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)

        by Anonymous Coward

        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!

        • 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... :(

    • by Anonymous Coward

      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 !!

      • by epyT-R ( 613989 )

        Seems to be a common trend in a lot of software nowadays, especially with GUI design and forced obsolescence of local storage.

    • 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.

    • You've just invented a language with built in support for multi-processing.

    • 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

  • by Anonymous Coward

    ...pink slip

  • Why Fight It? (Score:5, Insightful)

    by Greyfox ( 87712 ) on Thursday July 30, 2015 @12:52AM (#50211981) Homepage Journal
    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.
    • by AHuxley ( 892839 )
      Yes, found your own brand or ensure you are indispensable within a huge brand. Long shifts, constant reports, just in time repairs, solutions, over time.
      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..
    • 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

      • They've made it abundantly clear that's not what they are paying you for, so oblige them, even going so far as to gleefully compound their organizational problems.

        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

    • by melted ( 227442 ) on Thursday July 30, 2015 @02:40AM (#50212259) Homepage

      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 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)

      by AmiMoJo ( 196126 ) <mojo@nOspAm.world3.net> on Thursday July 30, 2015 @04:07AM (#50212491) Homepage Journal

      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.

      • by Anonymous Coward

        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)

        by monkeyxpress ( 4016725 ) on Thursday July 30, 2015 @06:25AM (#50212861)

        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)

          by AmiMoJo ( 196126 ) <mojo@nOspAm.world3.net> on Thursday July 30, 2015 @08:22AM (#50213333) Homepage Journal

          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.

          • by Anonymous Coward
            And that's why it's so different in the US. The short term is all that matters to management, because once they've gotten their bonus for firing a few thousand people or shit-canning R&D, they're off to another company, so the backlash of poor long-term planning never catches up with them. You can't really expect much better when there's a much higher proportion of sociopaths in management relative to everyone else.
          • Oh I agree. But very few companies have the luxury of being able to remain solvent in the face of an attack by short-term thinking competitors for long enough to get those long term benefits. Japan is also not a good comparison as it has a unique cultural makeup that supports semi-dynastic companies. Have a read about the Zaibatsu. The allies tried to dismantle these after the second world war, but they largely reformed anyway. Very different from western capitalism.
      • by Anonymous Coward

        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.

    • by epyT-R ( 613989 )

      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

    • Why do humans feel it is necessary to "fight" our problems?

      We fight mediocrity, fight poverty, fight cancer, etc.

      Shouldn't we be looking for solutions to our problems, instead of fighting them?
  • by Anonymous Coward on Thursday July 30, 2015 @12:55AM (#50211991)

    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.

    • by preaction ( 1526109 ) on Thursday July 30, 2015 @01:36AM (#50212111)

      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?

    • by Anonymous Coward

      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

    • by jellomizer ( 103300 ) on Thursday July 30, 2015 @05:44AM (#50212753)

      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.

    • by epyT-R ( 613989 )

      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.

  • by Anonymous Coward

    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.

  • by Anonymous Coward

    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

    • . The end user doesn't know what they want, but you do. Make the decisions for them.

      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.

    • by epyT-R ( 613989 )

      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.

  • 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 secretarie
    • Re:Cycle of life (Score:5, Interesting)

      by justaguy516 ( 712036 ) on Thursday July 30, 2015 @01:50AM (#50212137)

      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)

      by rtb61 ( 674572 ) on Thursday July 30, 2015 @02:02AM (#50212167) Homepage

      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.

      • 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.

    • 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

  • by forgottenusername ( 1495209 ) on Thursday July 30, 2015 @01:11AM (#50212053)

    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

    • 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

  • 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.

  • by myid ( 3783581 ) on Thursday July 30, 2015 @01:28AM (#50212099)

    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.

  • Bravo (Score:5, Insightful)

    by lucm ( 889690 ) on Thursday July 30, 2015 @01:36AM (#50212113)

    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.

    • He re-wrote the entire front end ?

      Another ass-hat !

      Real developer fix existing code, and don't resort to a re-write except as a last resort.
    • by tomhath ( 637240 )
      Then, a week later he learned that someone else (who knew how to commit code) had rolled back his changes without telling him.
  • 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.
  • That's the difference between a developer and an innovator, you will only be supported when you succeed.

    • by Anonymous Coward

      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.

  • 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 t

  • 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).

  • 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)

      by Todd Knarr ( 15451 ) on Thursday July 30, 2015 @04:41AM (#50212583) Homepage

      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.

      • by gsslay ( 807818 )

        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."

    • 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

  • by kurisuto ( 165784 ) on Thursday July 30, 2015 @06:34AM (#50212885) Homepage

    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.

    • by Bengie ( 1121981 )
      This is where a good manager comes into play. My current and past manager would tell the other departments that if they could not do a good job in a timely fashion, we would do the job.
  • 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

  • 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

  • by mveloso ( 325617 ) on Thursday July 30, 2015 @08:34AM (#50213399)

    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)

      by Anonymous Coward
      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.
  • You can almost never change a company but you can change companies.

If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson