back to article How do you make those darn code monkeys do what you want? Just give 'em a little nudge

Nudge theory – brainchild of Richard Thaler, a professor of behavioural science and economics at the University of Chicago – uses positive reinforcement and indirect suggestion to influence behaviour. For example, in a supermarket or canteen placing healthy food on display at eye level rather than banning sales of junk food. …

  1. Voland's right hand Silver badge

    I stopped reading the moment I reached the D word

    Another DevOps article. Can we have something more interesting with a more substantial IT angle please?

    1. Anonymous Coward
      Anonymous Coward

      Re: I stopped reading the moment I reached the D word

      Nudge theory is behind the business of giving the salaried workforce free supper to keep them working longer hours. It's vastly cheaper than paying them for their extra work.

      1. AmyInNH

        Re: I stopped reading the moment I reached the D word

        "Free lunch!"

        "Game room!"

        "Pizza Fridays!"

        "Onsite haircuts!"

        etc.

        All to attract youth, who don't know this means they're making minor concessions to accommodate keeping people there night and day.

        The article is attempting to fix one of the inherent flaws in their youth only hiring, their subservience to their learning curve. They don't have space to innovate, when they're on slow path discovering basics of collaboration, robust design, etc. And, nobody makes good decisions when overtired, particularly chronically overtired.

    2. Pascal Monett Silver badge

      Re: Another DevOps article

      Which, again, manages to rediscover things IT professionals knew 20 years ago.

      I'm beginning to believe everything DevOps is just a dictionary renewal exercise for management.

      1. AmyInNH

        Re: Another DevOps article

        Management manufactures business buzzwords EXPERIENCED tech professionals knew years ago. Then business spins certification factories around them. You too can be a Scrum Master! Project Manager! etc. etc. And then the truly clueless hire the latest fade certified.

        "I don't know what a Data Analyst is, but I'm sure we need one!"

  2. Anonymous Coward
    Anonymous Coward

    Positive Encouragement

    Well that's not going to happen in vast swathes of the UK IT Industry. The PHB's are too busy getting rid of people and sending their jobs to S. Asia.

    Then there is HMG itself telling the contractors based here that they are really shadow employees and IR35 is coming to get you.

    Who needs this DevOps snake oil anyway? This time next year there won't be much industry left to employ it. Better start learning German I think as my Russian won't be of any use as long as Putin is in power.

  3. Chairman of the Bored Silver badge

    Problem is...

    ...the average manager who grasps at the buzzword of the day to "transform his organization" is generally not the kind of guy or gal who provides inspirational leadership.

    True leaders are like eagles... Beautiful, powerful, majestic. And of course an endangered species.

    1. Doctor Syntax Silver badge

      Re: Problem is...

      "True leaders are like eagles... Beautiful, powerful, majestic"

      And apt to carry off livestock.

      1. Anonymous Coward
        Anonymous Coward

        Re: Problem is...

        "wherever possible we want our teams at the FT to migrate to Amazon Linux, because it saves us money – and we have a website that shows each team how much they would save"

        Aha. So instead of telling the team to migrate to AWS - which would be old-fashioned top-down management - you drop not-so-subtle hints that they should do so. Also include implied threats if they don't - in this case, budget problems.

        Let's have a new buzzword for this: Passive-Aggressive Management, or PAM for short.

  4. Alan J. Wylie Silver badge

    Beware of the leopard

    Make Things Easy / Politicians

    The antithesis to this is if you don't want someone to do something, e.g. claim a tax refund, you make it as discouraging as possible.

    Web forms that show you the new question only after you have answered the previous one, so you have to keep bothering the same person over and over again for the next answer.

    Confusing instructions on web forms.

    Long phone calls on hold with irritating music.

    Being referred from one phone number to another.

    That was my morning just wasted, and I'm sure that the Sir Humphreys of this world have big smug grins on their faces.

    1. bombastic bob Silver badge
      IT Angle

      Re: Beware of the leopard

      well, a positive example of this 'make it easy' etc. principle is how the city of San Diego handles its recycling program, which effectively pays for itself (as I understand it) with items tossed in the blue cans.

      All they did was give EVERYONE a blue trash can to put out every other week with recyclable materials.

      Now I find I'm filling the blue can, and rarely put out the black one [normal trash] by comparison.

      So recycling gets done on a massive scale, it benefits the city, trash doesn't fill up the landfills so much any more, and it is SO easy to do as a citizen, because you just toss the recyclable thing into the blue can instead of the black one. [they also give you a pretty long list of things you can recycle, and a trash calendar indicating which weeks to put the blue can out on the curb].

      Anyway, I think this is a good example of the principles discussed in the article being applied. OK it's not IT, thus icon, but I thought it was worth "sharing". heh.

      1. AmyInNH

        Re: Beware of the leopard

        Just what I told my local recycle initiative leader, make it easy to do what you want people to do.

  5. monty75

    Zapp Brannigan writes

    I like my women like I like my DevOps framework

    EAST – Easy, Attractive, Social, Timely

    1. Chairman of the Bored Silver badge

      Re: Zapp Brannigan writes

      Nice. My problem is that I leave my women like I take my coffee: cold, dark, and bitter. Similar to my experience with DevOps so far!

  6. Anonymous Coward
    Anonymous Coward

    Ring the bell

    Positive reinforcement is much older than 10 years. Some guy named Pavlov who liked dogs or some such.

    Back in the mid 90's my supervisor decreed all user documentation would be rewritten "in the positive". No more "no" or "do not". Instead of saying "do not use weak passwords" you say "only use strong passwords".

    The end result is a much stricter set of rules. The docs become "everything restricted, but here's what you may do" vs "nothing is restricted, but don't do these specific actions". The positive docs inherently define allowed system operations.

    Actually worked too. Fewer calls to the helpdesk. Fewer instances of updating the docs because a user found a new "do not". Users bent on circumventing the rules could no longer hide behind the docs. Them saying "the docs didn't say I couldn't" became us saying "the docs didn't say you could".

    When we did update the docs it was usually to add a new feature or empower users with a new privilege as opposed to applying new restrictions. It's still a philosophy I follow today. Document in the positive.

    1. bombastic bob Silver badge
      Devil

      Re: Ring the bell

      "Document in the positive."

      things that document 'in the negative' were probably written by lawyers trying to cover their own asses...

    2. veti Silver badge

      Re: Ring the bell

      It's very hard to generalise about this, because every software package is different, but if you document it as "do this", then effectively your software now does only that. Easier to support? - sure, because 80% of people stop trying to use it, because what they want to do is something slightly different.

      I've been in the same position - for years I was the documentation guy at a small software company. My bosses were forever telling me to write the process to be followed. But what that left out was, basically, all the options. I'd end up documenting one very specific workflow, out of several hundred such options that the software would support. There were fewer questions of the form "how do we do this?", but many more of "what does this button do?"

  7. iron Silver badge

    Call me cynical but

    "We also have a celebration party every quarter and that has gone a long way to getting people motivated."

    That would have the opposite effect with me, I would think you were having a party to avoid raising salaries or paying bonuses.

    1. Korev Silver badge

      Re: Call me cynical but

      Me too. A celebration when you're compelled to do it seems forced (cf Valentine's Day); however celebrating more spontaneously for something worth honouring is a good thing.

    2. Anonymous Coward
      Anonymous Coward

      Re: Call me cynical but

      Hah, we have these. In our US office, they have a party on the first Friday of every month, everyone knocks off at 3pm, there is some booze and nibbles and often a theme or gimmick, karaoke one month, hot dog stand the next month etc etc.

      In the London office, we started doing the same. After 9 months, it changed from monthly to quarterly. The budget got reduced to the point we couldn't even afford proper food, just crisps. Our last "quarterly" party was over 8 months ago because they defined the end of financial year company drinks as one, and the Christmas party as another.

      Our HR manager in London was one of those delightful old dinosaurs who believed that fun was something that can be ordained. If you chose not to partake in the festivities, you couldn't go home early, even to work from home. Nope, you had to sit there, 20m from the party, unable to work because of the noise. She would be on the door making sure you didn't leave early...

  8. Gio Ciampa

    "Social"

    "We also encourage people to talk about things that have worked for them, in lightning talks or blog posts. When we share information we can show how easy it is to do something and show what people can gain from it."

    Until you're flooded with notifications saying that XYZ has responded to ABC's post - and promptly tune them all out... even the useful ones

  9. Jason Bloomberg Silver badge
    Trollface

    Missed opportunity

    I was a little surprised there was no mention of Linus Torvalds and the way he applies Nudge Theory in his interactions.

    1. Jim Mitchell

      Re: Missed opportunity

      Linus prefers the "Cudgel Theory", instead. Almost the same word, rather different result.

  10. smudge Silver badge
    Facepalm

    Let the devs decide!

    "We started asking developers to think about things like monitoring and resilience. It's hard to tell a team that they may be woken up at 2am if it breaks. You have to give your teams a level of power to take decisions."

    How about the business - not the developers - deciding what level of resilience they want and are willing to pay for... and specifying it in the requirements? You do have requirements? Ohhh....

    1. Blank Reg

      Re: Let the devs decide!

      If only those writing the requirements actually understood what they were asking for, or the implications. Like asking for 5 nines reliability because they heard that's something good, but then questioning why it costs so much.

  11. Anonymous Coward
    Anonymous Coward

    I find shit loads of cash really helps...

    ^ see title.

    1. LucreLout Silver badge

      Re: I find shit loads of cash really helps...

      Indeed - there are few things in life you can pay me to STOP caring about, but almost limitless things you can pay me to START caring about.

  12. SVV Silver badge

    Nudge + Dev Ops = The Bleedin' Obvious + Buzzword Bullshit (apparently)

    "Sarah Wells, principal engineer and platform tech lead at the Financial Times, is a passionate advocate and has been banging the drum for Nudge at various DevOps-themed events."

    Let us now marvel at the new wisdom presented to us humble servants by this noble sage.....

    "We started asking developers to think about things like monitoring and resilience"

    Yep, devs are idiots and never think about such things.

    "It's hard to tell a team that they may be woken up at 2am if it breaks."

    Well, nobody in IT has ever expected that this might happen.

    "You have to give your teams a level of power to take decisions"

    The power of being able to decide to get the work done well without listening to the unnecessary distraction of the bullshit you spout would be welcome.

    ""It's about saying to people if you choose this database, we've made it easy for you to use".

    What, you mean like employing an experienced database team, and developers who understand databases? Which is what you have to do if you need to use databases. Hmm. starting to see someone who's not too experienced in IT learning a bit about things and believing that she's made a whole load of original gosh wow new insights that she just HAS to share with the world.

    "And be customer focused – make sure people know who to contact, she adds."

    Shit, our organisation needs to be somehow organised?

    "together with granular insights into which application and infrastructure changes are causing problems."

    Thank you for inventing incident / change management systems and processes just now. By yourself. Nobody could ever have thought of THIS before ould they?

    "developer tools startup Paddle, dashboards of "contextually relevant" information help focus minds on key metrics before they become a problem."

    Oh great, a load of useless metrics to distrract me from development work. At least his company's name implies that it will be sold to customers whose poor IT management has led to them finding themselves up Shit Creek and desperately looking for a means of escape. And again, the idea seems to be that of relying on a product or snake oil philosophy to solve problems rather than using experienced people who ignore all this sort of bullshit and just succeed in delivering good quality work because they really know what they're doing.

    "gamifying development can help inject a sense of competition into processes and nudge engineers to achieve higher "scores" across important metrics"

    Attention nudge evangelists : any talented developers you have will leave the moment you try to foist bullshit such as this on them.

    "firstly, attract people's attention so they know what you are asking them to do. Then you need to explain why they should want to do this".

    How about you tell me what needs doing, and I do it because it's my job to?

    "we want our teams at the FT to migrate to Amazon Linux, because it saves us money – and we have a website that shows each team how much they would save," Wells says."

    Well if you'd just migrated them to Linux and told them to use it, you would have saved even more money.

    I can't go on any further with this nonsense, IT at the FT was obviously expensive and disorganised, they improved things a little and now they think they've miraculously\ discovered the "secret" of effective IT and wish to share it with the world, but have, in fact, publicly embarassed themselves with this buzzwordy restating of the trivially obvious.

    1. GrumpenKraut Silver badge
      Thumb Up

      Re: Nudge + Dev Ops = The Bleedin' Obvious + Buzzword Bullshit (apparently)

      You are soooo negative! Have an upvote. -------------->

    2. Doctor Syntax Silver badge

      Re: Nudge + Dev Ops = The Bleedin' Obvious + Buzzword Bullshit (apparently)

      "principal engineer and platform tech lead"

      It's the "engineer" and "tech lead" bit that's puzzling. People without any tech background coming into IT in management roles and spouting this stuff is nothing new but the titles suggest someone who actually does have that background. Or is it just how they label managers over there?

      1. AmyInNH

        Re: Nudge + Dev Ops = The Bleedin' Obvious + Buzzword Bullshit (apparently)

        "It's the "engineer" and "tech lead" bit that's puzzling."

        One insane company/department I worked for declared one of their two interns "tech lead", and left it in that state after hiring a bank of experienced engineers, to work for this lead. The task, WAY out of his depth.

    3. Steve the Cynic Silver badge

      Re: Nudge + Dev Ops = The Bleedin' Obvious + Buzzword Bullshit (apparently)

      "It's hard to tell a team that they may be woken up at 2am if it breaks."

      Well, nobody in IT has ever expected that this might happen.

      I *hope* your response is sarcasm. Not my current job, but the one before it, I had several calls from the data centre in their late evening, which of course was about three am British time since the data centre was in New York, and the possibility of such calls was part of the package. (Of course my response was normally "back it out and I'll work on a fix once I'm in the office" and it was often times not actually my fault it broke.)

      1. Anonymous Coward
        Anonymous Coward

        Re: Nudge + Dev Ops = The Bleedin' Obvious + Buzzword Bullshit (apparently)

        I was once called up at 4am by someone in our China office telling me that something was broken. I was not best pleased, my role does not include out of hours support, and I spent about 5 minutes just shouting down the phone at her "Do you know what time it is in London?" over and over again.

        Nowadays, they call someone else, who then decides if its worth waking me :)

    4. Anonymous Coward
      Anonymous Coward

      Re: Nudge + Dev Ops = The Bleedin' Obvious + Buzzword Bullshit (apparently)

      "gamifying development can help inject a sense of competition into processes and nudge engineers to achieve higher "scores" across important metrics"

      I dunno, the level of interest our proposed move to github corporate is generating because people will be able to put badges on their repos is scaring me slightly. Like, seriously, this is why you want to do all this work? For BADGES?

      We don't need no steenkin badges

    5. Sebastian P.

      Never do this

      > "We started asking developers to think about things like monitoring and resilience"

      > Yep, devs are idiots and never think about such things.

      Actually, asking developers to think about such things is a very smart thing to do. Not because devs are idiots. But because devs take the requests from the requestors, e.g. The Business, whom are not always cognizant about putting in requests about monitoring, resilience or security.

      By explicitly telling the devs to think about such things, you put those on the requirements lists, and the devs can now work their magic to flash out what exactly is needed to be implemented.

      When requirements are not specificified, that's when things go bad: requestors will assume that those are "built in" by default and they don't have to bother mentioning them; devs will assume that if something was not mentioned, then it's not needed. Assumptions all around, which we all know how well they work out...

      1. AmyInNH

        Re: Never do this

        Resilience only needs mention if they've hired 100% minimally experienced, and have no code reviews. This speaks to their bad hiring practices and lack of quality oversight in their development process.

  13. disgruntled yank Silver badge

    Noodge theory, anyone?

    The dictionary at my desk derives it "< Yidd nudyen, to be tedious, bore < Russ nudnii, tedious" and defines it as "to keep urging, asking, etc. in an annoying way; nag."

    Now, I had understood it as a noun, one who noodges. But either way, it's as good a theory as any for IT consulting.

  14. Doctor Syntax Silver badge

    The view from local government:

    "Ensuring litter bins are available accompanied by adequate signs..."

    Costs money. Bad.

    "...rather than imposing on-the-spot fines."

    Brings in money. Good.

    "It was seized upon by politicians"

    Guess which was the 'it' the politicians seized on.

    1. Alan J. Wylie Silver badge

      You missed out "Can be contracted out to my brother-in-law's company. Good.".

  15. Code_Daemon

    When I saw the title this sprung to mind...

    https://www.youtube.com/watch?v=8mG76I7DpT8

  16. Disk0
    IT Angle

    Cattleprod theory

    Is all we need down here.

  17. Herby Silver badge

    You will get desert.....

    When you eat your vegetables.

    (or something similar)

    1. bombastic bob Silver badge
      Coat

      Re: You will get desert.....

      how can you have any pudding if you don't eat your meat?

  18. Denarius Silver badge

    older than you think

    Seneca or was it Marcus Aurelius remarked that good laws should be easy to follow. Laws to do the right should be easy and to do wrong made hard. Seems the bureaucrats making taxation laws have it backwards. So user documentation and application design guidelines have old precedent

  19. Robert D Bank

    the whole thing falls on its arse when you have incompetent staff. In the rarefied Mgmt world they don't have to deal with the dickheads they've hired that have to be carried by the rest. This leaves precious little time to do the real work because you're hand holding, teaching fundamentals and fire fighting the fuckups they make. Most of the time you want them to do nothing as it's less painful. Oh yes, and I know, 'you should spend time training them and building systems that caters for the lowest common denominator so they can't makes mistakes'. Well FO, most leave quickly once they're rumbled, to be replaced by someone of equal or worse incompetence (but cheap) and the cycle starts again. In between you're having this DevPlops and all the other jizz thrown at you like it's gong to be a panacea for the stupid Mgmt decisions that created the problems in the first place, such as siloing everyone, not investing in training, constantly ratcheting down the budget

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

Biting the hand that feeds IT © 1998–2019