We have programming peeps around here. How bad is this as a mistake? Is it take the person who designed the calendar part of the system out the back and shoot them? Or is it execute them in front of all pour encourager les autres?

The Department for Work and Pensions has abandoned its lengthy legal battle to avoid fixing a “perverse” design feature in universal credit that has left thousands of working claimants hundreds of pounds a year out of pocket.

The minister for welfare delivery, Will Quince, told MPs he accepted that the DWP must correct the feature, which has resulted in serious budgeting problems for some claimants who are paid at the end of the month.

The issue currently affects claimants whose wages are paid two days earlier than usual when the month ends on a weekend or bank holiday. The system assumes they have been paid twice in a single universal credit assessment period, and none in the next, meaning their benefit payments fluctuate wildly.

I have absolutely no idea of course, this being both technical and hard. But I do assume that someone, somewhere, in some sort of computing system somewhere, has already solved this problem. So, why is it in this system here?

41 thoughts on “Seriously?”

  1. It’s almost certainly not a “programming” error. That’s just a convenient peg upon which to hang the blame.

    Far more likely that these kind of rules were handed down by business analysts, based on meetings with the UC product owners (DWP wonks). And there was likely some analysis done of the “only affects 0.01%, so not worth fixing”, which is fine if you’re in a comfy job for life with a guaranteed pension, but less fine if you’re at the sharp end on benefits and the dork on the phone tells you “computer says no”.

    Fixing it is likely trivial – a few days at the most, including the testing. Even allowing for grossly inflated consultancy fees and multiple layers of management, what will likely consume a big chunk of that cash will be retraining staff (tbh, that shouldn’t happen at all in a rules-based system).

    Caveat: Most of the above based on 35+ years of coding experience, some of which has been public sector, and plenty of ignorant hand waving.

  2. Dealing with dates is a major PITA, I’ve got an entire book on the subject(*). It’s our love of doing things by month that’s the problem, if payments were by week number there would be no problem, but monthly payments are so hard wired into our culture that we’re stuck with it. I suspect someone programmed up the rules as written, found this problem, raised it with their superior and got told “them’s the rules, implement them and sod the punters”.

    (*) Admittedly it covers pretty much all calendars, not just the Gregorian one.

  3. Payroll systems work on the basis that if payday falls on a weekend your salary is paid on the preceding Friday. Which would suggest that the issue has been encountered and resolved before. This is what happens when involving the likes of Crapita or Price, Whorehouse & Croupiers – they will declare that the system must be built from scratch and will cost oodles of billions when it may be possible to adapt an off the shelf payroll system as the back-end piece for a fraction of the price.

  4. allthegoodnamesaretaken

    why is it in this system here?

    Public sector.

    You know how much the government struggles with basic tasks like giving away free money.

  5. It’s similar to when I was signing on while doing part-time work. I was paid in arrears. So when I did some work, the system would see on week one I’d worked too many hours, and zero my claim, and then in week two I’d had too much income, and zero my claim. One week’s work resulting in two weeks’ benefit loss.

    I managed to successfully appeal it, and get it retrospectively fixed, but every time I signed on during part time work I had to show the claimant advisor my letter and instruct him/her what to put into the system.

    Ironically, this was part-time work installing the DWP’s jobcentre computers.

  6. It’s good to know that nobody’s career prospects or pension rights were damaged in the course of making and continuing this blunder.

  7. allthegoodnamesaretaken

    Fixing it is likely trivial – a few days at the most, including the testing.

    Oh my aching sides. Now the court has mandated it be fixed, just watch the price go through the roof!

    Even without the court order, the change management process alone is measured in weeks if not months.

  8. If coping with dates was extraordinarily difficult, the whole airline industry wouldn’t work. They accept bookings months/years in advance, for two way tickets, in/out of different timezones. It’s a bit like address input (not all houses have numbers) or names (don’t fit into firstname lastname), programmers always like to reinvent the wheel and come up with their own cunning scheme and ignore the previous work in the area.

    That said, here it’s also likely to be incompetence in the civil service on top of the likes of Crapita.

  9. Bloke in North Dorset

    The problem isn’t the programming mistake, it’s the decision to spend ££££s on lawyers defending what is obviously a ludicrous position.

  10. Bloke in cornwall

    Dates are a pain in the ass to be honest, but only because the project managers and businesses analysts decide to write vague statements with no logic – I have seen, in the same spec, from a council, the use of “month”, “30 days” and “4 weeks” to define how a process works… When pushed each of the managers doing the job we were systemising said they did it differently…

    Good luck coding that.

    Coding in payment rules (bank holidays, Sundays, etc) is easy if you have proper rules. Loans and credit card payments take it into account easily enough, as does payroll (as others have already pointed out). I’m sure many other places take it into account to (JIT deliveries?)

  11. Like your solution. But if pursued across the entire public sector what’s the UK armed forces going to using for ammunition the next time the government wants to extend the hand of friendship to forriners?

  12. The coding horrors displayed at the Daily WTF site (https://thedailywtf.com/series/code-sod) include date/calendar related items about a couple of times each week. If we could see the code behind this report in a post there, I’m sure it would mingle unobtrusively along with its fellows.

  13. These mistakes usually occur in Government depts. The main reason imo is that nobody every gets punished for these cock ups and the end users can’t vote with their feet.

  14. It’s not even a problem that should need solving. Payments can be made any day of the week, including weekends and bank holidays. It’s not like the banks’ computers all pack up their stuff on the Friday night before a bank holiday weekend and sod off for a 3-day bender in Eastbourne.

  15. Railway workers are paid on a Friday, 4 weekly rather than by calendar month. There needs to be a once in a few years one off additional payment (53 weeks in the financial year rather than 52, such as 2018 – 19).
    Works fine and doesn’t have the issues noted by Tim.

  16. If I got that wrong, I’d get a severe kicking for it. Given that this is a relatively new system, there should be a microservice that deals with this, and only this, specific issue, of date calculations, with a set of automated tests around it that run every time a code change occurs. As soon as an issue like that is raised, tests should be written to make sure that it can’t happen, and then the relevant microservices should be fixed accordingly.

    Given who was involved, none of that will be the case, and it will be some abominable monolith that only works in certain weather conditions.

  17. As mentioned by others, this is likely to be a problem in the specification, rather than the programming.
    Any attempts to raise questions, and gain clarity, will have exposed the incompetence of the sad inadequates in the relevant Gov department, resulting in “Shut up and do what it says”.
    “OK, Guv, you’re paying, you will get exactly what you asked for. Enjoy.”

    Of course, the whole industry rather depends on this specification incompetence, as the original quote is loss leading, and fixing all the crap is where the profit is.
    If HMG ever started doing things right, the industry would have to change. No risk of that though.

  18. I’ve just asked a software architect.
    “Why? You can get an app off the net. There are hundreds of them. Most of them are free.”

  19. Time is horrible to deal with—especially on multi-time zone systems (it’s one of the reasons why so many apps use formulations like “posted 4 minutes ago”—it is 4 minutes ago whatever timezone you’re in).

    Dates are pretty horrible too, but time periods are an absolute bastard—especially when you are integrating into multiple systems, each one of which might deal with a slightly different time period cycle. Most Housing Association software still works on a period of 52 weeks, for instance, which is actually easier—because nothing is more of a complete and utter bastard than trying to deal with months.

    Not only are months inconsistent in the number of days but working days can differ even within the UK (Scotland, for instance, has different Bank Holidays to England); further, of course, you have the joy of Leap Years to deal with.

    As someone who writes the specifications, I try to be pretty careful with how I specify time periods—and they take up an inordinate amount of time, frankly.

    DK

  20. Mr in the Kitchen,

    What I hate about that kind of thing is illustrated by email systems. They use a stupid array of completely different date formats. In the same box you will have things like:
    Today
    On Tuesday
    1 week ago
    2 weeks ago
    1 month ago
    Friday 12 Jan 2020, 09:24

    The latter format is the only one that doesn’t force the user to do calculations, or be as imprecise as the course of a week. But you only seem to get it on really old items.

  21. Calendars are really tricky with respect to periodic payment dates, and are a major cause of operational failures and losses in financial systems. This is because the rules on whether and how to adjust a payment date can be quite complex. However, once a problem is encountered, it is typically trivial to fix and include in testing (in any well architected system), so the same problem should not happen twice.

    My guess is that whoever designed or wrote this was just not aware of this being an area that requires careful thought and good design, and so trod in every cowpat in the field. And then stood on a rake.

  22. Effing stupid.

    I used to work on direct debit systems, where you have to request payment in advance (and adjust it for weekends/bank holidays) and we stored two dates: when the payment was requested and when the payment is for. And one reason we did this was that we didn’t take 2 payments in a month, so to check that, we used the “for” date.

    So, what they should do is record the “for date”. If you pay someone for 1st June on 29th May, you hold 1st June and do your checks against that as the payment date, not 29th May.

  23. “What I hate about that kind of thing is illustrated by email systems. They use a stupid array of completely different date formats.”

    My, paid for, domain webmail systems do the same. For some reason the people run the systems started designing them to suit small children, third world peasants, the educationally sub-normal & the Spanish. Why, I haven’t a clue. None of these groups actually use e-mail. They Whatsapp or whatever.

  24. @3’s
    The banks themselves seem to be clued up. Credit cards usually debit same day mid-month, so you have 12 statements a year, each relating to a month. Same with utilities, etc

  25. “this being both technical and hard”

    Nah, it’s been solved thousands of time before. Just use old, competent code.

  26. I’m a full time programmer. I’m nearly 100% sure that this isn’t a programming error. The bit of the system that does “pay them before the weekend” likely works fine AND “have they been paid this month” is fine. It’s that those two systems were written by different people, they work to different rules and make different assumption. This is a design/architecture or possibly a management problem.

    As all the other programmers here say, dates/time are surprisingly difficult.

    FWIW I get paid on the Thursday preceeding the last Friday of the calendar month. A lot of people think that would be equivalent to “Last thursday of the month”.

  27. Tim the Coder,

    “As mentioned by others, this is likely to be a problem in the specification, rather than the programming.”

    One little thing about government contracts, and many of the scummy outsourcing companies they use, is that they’re perfectly happy to let users put a big error in the specification that cocks things up, as they get paid for that, and the fix. I’ve known developers get bollocked by managers for suggesting cheaper/better ways of doing things to clients (i.e. me).

    Internal teams tend to flag things up earlier.

  28. I had a summer job in the civil service once (ironically the ‘dole office’ as it was called back in 1981). Obviously a Monday to Friday job.

    I started on Monday 3rd of July. My payslip arrived at the end of July for me to find I had been paid 29/31 of the month’s wage.

  29. ‘So, why is it in this system here?’

    Because they haven’t fixed it yet. A management decision.

    ‘The Department for Work and Pensions has abandoned its lengthy legal battle to avoid fixing a “perverse” design feature’

    ‘Feature.’ Cute.

    ‘There were no straightforward solutions and the system could not be changed at “the flick of a switch,” he added.’

    This could be true. With no personal knowledge of their system, and their reluctance to change it, I presume it is true.

    ‘We have programming peeps around here. How bad is this as a mistake?’

    We have no way of knowing. Insufficient information.

  30. “in a single universal credit assessment period”

    This is the problem, its a fixed period versus a variable period, absolute vs relative, sure to go wrong.

    The payment should be calculated on earnings “since the last payment”, everything is relative in programming these days.

    My own company insists on using a fixed period (month) for analyzing high severity incidents, more than one per month is considered an issue, but often if one or the other incident had occurred 24 hours earlier or later, putting it in the next/previous month, then the issue disappears, should be “withing 30 days of previous incident”, it does show that senior management are a bit out of touch with basic IT concepts, and is probably the case in DWP.

  31. It’s more than half-a-century since I last wrote a programme. That is actually relevant since the reason I quit to become an Actuary was that I could not control errors in the data entered and was utterly pissed off at being told my programme didn’t work when some guy had supplied data that looked right but had slipped by 10^3 (metric system).
    It’S DWP
    It’s NOT a programming error – it is utter stupidity on the part of DWP staff. How can any honest man claim that it’s a programming error – if DWP looked a6 payment during the actual calendar month instead of their artificial month no problem would arise How can anyone dispute that.
    I have said before that DWP is not fit for purpose. Data available on request.

  32. It’s an understandable error to make – as many have said, dates are hard.

    *Because* it’s understandable and expected that there will be errors, the system should have been set up with the expectation of regular bug fixes to be applied (to both spec and code), tested and deployed with minimal interruption to normal service.

    Of course, it wasn’t.

    “The DWP had argued that to change the system would cost at least £7.5m” they say; I would very much like to see the breakdown of that £7.5m.

  33. “I could not control errors in the data entered and was utterly pissed off at being told my programme didn’t work when some guy had supplied data that looked right but had slipped by 10^3 (metric system).”

    Anecdata: Many a month end I had to straighten messes from data entry. It usually involved someone making up a number. I told the accountants over and over: If you are going to make up a number, make up a big one.

    Someone entering something like a flow, which should be millions, would put in 1. Later calculations would exceed numerical limits because input was many orders of magnitude off. I didn’t get mad. I made similar programs that I could run that would preserve the intermediate values so I could see where the mess up was. What used to be a huge problem I could fix in under 15 minutes.

    ‘“The DWP had argued that to change the system would cost at least £7.5m” they say’

    Sounds about right if it’s SAP. But again, we don’t know enough about it to know.

    Though I think I could write that program in 7 lines.

  34. Dates are a pain, just had to do a fix for someone as their system displayed a duration in seconds and they wanted it to display in business days, “x days x hours and x minutes”

  35. Bloke in Lower Hutt

    Another software developer here, another agreement that dates are hard to work with. I don’t think the real issue here is the feature itself, even the worlds greatest development teams and Microsoft introduce errors into their applications.

    I’d be more concerned at the amount of effort it appears it will take to resolve the problem, that sounds to me like there are some serious architectural issues and inadequate testing procedures in place which for an application that manages the doling out of cash would leave me in a cold sweat at night if I was leading the development team responsible.

  36. I beat you all. I was up after midnight watching client’s system on 31 Dec 1999.

    A cost accounting system.

    Gamecock told his fine bosses that accountants won’t be working at midnight. Bosses didn’t care. Y2K demanded all hands on deck.

    BTW . . . has Gamecock ever said he knew a shi+load more than his bosses?

  37. People are complaining about a system that leaves them better off ( over a 12 month period ) compared to some kind of counterfactual where there is income smoothing. I just don’t get it.
    At the extremes , say I am monthly paid and get an income meaning 1 penny of benefits per month. Ok, cool, I get nowt for practical purposes. Amend that to being over the threshold for 1 month of the year due to 2 payments, but the amount by which I’m under the threshold for the other 11 months where I get paid once, means that I’m net better off compared to the Tax Credits system.
    And people are complaining about a welfare system that results in a tiny bit more welfare compared to what we had before. Words fail me.

  38. @Henry Crun
    Spot on. Same as Track & Trace – reinvent wheel

    @jgh June 26, 2020 at 7:45 am

    I had biker friends who had same problem. Conclusion was ‘don’t tell DSS’, ‘fess up if “caught”. It wasn’t only dole payment being honest screwed, but housing benefit etc too.

    Same problem now:
    Farmer Jim: Two weeks full-time picking job for you
    Bennie: No thanks, my benefits will be screwed for two to three months

  39. bloke who's paying attention

    Your expert programmers are missing that it happens when your WAGES are paid too early. Assuming they kept the user interface simple by asking “enter date and amount of wages”, then the DWP have no way to know whether it was a genuine Friday payment or early Monday payment. They can write “rules” to compensate, but they’ll probably just discover a different edge case.

  40. @ bloke who’s paying attention
    But DWP have told employers’ computer to supply the DWP computer with date and amount of payment because the don’t expect the claimant, a mere human, to be capable of doing it him/herself

Leave a Reply

Your email address will not be published. Required fields are marked *