• olaf (unregistered)

    Oh my, what a slacker :(

  • (cs)

    Quality starts from the top down. If management comes from a used car lot "we only want sales" perspective then the rest of the company will act that way.

    Sadly, with pressure on money concerns, more and more companies will go this way. ... I hope they fail short term as well.

  • (cs)

    Sadly I've encountered a similar mentality. I was fired last July from a job because our "Larry" didn't like the things that I was pitching such as actually making good use of source control, having actual testing, and scoping the app properly instead of adding more work every time the boss wanted some new thing added to our current "sprint". Our CIO, unlike Lisa in the story, bought every word about how bad these things were from our Larry and got rid of me because my constant pushes for change weren't sitting well with him.

    The only thing that caught me off guard here was that management actually listened to the new guy's suggestions over "Larry" the senior dev, instead of telling him to sit down and shut up, if not firing him for wanting to change things. I think that outcome is more common in environments.

    It sounds though like everyone got what they wanted. Michael and Lisa, as managers, probably had no issues getting new jobs. Jeffery seems like a bright guy so he probably did well himself (probably for more pay too, and now he has lead experience). Even scumbag Larry got to keep his job and run the company into the ground without any of that high-falutin' modern development stuff, and since he's the manager now he can squash any newbie developer who wants to use source control or bug trackers.

  • Demos (unregistered)

    I really enjoyed this story!

  • foobar (unregistered)

    Isn't this called DevOps?

  • EvilSnack (unregistered)

    Mayhap we could start a couple other sites and name them The Daily PHB and The Daily Wally so that TDWTF can focus on code WTFery.

    facilisi: "I biss my songue, buss this facilisi has no docsor."

  • (cs) in reply to EvilSnack
    EvilSnack:
    Mayhap we could start a couple other sites and name them The Daily PHB and The Daily Wally so that TDWTF can focus on code WTFery.

    No no no. On the contrary. We need much more of this - even though it was a very sad story (I miss the part where the company goes bankrupt or something).

  • Truckers delight (unregistered) in reply to EvilSnack
    EvilSnack:
    Mayhap we could start a couple other sites and name them The Daily PHB and The Daily Wally so that TDWTF can focus on code WTFery.

    How about we just rename it to The Daily Shit that didn't Happen?

  • Sparticus (unregistered)

    I am Jeffery!

  • (cs)

    The sad part is that things will go downhill, and management will never know why...

    ... why, o Lord, is there such a vicious cicle of life and death cursing all IT projects? Is smart management just a legend?

  • Dave H (unregistered) in reply to Sparticus
    Sparticus:
    I am Jeffery!

    We're all Jeffery.

  • (cs) in reply to ochrist
    ochrist:
    EvilSnack:
    Mayhap we could start a couple other sites and name them The Daily PHB and The Daily Wally so that TDWTF can focus on code WTFery.

    No no no. On the contrary. We need much more of this - even though it was a very sad story (I miss the part where the company goes bankrupt or something).

    This! Stories are much more entertaining, and a bit educational too. To see oh-my-god-my-eyes-bleed code, I just need to Alt+Tab to my open IDE.

  • RFoxmich (unregistered) in reply to Y_F
    Y_F:
    The sad part is that things will go downhill, and management will never know why...

    ... why, o Lord, is there such a vicious cicle of life and death cursing all IT projects? Is smart management just a legend?

    Smart management is an oxymoron...or maybe just a moron?

  • Herr Otto Flick (unregistered)

    Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.

    Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

    They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

    I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

  • Derek (unregistered) in reply to Dave H
    Dave H:
    Sparticus:
    I am Jeffery!

    We're all Jeffery.

    I'm a Derek. Unlike Jeffery, Derek's don't run.

  • (cs) in reply to Herr Otto Flick
    Herr Otto Flick:
    I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

    I think you'll find that to most peoples understanding, if you're brought onto a project that is massively behind schedule, and you manage to create better code with less bugs, AND reduce your delay deficit, then you have delivered.

    If you'd like a mathematical analogy: -10 + 5 > -10 even though -10 + 5 < 0.

    You're one of those people who likes to blame the current administration of two years for mistakes made four years ago, right?

  • Ironside (unregistered) in reply to Herr Otto Flick
    Herr Otto Flick:
    Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.

    Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

    They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

    I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

    You are right. Sometimes dirty/hack approach is not just sufficient, but necessary. I can go into a job telling them I'll cut to the chase, get the project done faster as I won't be p***ing about with all the trendy fashionable shit like TDD and Agile.

  • (cs) in reply to Herr Otto Flick
    Herr Otto Flick:
    Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.

    Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

    They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

    I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

    No, it is a series of WTFs, but not on our skilled trio. First, it seems there was never a real estimate for the product. Second, they promptly started churning code without dev management, lead by a stupid senior dev. Third, they watched the whole thing go froim bad to worse, behind schedule and overbudget, only to 6-12 months later decide that some good management was needed. They called for it.

    If the good devs push for improvement, like source control, unit tests, proper testing and such, they're doing their job. The project was already doomed, and they only did what could be done to set things straight, even if only to see a slightly better project fall off the cliff. And even like this, it's still probably better this way.

    With Larry-like lead, if they ever manage to deliver something, will be some steaming pile of crap. It won't be documented, not tested, riddled with bugs and probably not backed up anywhere else. Sooner or later, their prod server would go up in smoke along with the whole single copy of their product, or simply it would grind to a halt, unable to perform maintenance, fix bugs or add new features. The client would start using and relying on a product that soon would give them lots of trouble. It would do more harm than good, either because it does not work properly, barely works or some sunny morning it simply stops to work.

    Do you honestly think this is a better outcome?

  • Bumkiss (unregistered)

    Sadly, by the time the end of this story came it was a lose-lose situation. Even assuming theyntried to make the best of it and retained Jeffrey instead of Larry, he would have had to do the role of team lead as well as all management work (because "management is 100% overhead" is usually bullshit) and would have burned out anyway.

  • (cs)

    It's never a smart idea to cut corners, even on a project that's behind schedule. Cheap hacks are never the answer. You triage the situation, set up a proper environment to facilitate better change, and then take care of the most critical issues as soon as possible (hacking if you have to but making strict notes to refactor later).

    People like Larry are a cancer on companies since they almost always have someone's ear, but are useless and ignorant of anything modern. Modern techniques make it so you don't fall behind schedule in the future, but if you ignore them and fall behind and then introduce them, the blame doesn't lie on the new things like so many clueless idiots try to pull.

  • McVyvian (unregistered) in reply to Derek
    Derek:

    I'm a Derek. Unlike Jeffery, Derek's don't run.

    Well, get up a tree or something!

  • (cs) in reply to Herr Otto Flick
    Herr Otto Flick:
    Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.

    Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

    They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

    I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

    So you're basically saying that proper QA, CI, SCV, etc. Are overhead which in turn will make any software project delivery longer. It's better to simply get your server running and start coding in it... yeah, try that in the real world to see how it ends. All that is simply stuff which software engineers made up so they would get a job.

    Anyway, starting this sort of project without a proper manager/project owner who knows how to deliver proper and maintainable software in time is ridiculous.

  • Pock Suppet (unregistered) in reply to Y_F
    Y_F:
    To see oh-my-god-my-eyes-bleed code, I just need to Alt+Tab to my open IDE.
    Oh, you must work here, too. Welcome to Hell.
  • DonaldK (unregistered)

    What... no comments yet about the Facebook bashing in the "story"? I thought they recovered well...

  • (cs) in reply to foobar
    foobar:
    Isn't this called DevOps?
    Nope.

    The stuff that Jeff was pushing (Source control, CI, unit tests, scripting) are all good DevOps tools and methods. The methodology that Larry was pushing is technically known as "Clusterfuck"

  • (cs)

    Got people like this at our place, fortunately none in management and in the minority at that.

    "What's the point of unit tests, I know my stuff works"

    "If I write a test then I'll have to change it when I change my code"

    "the problem with unit tests is that you need to learn a whole testing framework"

    "a testing framework, can you really trust that?"

    "Tests take too much time, we could be programming instead"

    They're the same group who don't trust WCF, Entity Framework, NHibernate, anything off CodePlex or the entire .net Framework for that matter. They'd rather use the framework they don't trust to reimplement other parts of the framework they don't trust.

    3 man months spent rewriting ADO.net, but not as well.

    Don't ask me how long they took building their own localisation component or how long it took someone to implement a SOAP service from scratch using only HttpWebRequest and string concatenation whilst ignoring WCF and any .asmx options.

    .net config files that don't actually contain the config, rather a single file path in appSettings to an xml file which contains the actual config. someone seriously asked me if I could migrate my WCF service config from web.config to the xml file, because "it's cleaner that way".

    fuck.

  • (cs) in reply to Herr Otto Flick

    The ship's sinking and there's a hole in the hull below the water line. Patching the hole is simply going to prevent us from delivering- we just have to bail out the water faster.

  • secundum (unregistered) in reply to Dave H
    Dave H:
    Sparticus:
    I am Jeffery!

    We're all Jeffery.

    I'm Jeffrey, and so is my wife.

  • (cs) in reply to JimLahey
    JimLahey:
    ... snip horrible stuff ...

    Oh god yes. It seems like every company I interview with is full of people like this. Use a mature tool that's been out for years to help us write better code? Nah we'll just use stored procs like it was 2000 and write our own data layer around ADO.NET. Unit tests? You mean poke around in IE, right?

    I can kind of see the different config files depending on what you need, but the rest is indicative of a lot of bad things and it seems like in Tampa those are the only places that exist.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Unit tests? You mean poke around in IE, right?

    I swear this happened to me: PHB: "Did you run unit tests?" Me: "Not yet." PHB: "Can you give me some screenshots while you do it?" Me: "Um... okay."

    I push the button to run unit tests, screencap the report, and send it along.

    PHB: What the hell is this? This is some programmer thing. I wanted to see your unit tests. Me: These are my unit tests. PHB: No, go do unit tests right- in IE.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I can kind of see the different config files depending on what you need

    I can't. Not when they hold things as complicated as boolean flags to turn application features on or off. Or connection strings and passwords, because they're no longer in a standard .config encrypting them like you easily can with a standard .config "would take too long". So they're in plain text.

  • (cs) in reply to JimLahey
    JimLahey:
    ObiWayneKenobi:
    I can kind of see the different config files depending on what you need

    I can't. Not when they hold things as complicated as boolean flags to turn application features on or off. Or connection strings and passwords, because they're no longer in a standard .config encrypting them like you easily can with a standard .config "would take too long". So they're in plain text.

    Ugh. Point taken. That's just ugly. I meant more like how you can have a ConnectionStrings.config or a Local.config for override settings.

  • (cs) in reply to JimLahey

    Especially because if you use a single config file (app or web) you:

    • Can build your own custom sections, allowing you to use an arbitrary data structure in the file
    • Benefit from XDT to transform the file between your deployment environments
    • Benefit from the standard encryption stuff, like you mentioned

    XDT can be used on other XML files if you want to customize your build process, but you might as well tie into the existing pipeline.

  • (cs)

    IMHO if you happen to come onto a project which is behind schedule, over budget, with a crap code-base, no tests, no CI infrastructure, and funding problems, you really don't have time for anything but the basics.

    Source control is the only bit of infrastructure with almost no cost and an instant payoff (honestly I don't even want to think about how people work without it, but anyway). It takes 5 minutes to install and it's already paid for itself the first time two people make a concurrent change to the same file.

    As for "teaching people how to use source control", anyone who professes to be a professional software developer in 2013 whilst not knowing how to use even a basic version control system like SVN will only contribute a net-loss to your project.

    My suggestion would be to immediately assign the offending individual a very important research project... Something to do with cat pictures and the internet.

    Other than that, unit tests and CI are time-consuming to establish, and (at least initially) do detract from the immediate objective of having something to sell.

    Sometimes you've gotta put commercial reality first. Once a project is that far down the track, refactoring it to be well structured, testable and automatically deployable is probably not a viable option anyway.

    Just hack and slash (in a professional and responsible way) to get some revenue ASAP, then do a complete rewrite for V2.

    Hey, i think this approach even worked for Facebook ;)

  • Herr Otto Flick (unregistered) in reply to Y_F
    Y_F:
    Herr Otto Flick:
    Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.

    Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

    They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

    I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

    No, it is a series of WTFs, but not on our skilled trio. First, it seems there was never a real estimate for the product. Second, they promptly started churning code without dev management, lead by a stupid senior dev. Third, they watched the whole thing go froim bad to worse, behind schedule and overbudget, only to 6-12 months later decide that some good management was needed. They called for it.

    If the good devs push for improvement, like source control, unit tests, proper testing and such, they're doing their job. The project was already doomed, and they only did what could be done to set things straight, even if only to see a slightly better project fall off the cliff. And even like this, it's still probably better this way.

    With Larry-like lead, if they ever manage to deliver something, will be some steaming pile of crap. It won't be documented, not tested, riddled with bugs and probably not backed up anywhere else. Sooner or later, their prod server would go up in smoke along with the whole single copy of their product, or simply it would grind to a halt, unable to perform maintenance, fix bugs or add new features. The client would start using and relying on a product that soon would give them lots of trouble. It would do more harm than good, either because it does not work properly, barely works or some sunny morning it simply stops to work.

    Do you honestly think this is a better outcome?

    If you can sell it, keep the company operating, keep you and your colleagues in jobs, then yes. Version 1 doesn't have to be perfect, but it needs to work, it needs to be delivered in time for the company to make money from it.

    Quality can come later down the line, if you obsess over quality whilst the company disintegrates around you, you've failed.

    As I've said, Larry is a tool. VCS adds a lot to a project, and doesn't really cost you anything. Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.

    You can always add the unit tests later, when the money is coming in. No money, no company, no development, no job. Show me the money.

  • Lord Crumb (unregistered) in reply to Derek
    Derek:
    Dave H:
    Sparticus:
    I am Jeffery!

    We're all Jeffery.

    I'm a Derek. Unlike Jeffery, Derek's don't run.

    But they are tasty.

    Sorry, that remark was in Bad Taste :-)

  • (cs) in reply to caffiend
    caffiend:
    As for "teaching people how to use source control", anyone who professes to be a professional software developer in 2013 whilst not knowing how to use even a basic version control system like SVN will only contribute a net-loss to your project.

    My suggestion would be to immediately assign the offending individual a very important research project... Something to do with cat pictures and the internet.

    I've seen so many people who have no idea of anything beyond comitting it's not funny. Ask about branches/tagging and you get a blank stare.

    It's not as bad as the anti-ORM/sprocs for everything crowd that seems more resistant to change, but still a bit ridiculous.

  • (cs) in reply to RFoxmich
    RFoxmich:
    Y_F:
    The sad part is that things will go downhill, and management will never know why...

    ... why, o Lord, is there such a vicious cicle of life and death cursing all IT projects? Is smart management just a legend?

    Smart management is an oxymoron...or maybe just a moron?

    Developers who think that way are the morons. Or at the least, the problem.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I've seen so many people who have no idea of anything beyond comitting it's not funny. Ask about branches/tagging and you get a blank stare.

    In a largish team, having a few (minority emphasized) members who aren't totally comfortable with the concept of branches and merges isn't the worst thing in the world. Just so long as they do atomic commits like "fixed issue #whatever", or "Implemented feature card blahblah" it's manageable, albeit annoying.

  • Lazy Boy (unregistered) in reply to Herr Otto Flick
    Herr Otto Flick:
    Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.

    And how do you test? clicking around in IE? Do you really believe that is faster and more efficient than unit tests?

    if you "test" say an insert, you have to manually enter the data and then manually look in the database if the data is actually there. Thats is never faster.

    I can live with not testing properties or setters and getters and not testing every single convoluted edge-case. But at least 1 test that checks the new method actually does what you want it to do with the correct input helps a lot.

  • (cs) in reply to caffiend
    caffiend:
    ObiWayneKenobi:
    I've seen so many people who have no idea of anything beyond comitting it's not funny. Ask about branches/tagging and you get a blank stare.

    In a largish team, having a few (minority emphasized) members who aren't totally comfortable with the concept of branches and merges isn't the worst thing in the world. Just so long as they do atomic commits like "fixed issue #whatever", or "Implemented feature card blahblah" it's manageable, albeit annoying.

    But in a small team (my main experience) it's ridiculous. You get one guy, usually as senior like Larry in the story, who pushes against it because he doesn't understand and doesn't want to understand it.

  • some pony (unregistered) in reply to Herr Otto Flick
    Herr Otto Flick:
    As I've said, Larry is a tool. VCS adds a lot to a project, and doesn't really cost you anything. Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.

    And in the time where you debugged the errors created in the first feature created by the second feature, you implement the third and fourth feature. It really does double or tripple the rate at which you can add (working) features

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    But in a small team (my main experience) it's ridiculous. You get one guy, usually as senior like Larry in the story, who pushes against it because he doesn't understand and doesn't want to understand it.
    If he doesn't wanna do it, you've just gotta find yourself a "Merge Victim". It sounds worse than it is. It's just a dude with a good diff tool who is good at eyeballing code, and is across what all the people are doing in their respective branches. That does sound like a job for the team lead...

    One bit of good advice tho, if you can be a Nazi about anything, ATOMIC COMMITS. Don't commit you're days work when you go home at 5, do it in 3 or 4 commits, each targeted at a feature. If it's done well, it can make the whole divergent branch thing a lot less painless. Plus, it's not retarded.

    Oh, and while we're on the topic of divergent branches, some prick who decides to do a global refactor->rename to correct something stupid like a spelling mistake in a variable name, annoying, but tolerable.

    BUT THIS FUCKING THING TAKES THE CAKE.

    Yeah, just re-arrange every method in the goddamn file, arbitrarily, then check in a 2 line change. Good luck finding what it was.

  • C-Derb (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    JimLahey:
    ObiWayneKenobi:
    I can kind of see the different config files depending on what you need

    I can't. Not when they hold things as complicated as boolean flags to turn application features on or off. Or connection strings and passwords, because they're no longer in a standard .config encrypting them like you easily can with a standard .config "would take too long". So they're in plain text.

    Ugh. Point taken. That's just ugly. I meant more like how you can have a ConnectionStrings.config or a Local.config for override settings.

    Could be worse.

    How, you ask?

    My current gig has gone bat shit crazy for SOA and decided that all configuration settings for all our numerous applications shall be stored in a centralized database accessed via a service call. It is working out great. I can page through all the production settings and see, in plain text, database connection information (usernames and passwords) for databases I didn't even know we had. The possibilities are endless!

    All because, you know, SOA is totally hip. Web.config is for suckers.

  • jon (unregistered) in reply to Herr Otto Flick
    Herr Otto Flick:
    Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.

    Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

    They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

    I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

    The way I read it, they were already behind and they were behind because of Larry. The new process sped things up and it was too little too late, but the people that sped up the process late in the game were the most expensive and first to go.

  • (cs) in reply to Herr Otto Flick
    Herr Otto Flick:
    Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.

    You can always add the unit tests later, when the money is coming in.

    Out of interest, have you ever heard the phrase "Technical debt"?

  • cliffhopper (unregistered)

    This sounds exactly like my last company, I ended up there after "Larry" took over.

    captcha: nibh, like cacao nibs, but better.

  • (cs) in reply to Vanders
    Vanders:
    Herr Otto Flick:
    Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.

    You can always add the unit tests later, when the money is coming in.

    Out of interest, have you ever heard the phrase "Technical debt"?

    Wouldn't surprise me if he didn't, or if he's one of those devs that keep putting off the technical debt (e.g. "We don't have time to refactor the code, the execs wants Feature X done in a month!") until the company experiences technical bankruptcy.

  • neminem (unregistered)

    I do kind of agree about unit tests. Sure, they're nice to have once they're working, but they are also kind of a pain to get working for anything even slightly complicated. I don't see a huge deal with only properly unit testing the truly critical parts of the system, if the goal is shipping a project that's already behind schedule. Testing: yes (you do have actual QA people on the team, right? If not, that's your bigger issue). Spending half your programmers' time writing tests for things that are most likely working, when they could be writing code? No. Save that for later. Not necessarily never, just not right now.

    But you do need a testing environment that is neither the production environment nor each developer's personal computer, and holy mother of frack would I not want to work at a place with no bug tracker and where nobody used any sort of source repository. There's no possible way those could inhibit work getting done (well, unless they were just terrible... forcing everyone to use, for instance, VSS, that would be a real wtf, ugh. But barring that... I can't even imagine working without the ability to diff my code against an arbitrary slice of history of the file, for instance. How did I once live without that?)

  • Rich (unregistered)

    This story nearly made me cry... Luckily enough I've never been in an actual situation like this, or I would have actually cried.

    CAPTCHA: venio Many venio(l) sins in this one.

Leave a comment on “Slacking Off”

Log In or post as a guest

Replying to comment #407129:

« Return to Article