back to article Greatest threat facing IT? Not the latest tech giant cockwomblery – it's just tired engineers

Bid farewell to the festivities of the weekend with a story of self-inflicted pain in our weekly Who, Me? column. "Don", as we shall call him, was reminded of his own database-related dark night of the soul by our recent tale of telco terror. He got in touch to confess all to the sympathetic vultures of The Register. Don had …

  1. Sir Runcible Spoon
    Thumb Up

    Not his fault

    Totally the fault of the people piling on the pressure, but well done for doing the honourable thing.

    You really learn what you're made of in situations such as this. Anyone who hasn't created a fubar of this magnitude just isn't trying hard enough.

    1. Stonehauler

      Re: Not his fault

      This is exactly right.

      Even the best people make mistakes. When we pile on over work, being tired, high stress, and time pressure, it just increases the number and severity of mistakes. Unfortunately, bosses typically "blame the human" rather than admit that it's either the schedule they forced on the team, or the lack of resources they game to ensure the project could be completed at the anticipated time. The person took a shortcut. Why? Because of the time pressures and schedule forced on him. Had they been working 40 hour weeks and had a reasonable deadline, all the appropriate processes and procedures would have been followed.

      1. Anonymous Coward
        Anonymous Coward

        Re: Not his fault

        Some years ago I had the job of working through a large set of approvals documents ensuring they were correct and up to date. I passed it on to a relatively junior member of staff with strict instructions that he was to take frequent breaks and not work outside office hours, while I would do a sample audit.

        I then got a complaint from the MD that one of my staff was, as he put it, arsing around on company pay.

        I respectfully pointed out that a mistake in one or two places could cost tens of thousands of pounds,to which the MD's brilliant response was "then tell him to concentrate harder."

        This from a man who regularly had to work overnight before submitting the next year's budget to the group, to try and catch all his careless mistakes, to the extent that the FD eventually gave in his notice.

  2. Blockchain commentard
    Joke

    70 hour week for 3 weeks. Ah, the luxury. When I were a lad....

    1. big_D Silver badge

      I can remember a month of 80+ hour weeks to get a project released (and driving an additional hour and a half to the office each day, and back home again). I was in a daze by the end of the month, but the project was released on time.

      I then took 3 days off and slept for over 30 hours! My tax bill that month was also more than my normal gross salary!

      1. Anonymous Coward
        Anonymous Coward

        I think I billed a little over 350 hours one month

        Unfortunately as a consultant I didn't get OT, but sending in an invoice for over $50,000 was pretty sweet!

        The funny thing was that probably 75% of this time was not really work. I was fine tuning a complex script to do replication of an SAP instance (for a upgrade/replacement SAP environment that was soon to go live) from production to a remote site for DR, which would then create another replica and give it a new identity to work as a reporting instance. We were so far on the bleeding edge of EMC's offerings at the time and running beta firmware there was a bug in SRDF caused by the then-new technology of striped metavolumes that made it take a very long time to complete.

        Which meant that every time I made fixes to the script and re-ran it I had to wait several hours to see the results. Several hours of billable time, where I was surfing the web when I was in the office or watching TV when I was in my corporate apartment or back at home (connected by dialup, wheeeee!)

    2. chivo243 Silver badge

      In another life, in another industry, 65 hour weeks were the easy ones...

    3. Prst. V.Jeltz Silver badge

      Right. I had to get up in the morning at ten o'clock at night, half an hour before I went to bed, drink a cup of sulphuric acid, work twenty-nine hours a day down mill, and pay mill owner for permission to come to work, and when we got home, our Dad and our mother would kill us, and dance about on our graves singing 'Hallelujah.'

      1. Sir Runcible Spoon

        Not quite the quality Vogon Poetry I was expecting

      2. WonkoTheSane

        You were lucky!

      3. Michael H.F. Wilkinson

        And the problem with the kids these days that if you tell them how things were they don't believe a word you're saying

      4. Anonymous Coward
        Anonymous Coward

        Best comment thread

      5. Stevie

        ... singing 'Hallelujah.'

        Y'soft southern jessie etc etc.

      6. Colemanisor

        You were LUCKY!

    4. ElReg!comments!Pierre

      In a previous life it was more like 80 hrs for each working for 12 years straight (and barely any vacation at all). I've taken more days off in 2018 than in the previous 6 years combined ! Yay for carreer changes.

      1. chivo243 Silver badge

        +1 !!

        Yay for career changes.

        yes, it was a welcome change.

    5. NoNBNforMe

      Back in the day, working on a large construction site in middle of nowhere in Australia, our standard hours were 12 hour days, 13 days a fortnight. Typically worked 4 weeks on, one week off. During a busy period, I managed 12 weeks without a break. While the work was hard, the money was good.

    6. Anonymous Coward
      Anonymous Coward

      These days forty hours a week sounds a bit much. I'm thinking about moving to four-and-a-half days a week (ie Friday off every other week). No point in putting myself out just to make money for someone else.

  3. big_D Silver badge

    Been there, done that...

    We had an Essbase OLAP cube. Back in the day, Essbase couldn't calculate a full cube, or rather it could, but it took bloody ages! (In a cube with just bottom level data, it took an hour to caluclate, to re-calculate a filled cube, it would need 8 hours+).

    So, obviously, the standard procedure was a bottom level export, clear, import bottom level, calculate, job done.

    Only, I got distracted and started at step 2! I sat there with a P45 flashing before my eyes. I was new on the project and I asked a colleague who had been on the project for a couple of years what the procedure was. His answer wasn't very helpful: take the previous export, load it up and blame the missing data on the users!

    Instead, I went to the finance director, explained that we had a mishap with the process and I would have to load up the previous export and re-run the journal and it would take longer than usual. He okayed it and I informed the users that the "re-calculation" would take 2 hours, instead of 1.

    The journal file worked, we re-calculated and the users were told to double check their last edits. We lost seemingly 2 transactions.

    Honesty works.

    1. Rich 11 Silver badge

      Re: Been there, done that...

      Honesty works.

      Seconded. A cover-up is much more likely to get you fired.

    2. Will Godfrey Silver badge

      Re: Been there, done that...

      Anywhere that it doesn't, you're better off out of.

  4. swm Silver badge

    Estimating Software Projects

    I always found it hard to estimate how long a software project would take. My general rule of thumb was to multiply my estimate by 4 to get a believable number and then multiply by 4 again.

    Back when I was a student (> 50 years ago) to get time on a mainframe you had to work the midnight shift but then you got the entire mainframe to yourself. I got the entire executive for a time sharing system working (sort of) and then realized that the result was a mess. I then had to convince the powers that be to scrap the entire system and try again. The second time went faster, of course, and was much smaller.

    That was the time when writing software was fun (and I was much, much younger).

    1. big_D Silver badge
      Facepalm

      Re: Estimating Software Projects

      Yes, back then you wrote reams of code (Assembler or COBOL anyone?) and you really felt like you had achieved something.

      I still get some of that with modern languages, but these days a lot of it is just threading together a bunch of library calls. A lot of it is rinse and repeat using templated code, which just isn't the same.

      My first day at college was great. We had to write a simple program to calculate the minimum number of coins a person would receive in change. A task that took all of 10 minutes. What to do with the remaining hour of the class? We were using PETs and I had used them at school, so I just bashed in some machine code to draw a border around the screen, split it in 2, display the input amount in 8x8 graphics at the top of the screen and draw little piles at the bottom to represent the change.

      The lecturer looked at my screen and said "wow, I didn't know you could do that with a computer!" Oh, boy, and I was the one there to learn something!

      1. Blane Bramble

        Re: Estimating Software Projects

        Sounds a bit like a Z80 assembler course I was on, already knowing how to use it. So tasks like "write a sub routine to beep the console 3 times" became "use the most esoteric instructions and logic to beep the console 3 times" - jumps by pushing addresses on the stack and returning to them, using the index registers, that sort of thing.

        1. el_oscuro

          Re: Estimating Software Projects

          Did you overwrite EIP and get a reverse shell too? I think I did once... by accident.

    2. jmch Silver badge

      Re: Estimating Software Projects

      "multiply my estimate by 4 to get a believable number and then multiply by 4 again."

      The thing is that with most IT-related projects there are a great deal of 'known unknowns' and also usually a bunch of 'unknown unknowns'. PHBs insist on getting an estimate so we end up having to pull a number out of our arses and multiply by whatever to build in some breathing space, but the reality is that part of the project you know will take X, and the rest of the project time cannot be estimated.

      X + undefined = undefined, and undefined multiplied by whatever is still undefined.

      All IT practitioners know this dirty little secret, the managers who have worked at the coalface know it and go along with the charade. Bosses who have no idea do not want this explained to them or simply refuse to accept this reality and insist on a number. And the charade goes on...

      1. Sir Runcible Spoon

        Re: Estimating Software Projects

        In my opinion MS Project is a big culprit in all this. It's great at tracking amount of effort required for tasks, but most PM's struggle with the dependencies and the 'elapsed time' element (for which you have to map all your resources - and if they aren't 100% on your project it's even harder to track).

        So that 1 hour change that is on the critical path might not get done until next week.

        1. Long John Brass
          Thumb Up

          Re: Estimating Software Projects

          Spent some time with a "newbie" PM when she asked me for some advice

          Told her the following...

          Techies tend to underestimate the time taken to do a thing (So add extra time to the ETA)

          Techies tend to procrastinate (So don't tell them they have the time you've allocated)

          Management always thinks things are quicker, easier then they really are (Convince them early on an extended timeline)

          If a given task is completed earlier than expected; Don't shrink the timeline (you will need it later)

          Things *WILL* go wrong eating into your timeline (Use the slack from above)

          Techies can be bribed with food :)

          Every project I worked on with her as a PM, came in either on-time or early and usually under budget

          It helped that she was detail oriented and fastidious about keeping shit organised, kind of person.

          A true joy to work for/with

        2. Anonymous Coward
          Anonymous Coward

          Re: Estimating Software Projects

          As a PM resource management is a basic skill, any PM who has an hour long task on his critical path who hasn't secured the resource for at least half a day on an agreed date before he finalises the plan isn't a PM. Its not uncommon to have activities like this whether a key resource is only available at particular points or work specific shift patterns. that's what task constraints resource calendars are for. Project isn't perfect and the more complexity you have to use the more maintenance the plan takes but in a complex project I've yet to find a better tool.

          I Started life as a dev then went into tech support then tech management before becoming a PM I've managed developments in Cobol, Oracle, .Net, SQL Server just about every variation of C, Ruby on Rails Java and now Azure and the estimating problems don't change. Its not rocket science. If you cant estimate the whole product break it down to the stage where you can estimate the time for individual components. If you can't break it down to that level we have a research piece to schedule into the project before we can come up with a delivery plan the a set of design tasks to complete long before we get to write any code. If any dev is looking at a brand new new toolset and thinking I'll just start hacking code for a real project then that project is doomed

      2. Alan Brown Silver badge

        Re: Estimating Software Projects

        > and also usually a bunch of 'unknown unknowns'

        Yup, such as when a vendor "can't duplicate" a bug(*) you've been spoonfeeding to them - because they insist on trying to replicate it in a totally different OS (macos) to the one you're using (linux) and different authentication schema (local users vs LDAP) - and keep repeating the same mantra no matter how many times you point out that their "It works for me" is comparing Applies to orange juice.

        (*) Not so much a bug as a software module that's entirely broken from the ground up and the people responsible are dodging accepting the blame whilst their management look on, not realising that newer Linux distro rollouts are going to show this particular dain bramage(**) up in spades.

        (**) Otherwise known as "we're going to fuvk your security up, in exchange for gaining small amount of programmer convenience"

        1. Anonymous Coward
          Anonymous Coward

          Re: Estimating Software Projects

          > Clang and Apple?

      3. JLV

        Re: Estimating Software Projects

        >there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know.

        You know, I hate Rumsfeld passionately, along with Cheney. But I always thought, in this specific instance, he got a bum rap for what’s a pretty deep, if awkwardly phrased, observation.

        1. Anonymous Coward
          Anonymous Coward

          Re: Estimating Software Projects

          Its too bad he only considered that in the face of lacking sufficient evidence of Iraq's WMDs and not in the face of how difficult it would be for the invasion to be as easy as the neocon regime changers believed it would be. All those known unknowns and unknown unknowns eventually produced ISIS.

          Now we wish for someone as smart as Rumsfled in the Trump white house, and instead we get the worst neocon of all, John Bolton, and he's hot and bothered to make the same mistake with Iran.

      4. A.P. Veening Silver badge

        Re: Estimating Software Projects

        Bosses who have no idea do not want this explained to them or simply refuse to accept this reality and insist on a number.

        That is the same kind of boss, that thinks that because one woman can produce one child in nine months, nine women together can do it in one.

    3. Loyal Commenter Silver badge

      Re: Estimating Software Projects

      My general rule of thumb was to multiply my estimate by 4 to get a believable number and then multiply by 4 again.

      Don't forget to double that number before giving it to the sales droids, so that it ends up the same when they halve it to make themselves look good in front of the client.

    4. ButlerInstitute

      Re: Estimating Software Projects

      A colleague in a former job told of a Project Manager he'd had at a previous job who would take all estimates from developers and multiply by pi. Which apparently got reasonable results.

      When the developers discovered this they would do the pi multiplication themselves. Then the PM would multiply by pi again, and again got the reasonable results.

    5. Robin

      Re: Estimating Software Projects

      "My general rule of thumb was to multiply my estimate by 4 to get a believable number and then multiply by 4 again."

      When calculating an estimate, I was advised by my first manager I ever had to think how long it would probably take, then double the number and increase the time unit by one (e.g. 2 days becomes 4 weeks)

      At the time, I thought he was joking...

      1. Norman Nescio Silver badge

        Re: Estimating Software Projects

        When calculating an estimate, I was advised by my first manager I ever had to think how long it would probably take, then double the number and increase the time unit by one (e.g. 2 days becomes 4 weeks)

        At the time, I thought he was joking...

        Perhaps we had the same manager? It was certainly a realistic measure for the projects I witnessed - the only problem being that that particular estimation method was known, and manglement did their level best to cut estimates back to the number first thought of, which almost invariably ended in tears.

        I also had the misfortune to work for a manager notorious for his "5-minute" jobs, which generally took 5 days. He felt that his work was done conceiving of an idea and implementation was not his problem, and so 'trivial'. To be fair, as a mere underling, I had to do things like submit requests into the change management process, which required niceties like documentation, test results, and review by the change management team, whereas, as a manager he simply bypassed administrivia decades before 'agile' was a concept.

        But yes, double the time required, and go up to the next 'order of magnitude' : minutes to hours, hours to days, days to weeks, weeks to months and months to years seemed to work very well.

        1. Alan Brown Silver badge

          Re: Estimating Software Projects

          "a manager notorious for his "5-minute" jobs, which generally took 5 days."

          We have a lot of those - where the job might actually be 5 hours - but getting to it might take 5 weeks.

        2. J. Cook Silver badge

          Re: Estimating Software Projects

          The manager I refer to as "el turkey" thought that everything took two weeks.

          Implement a remote access system from scratch using technology never used in house, and with no one trained on it? two weeks.

          Replace the entire infrastructure of a multi-property, high transaction network stem to stern with zero downtime to the business? two weeks.

          He other claim to fame was 'I did this at my last job and got it running in half an hour', which was horse hockey and he hit his rev limiter on the backpedal meter when I call him out on it during week 3.5 of the remote access system implementation... (which never worked properly, and got scrapped in the first month after his replacement was hired with the solution we had been using, but a different idiot network manager had let support lapse on. I had *that* up and running about an hour after getting the hardware racked on on-net...)

      2. el_oscuro

        Re: Estimating Software Projects

        I have a similar policy:

        Estimate=actual_work^(time_unit*2)

        So 1 hour becomes 1 week, 2 days becomes 2 months and so on.

        Seems to be pretty accurate.

      3. T. F. M. Reader Silver badge

        Re: Estimating Software Projects

        @Robin: double the number and increase the time unit

        I have been using the same formula for many years, after learning it from a colleague. The formula as stated to me was a bit more precise: "Take your first estimate, multiply by 2, move to the next time unit - that's how long it will take you to bring the software to production quality".

        At first I thought it was a bit strange, then I did a few examples in my head: 2 weeks -> 4 months = a factor of 8, 1 month -> 2 quarters = a factor of 6, 1 quarter -> 2 years = a factor of 8 again, 3 days -> 6 (5 day) weeks = a factor of 10...

        Somewhere "on average" you get a factor of 8 to 10. And then it dawned on me that it fits the seemingly independent "last 10% of the job take 90% of the time" rather well. What happens is that you quickly figure out that you need to do A, C, and C - that's your first estimate. The rest seems to be ~10% of minor details, but it is those minor details that make the difference between a quick sketch and production quality, and that takes ~90% of the time. The "times 2 in the next time units" formula is just another way of phrasing it.

      4. BuckeyeB
        Thumb Up

        Re: Estimating Software Projects

        So 2 years becomes 4 decades?

    6. PerlyKing

      Re: Estimating Software Projects

      I can't remember (or be bothered to look up) who said this:

      The first 90% of the project takes the first 90% of the time, and the last 10% of the project takes the other 90% of the time.

      1. DJV Silver badge

        Re: Estimating Software Projects

        Excellent! Not heard that before so I did have to go look it up. Apparently it was Tom Cargill of Bell Labs:

        https://en.wikipedia.org/wiki/Ninety-ninety_rule

    7. Rich 11 Silver badge

      Re: Estimating Software Projects

      My general rule of thumb was to multiply my estimate by 4 to get a believable number and then multiply by 4 again.

      My general rule is to pick a number, double it and add three. I've told project managers to their faces that that's what I do. I've even said that they can pick the number and the time period that goes with it, but they can't blame me if they get it wrong. Eventually they give in and concede to the research period and proof of concept testing that I originally asked for but wasn't allowed to have until I'd agreed to the deadline dictated by manglement, while they have to go back upstairs and tell the PHBs that their beloved deadline might be a) unsupported by reason and evidence, or b) unachievable 'within the current resource framework' (or whatever this week's buzz phrase is).

  5. Anonymous Coward
    Anonymous Coward

    That's why when importing data...

    ... I connect with a user that can read data - but in now way can alter them. If needed, a specific one gets created. Proper permissions are your friend - and in Postgres TRUNCATE needs a specific permission very few users should have.

    Too powerful users in such situations are evil poltergeist that will bite your back as soon as they can.

    1. defiler

      Re: That's why when importing data...

      Too powerful users

      And yet many of us spent years using a Domain Admin account to check our emails...

      Hands up who still does that?

      1. Sgt_Oddball Silver badge

        Re: That's why when importing data...

        Not any more.. I'm no longer the dogsbody of IT so try as I might no admin rights for me any more (though I've got things working in ways that aren't approved of on my dev laptop.. Minor victories and all that).

      2. Anonymous Coward
        Anonymous Coward

        Re: That's why when importing data...

        I did in NT4 - as having to logoff/logon every time a domain task was needed was a bit uncomfortably - but stopped as soon as 2000 added the RunAs command.

        Sometimes bad habits have an historical reason (i.e. databases without permissions) - but there comes a time when you have to abandon them.

      3. Anonymous Coward
        Anonymous Coward

        Re: That's why when importing data...

        Hands up who still does that?

        waddya nuts?

        still if your entire organisation has been brought to its knees by a lack of patching etc , you do get encouraged to batten a few hatches subsequently...

      4. big_D Silver badge

        Re: That's why when importing data...

        I am a domain admin, but my user account is a normal user. We have secondary administration accounts for administering and we don't log on locally with those.

        1. Loyal Commenter Silver badge
          Devil

          Re: That's why when importing data...

          The added advantage of having admin accounts, is that if you screw something up, it's not necessarily traceable back to you...

          1. Anonymous Coward
            Anonymous Coward

            Re: That's why when importing data...

            Depends. On some system logs may be shipped to machines you don't have any way to modify them...

          2. John 104

            Re: That's why when importing data...

            Not really. At least in Windows land. Every log in ends up in the security log. So unless you are wiping the entirety of the logs, you will get caught eventually.

            And see above regarding lying vs being responsible. :)

        2. big_D Silver badge

          Re: That's why when importing data...

          Just to add, the my user account doesn't even have local admin rights on my own PCs.

          1. Nick Ryan Silver badge

            Re: That's why when importing data...

            Which is the most sensible way to do this.

      5. Nick Ryan Silver badge

        Re: That's why when importing data...

        No, however the morons who designed Office 365 and its security pretty much do their best to make it that standard user accounts have to take on Office 365 administrative roles. Cockwombles.

  6. Admiral Grace Hopper

    I never made a century

    The longest week I ever booked was 96 hours. As keen as I was to break the 100 hour mark, I was not in a functional state by the end of it but we had a piece of software that could be show to management to make them feel good about the pretty GUI and keep us moving.

    I am so glad that no-one let me anywhere near anything live that week. Bad things would have ensued for sure.

    1. MiguelC Silver badge

      Re: I never made a century

      I once did a well over 100 hours week. Not at a job, mind, but while in uni.

      My group mates decided to abandon our CG course's project work a week before the due date, leaving me with the option of a) also give up and retake that course the following year; or b) do all the work by myself (even redoing some of my own work to cut some corners and be able to finish in time).

      So, during the following 6 days I worked like a maniac and slept less than a total of 16 hours (split in 3 or four times).

      I got to deliver my work and fell asleep on the bus home - while standing (and woke up after banging my head against the handlebar).

      At least I got a good grade and never spoke to those bastards again.

      1. uccsoundman

        Re: I never made a century

        I'll bet that your mates that gave up on the project were very happy to take that good grade for the completed project. That's why I hate group projects, especially in School. If you want a good grade, you end up doing all the work and only getting 1/4 the credit.

    2. Down not across Silver badge

      Re: I never made a century

      I am so glad that no-one let me anywhere near anything live that week. Bad things would have ensued for sure.

      I have broken a century. As you have already discovered, I would not recommend it. I also had to work on live production system. As the hours piled up, productivity dived (probably inverse squared). Even the simple things started to require ridiculous amount of concentration.

      Having colleagues to check, at least that you're not doing something utterly stupid, can be a lifesaver.

    3. Long John Brass
      Windows

      Re: I never made a century

      Had one project; Later did the math... We averaged ~14 hours a day, 7 days a week for 3 months solid.

      Go live started 6am on a Thursday morning.... I walked out of the office very late the next Monday night. I was a broken sack of human meat by the end. Never ever again. Got way too used to driving home trying see around the big black dots in my vision.

      I was young and stupid. I only survived that one because I was young and stupid.

      Never

      Ever

      Again

  7. Anonymous Coward
    Pint

    Have a beer...

    ...for taking the point-in-time backup. True laziness would've skipped that step :)

  8. Pascal Monett Silver badge
    Trollface

    "the sympathetic vultures of the Register"

    Now, what does that remind me of ?

    Oh, right : this.

    1. This post has been deleted by its author

  9. ShortLegs

    We were doing 80-100hr weeks routinely at a certain large British Tobacco company just over 20 years ago. At the time, it wasn't that strenuous; the work was challenging, but fun, well rewarded, and they had superb management team (ok, 'superb' in the sense of no PHBs, no absurd management decisions, tech decisions left to techs and not over-riden, and a culture of costing the build rather than building to cost).

    Despite the hours worked, mistakes were very few and very far between.

    1. Sgt_Oddball Silver badge
      Trollface

      Well.. What did you expect?

      A company like that would be very generous with it's fag breaks...

      1. ShortLegs

        Re: Well.. What did you expect?

        Fag breaks? Mate, you could smoke at the desk.

        When booking a meeting room, you could also book tea, coffee, biscuits, and cigarettes. I'd book meeting rooms just to collect 40 cigs, take them downstairs, and throw them at^H^H^H, erm, "distribute them" to the smokers.

        Every so often every desk would have a packet of "$company's premium brand" on the desk, or even a carton of 200. Restaurant was subsidised; breakfast cost a maximum of 40p, lunch was wholly free. Bar was subsidised, too.

        Unsurprisingly, between the limitless free food, the bar, and the hours, I went from 9 1/2 stone to over 12 stone in 18 months... took some working off. But happy, happy days.

  10. lglethal Silver badge
    Stop

    Some weird comments on here...

    It's like people are proud that they worked long hours and crunched, like its a right of passage or something? Sorry, but I've never worked more than a 45 hour week. I now steadfastly refuse to work more than a 3-4 hours over time in a week. And never more than 2 weeks in a row. If the project needs you to work overtime continuously, well than management need to get off their asses and hire another person. I've got a wife and some young kids, and there's every possibility that any project that people are working on will be cancelled, redirected, delayed, etc. so why on Earth would i crunch? I've got better things to do with my time, like spending time with my kids.

    Crunch is an evil bastard of a thing which destroys people's lives, and for what, so that management can get some extra bonuses for meeting delivery deadlines with minimal headcount? Sorry, but I wont play that game.... I'm surprised there are any Vultures out there that would....

    1. Down not across Silver badge

      Re: Some weird comments on here...

      It's like people are proud that they worked long hours and crunched, like its a right of passage or something? Sorry, but I've never worked more than a 45 hour week.

      Some might be, other less so. I'm certainly nor proud. I've been there, have burnt out couple of times and it is not really worth it. Sometimes it just happens as things drag on and before you know it the hours have clocked up.

      I absolutely agree that in general need for anyone to do overtime is a sign of under staffing.

      Work/life balance is important and it is much more difficult to get me to agree to overtime these days especially if it inconveniences my plans.

      I also think there is a lot of cultural "longer hours mean harder/better workers" in UK and US. That is obviously a misconception. Work smarter, not harder.

      1. doublelayer Silver badge

        Re: Some weird comments on here...

        I don't think it's a good thing. I wouldn't be eager to do it. Yet I'm a little proud that I have done it and succeeded. When I was first required to work that long, it felt very difficult. Knowing that I didn't fail under that stress is at least a bit positive, even if I don't want to repeat the experience. Thinking this also lets me take an unpleasant part of my history and use it to my benefit.

    2. matthewdjb

      Re: Some weird comments on here...

      I happily work 3-4 hours a day. When things get tough, maybe 6.

    3. chuckrman

      Re: Some weird comments on here...

      Some of the pride may be a result of for whom and why. I have pulled 100+ hour work weeks I am very not much proud of because it was just a band aid over a problem and I just burned out. Other times I have pulled those weeks because there was a legitimate concern or event that no one had thought of and the risk of failure was high. It is those days that I take pride in being part of team that really brought things together under extreme circumstances. The former was often due to lack of staff, sudden departures of poorly treated staff, or just really bad planning. The others had to due with what fall under the "acts of God" sort of thing, On those cases we had follow-ups and lessons learned which prepared us for next time.

      1. StargateSg7

        Re: Some weird comments on here...

        Someone else's TRUE but UTTERLY FRIGHTENING 100+ Hours Initiation IT JOB STORY!

        100+ Hours Week for 4 weeks straight doing Software + Hardware bug fix team (in the 1970's).

        ON SITE in an actual WORKING PRODUCTION ENVIRONMENT !! Running tests on REALTIME actual INCOMING DATA --- Could NOT take production and backup systems offline for ANY reason EVER! Only the smallest part of each sub-system was allowed to be taken offline and worked on in a LIVE FIX-IT-RIGHT-THEN-AND-THERE until the code was fixed and tested!

        PROBLEM? Incoming data was PROVEN to be FALSIFIED caused by natural phenomena such sun flares and and extra-atmospheric blast events!

        HOW TO FIX? Take one section of system offline taking up to 10 minutes to do. Insert NEWLY coded system into same system. Test on realtime data! Get answer. Fix Bugs in 40 minutes (i.e. with an actual countdown clock running!) on large minicomputer built onto a large cart pulled by four people! Code, Compile, Run fix on "Bug Cart" with realtime data coming from LIVE system. Re-insert NEW code and boot up into LIVE production environment (took up to 10 minutes!) with no other tests other than LIVE realtime data showing up production viewing screens! Goto NEXT system and Rinse-n-Repeat Cycle for hour after hour!

        Rinse and repeat for 200+ different parts of same system taking about one hour for each Take-Offline, Re-Code, Test, Re-Upload, Put-back-online, Test on Live Data and then Pray subsystem fix! Do so for next 300 hours+ of constant 24 hours a day fixes by two teams who stayed ONSITE all the time to fix and update LIVE PRODUCTION SYSTEM on-the-fly!

        HOW BIG OF A PROBLEM WAS THIS AND WHY BE SO UPPITY?

        Code fixes were ordered by higher ups to be LIVE ONSITE and in REALTIME with IMMEDIATE UPLOAD to PRODUCTION SYSTEMS due to nature of system and type of environment that was ALWAYS UNDER SEVERE PRESSURE that was 24/7/365 for DECADES (and is STILL ONGOING today!)

        It was a LIVE Launch-on-Warning Data Centre at a time in history where NUCLEAR ICBM MIRV MISSILES were allowed to be sent off PURELY ON WARNING WITHOUT REQUIRING the permission of "The Executive!" (i.e. Launch on Warning!) Had ANY of these "Fix Teams" failed, NONE OF YOU HERE would be alive today to tell ANY tales because a TINY FEW Tens-of-People were overworked for 300+ hours 24/7 for a few weeks to ensure fixes to code that could have and ABSOLUTELY WOULD HAVE automatically without human intervention sent 4000+ Megatons of MEGA-DEATH TO THE ENTIRE EARTH because of FALSELY-INTERPRETED real-time live incoming data !!!!

        YUP! I would say that is TRULY and VERILY an ".I.M.P.O.R.T.A.N.T." Info-Tech FIX-IT JOB !!!!!

        .

        .

    4. CountCadaver

      Re: Some weird comments on here...

      I used to use a metalworking forum. which had a user who professed to being 16 (turned out he was closer to 50 and a fantasist but thats beside the point of this tale) said he had gotten an apprenticeship in a fab shop, everyone pleased, few weeks later "the boss is short staffed so he's asked me to do night shift" "Ive been doing 12 hour shifts and working alone on stuff" multiple guys on there, including an IT project manager with hiring responsibilities (who should have damned well known better) gave responses including "great work ethic" "wish more had your work ethic" "probably learn loads" "keep like that and you'll be valued by any manager" this being after it was pointed out that its illegal for someone under 18 to work nightshift and a criminal offence for any firm who has someone under 18 work night shift....what happened "let the lad work" "all good in theory but this is the real world"......and folk wonder why people get hurt or killed in the workplace.......

      I left that forum soon after.....

      1. Anonymous Coward
        Anonymous Coward

        Re: Some weird comments on here...

        Of course, he could well have been lying about the apprenticeship just like his age. And the hours. And the feedback from management...

        1. CountCadaver

          Re: Some weird comments on here...

          point being the reaction of other users saying it was a great thing......

    5. Olivier2553

      Re: Some weird comments on here...

      People may feel proud of their own achievement, that they have been able to pull it. Like one would be proud he managed to finish a marathon. Marathon are even more useless if you consider, you're not even getting paid to run, but still, there are hundred of thousand of people running several marathon a year, across the globe.

  11. Killfalcon

    One of the teams I supported once capped off a month of crunch with an all-nighter. The whole team worked from 8am Thursday to 5pm Friday.

    They got their simulations done, their results produced, job delivered, off to the pub to celebrate hitting this quarter's deadline.

    It took a solid month to fix all the cockups they'd made (which did not set things up well for the next quarter). The team manager responsible was "redeployed" and left the company shortly afterwards, so silver linings.

  12. NBCanuck
    Unhappy

    Project timelines

    Project timeline:

    Stage 1 = 1 weeks

    Stage 2 = 4 weeks

    Stage 3 = 2 weeks.

    TOTAL = 7 weeks

    Now here is the math. If Stage 1 goes 2 weeks over (runs 3 weeks), then the total should go to 9 weeks. That should not ever mean that the project stays at 7 weeks and everyone should just work more to make up the time. I know that is usually not how it works, but it should not ever be the case.

  13. Anonymous Coward
    Anonymous Coward

    Not a crunch comment!

    Does anyone else think it odd that they allowed live users onto the new system before data migration had been done? Migrations are hard enough as they are, having live data present that mustn't be overwritten as well just seems like masochism.

    1. Mr Sceptical
      Devil

      Re: Not a crunch comment!

      I'd have no issues with a selection of clients/customers using a trial system - on the strict understanding their data might be deleted at any time. Even a system in Beta shouldn't be relied on.

      Sounds like the Sales droids sold an incomplete product and the Dev's had to invent it - is Don's reall name Dilbert?

      The PHB ---->

      1. CountCadaver

        Re: Not a crunch comment!

        looks more like catbert imho

      2. ma1010
        Trollface

        Re: Not a crunch comment!

        Even a system in Beta shouldn't be relied on.

        So, no Windows X, then?

  14. Ugotta B. Kiddingme
    Coffee/keyboard

    a new term for my lexicon

    "sphincter-loosening fuck-up flowchart"

    Thank you for that. (And apologies to the person who walked by at JUST the wrong moment. I have an open account with a local dry cleaner for just such occasions...)

  15. Anonymous Coward
    Anonymous Coward

    Is it scrumptiously crunchable? golLUM golLUM golLUM

    1. J. Cook Silver badge
      Go

      Yesssssss my preccccisssousssssss... :)

  16. simon@simonrosephotography.co.uk

    The closest I've come to this situation was when I was contracting for a red-coloured mobile phone provider migrating some data from one SAN to another. I was using robocopy to keep two system in sync. Normally I use the /mirror parameter to copy anything from the source to the destination, but this time I also used the /purge parameter which also REMOVES anything thats on the destination thats not on the source. I'd failed to check and deleted 500GB of unrelated data on the destination. Data that was required, and fairly urgently. Opps! I learnt a few useful lessons that day. 1) own up. 2) check thoroughly and use the /l parameter to simulate before commiting. 3) $25 spent on GetDataBackNTFS was the best $25 ever spent!

    I got all the data back and still keep that data recovery tool license handy, 15 year later, just in case....

  17. Stoneshop Silver badge
    Facepalm

    The process "worked, but it was too slow"

    That brings back memories. Unhappy ones.

    I was one of two sysadmins for a GIS being built that was to be used for all kinds of agricultural taxes, duties and subsidies; there were also two DBAs and of course a bunch of developers. Stuff like land use, feritilizer runoff into ditches and streams, cow poo volume (not to be confused with bullshit, that came from within the Agri Ministry itself), all bundled into one Portal with a Hefty Database behind it.

    At some point the devs needed to load a base map of the Netherlands, followed by each farmer's data as held by the land registry. And of course it did a crosscheck to find any patches of land that appeared to be allocated to more than one farmer. While loading the dataset. This caused the loading to get very slow very fast; and my suggestion was that they were checking each new record against every record already loaded, but the DBA who was keeping an eye on things replied that it was worse. How? They were indeed doing exactly that, on tables that weren't indexed. So, full table scans. And they weren't indexed because they wouldn't need those particular indexes in production.

  18. J.G.Harston Silver badge

    I think everybody has done the stagger out of computer lab at 7am, post assignment in box, fall asleep thing.

    1. Anonymous Coward
      Anonymous Coward

      No, but at U I finished an awful lot of essays around 6:30a.m. before a 9 o'clock lecture. Then I noticed my 9 o'clock lecture notes were invariably crap.

  19. Hazmoid

    Try support they said

    As a support bod, I have done the occasional overnighter to get things fixed, so much so that at one stage I had a sleeping bag under the desk so I could catch some zzzs in the board room whilst waiting for things to happen. However the only time I worked long hours was when I was in a bush fire gang helping combat bushfires in SW Australia during summer. The overtime and standby were awesome but the social life sucked.

  20. Long John Brass
    Pint

    Well said Don!

    The moral, according to Don, is: "When you cock up, own it: admit the mistake and then work out what you need to do in order to fix it."

    I *wish* more people knew/did this!

  21. RichardB
    Stop

    Truncate... Rollback

    Of course truncate can be rolled back; even in Postgres, otherwise it wouldn't be acid compliant, would it...

    But... if it's already committed then I'm pretty sure you are bang out of luck on all the proper rdbms platforms...

    Happy to be corrected if someone knows of an exception to the rule that you cannot roll back a committed transaction?

    1. TSM

      Re: Truncate... Rollback

      In Oracle, at least, a truncate (and any other DDL statement) auto-commits.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022