back to article 'Business folk often don't understand what developers do...' Twilio boss on the chasm that holds companies back

Twilio founder and CEO Jeff Lawson has told The Register that many biz execs still fail to grasp the importance of software developers and do not understand how to work with them, dismissing them as "math geeks" or "digital factory workers". Lawson recently released a book called Ask your Developer, arguing that things haven't …

  1. Neil Barnes Silver badge
    Holmes

    Brookes

    You'd almost think no-one ever read 'The Mythical Man-month'.

    1. jake Silver badge

      Re: Brookes

      We did. Back in the late '70s, before most of today's management had graduated out of three-cornered pants,

    2. Michael Wojcik Silver badge

      Re: Brookes

      Required reading in my CS course, back in the '80s. I still have my copy. It remains as pertinent as it ever was.

      That said, development-method schools such as Agile aren't in opposition to most of Brooks's observations. Agile is an attempt to avoid the eponymous problem that Brooks discusses, by keeping schedules very short and flexible (so there's no incentive to try to throw resources at them). A good Agile implementation accommodates the variety of developer roles that Brooks describes by letting teams self-organize rather than treating them as pools of fungible workers. And so on.

      Of course, Agile isn't a silver bullet and can certainly be done so badly that it's counterproductive. And there are all sorts of ideas and practices lumped under the Agile category, of varying value; and there's wide agreement that every organization and team have to be free to adapt whatever Agile system they're trying to use to their own requirements.

  2. Doctor Syntax Silver badge

    Ah, yes, low-code and no-code. But will they be the Last One?

  3. yoganmahew

    Why respect?

    When you can buy in scrum teams and they fit neatly into your spreadsheet?

  4. Mike 137 Silver badge

    However I wonder why...

    It's strange that so many online services only work on the latest client side systems. Just the other day I encountered a business critical portal that only works on the latest few (six weekly) versions of Firefox and is specified as not working on IE at all. This kind of restriction can only be bad for business, as it excludes potential customers and collaborators unless they're on the "constant update" treadmill. It's an increasingly prevalent trend and I really do wonder why it's been allowed to establish itself. One might legitimately infer that developers are coding solely for themselves, rather than for their client's customer base, particularly as many such system restrictive functions could often be implemented in much simpler and more universally accessible ways. It's almost as if complexity of implementation is commonly for its own sake.

    1. Anonymous Coward
      Go

      Re: However I wonder why...

      The 'constant update treadmill' simply describes modern browsers' default settings. If you don't intervene, your browser will stay up to date.

      And IE has been dead (and good riddance) for years.

      1. Mike 137 Silver badge

        Re: However I wonder why...

        "The 'constant update treadmill' simply describes modern browsers' default settings"

        Yes, that's the whole issue. There should be a very strong justification for forcing change on us every six weeks or so, but I haven't heard one yet.

        It's a basic principle of good engineering to find the simplest and most easily usable way to solve a problem robustly and reliably. When I taught web development the very first thing I said to every class was "you're not creating a site for your client - you're creating a site for your client's customers. If you limit unnecessarily who can access it, you're not serving your client's best interests as they'll lose potential customers".

        However I get the strong impression that many web developers are creating sites not even primarily for their clients but for their own self-gratification or to show off how smart they think they are.

        1. Clinker

          Re: However I wonder why...

          I think this familiar design for designers pattern has much simpler underpinnings. It's the default pattern that comes from how we're taught, how specifications are written and how all of us try to simplify the real world with abstraction.

          The only consistent cure is to keep the customer in the design conversation at every stage of product planning, implementation and rollout. That is easy to say and, without a Bezos, is difficult to accomplish. And why? Because it's complicated!

    2. Alan Brown Silver badge

      Re: However I wonder why...

      "Just the other day I encountered a business critical portal that only works on the latest few (six weekly) versions of Firefox"

      Because w3c standards "aren't a standard, but Firefox is!" ?

  5. The Man Who Fell To Earth Silver badge
    FAIL

    skill & knowledge as a commodity

    Business people, even if they have undergraduate degrees in the Sciences or Engineering and worked in those areas for a while, eventually tend to think of technical ability as a commodity. They don't get that even in technical businesses that are dealing with highly mature technology, some technical folks are better than others and it matters. Even if one has highly documented processes and great document control (and we all know how every company does - they have the ISO certs to prove it), if you don't keep a stable workforce and instead ramp headcount up and down as the short term winds blow, good luck competing against competitors who take a longer term view.

    1. Joe W Silver badge

      Re: skill & knowledge as a commodity

      Yes and no.

      Skills and knowledge are a commodity. Deep knowledge fo your processes and products comes with experience. This knowledge cannot (ok: seldomly) be bought, we all know more things than what is written down (but can be used as a bargaining chip...), and in fact we all know more things than we are aware of. So no, you cannot easily buy it. But that does not make it less of a commodity. And skills - in every field - is not a binary state, but rather a continuum, a wider range. Good people cost money. That does not make skill less of a commodity. You need to buy a certain quality and quantity of skill and knowledge. Some is available on the market, some for rates you don't want to pay, some cannot be had. You can buy Pelé (ok, maybe more modern... Ronaldo? I don't follow soccer) or Andi Suckface who is playing on the weekend in the county's "league". One costs a lot of money and is (probably) worth it. The otehr one can be had for cheap but will not perform on your European Champion Club's Cup (or whatever it is called).

      The main point is that the bean counters need to be aware of those things. Your boss likely is. Maybe his boss as well. What about the ones higher up that care more about their super yacht races?

      (but I'm d'accord with your general assessment and especially the last sentences!)

  6. Pascal Monett Silver badge

    "rather subscribing to cloud services and using them as components"

    I am disappoint.

    The book is nothing but a PR puff piece promoting a cloud-based company which, surprise, finds that using the cloud is the best thing sliced bread.

    I'm sure OVH would agree, but I'm guessing some of its customers might have an issue with that idea.

    Oh, and how does Twilio guarantee that it won't become another SolarWinds123 ?

    1. Youngone Silver badge

      Re: "rather subscribing to cloud services and using them as components"

      I am not particularly disappoint, because a PR puff piece is exactly what I expected. I seriously doubt if Twilio founder and CEO Jeff Lawson has even read the thing because what are the chances he wrote it?

      Also, I would not leave my wallet on my desk if he was in the office.

    2. Michael Wojcik Silver badge

      Re: "rather subscribing to cloud services and using them as components"

      Well, Twilio is unlikely to have a SolarWinds-style breach, because they're not distributing code to their customers.

      They'll have a SaaS-style breach instead. Pick yer poison.

      (On the plus side, telephony is already so absurdly insecure1 that a telephony breach is more "oh, another of these" than "holy crap I was not expecting that".)

      1For frickin' example...

  7. cantankerous swineherd

    worked on the shop floor for a firm run by a mechanical engineer, doing minute operations as part of the whole effort. we were given a mass of words and numbers printed out from a spreadsheet that had "all the information". so complicated that the fuckwit manager couldn't understand it, whilst we, of necessity, could decipher it. no attempt was made, or even conceived of, to present relevant info in a useful fashion.

  8. Anonymous Coward
    Anonymous Coward

    CEO once spotted a developer typing at a computer...

    CEO: "What the F**k are you doing"?

    Developer: "Huh"?

    CEO:"I don't pay you to type stuff up, you have a secretary to do that for you"!

    That really did happen. I was there to witness it :-(

    Same guy - "We keep having bugs in the code. I don't understand why we haven't just tested all the possible combinations that we can get in the 8K EPROM that holds the code".

    1. Anonymous Coward
      Anonymous Coward

      Re: CEO once spotted a developer typing at a computer...

      Worked at a place with a similarly-minded CEO. His interpretation was that if the engineers weren't typing in code then they were actively stealing from the company. So things like requirements and documentation (and even testing) were non-existent, and the company struggled to do anything besides cope with a crushing mountain of technical debt.

      Best quote I heard: "there's no time to plan, JUST START CODING". Emphasis on speed and cost, and actively sacrificing all quality in order to get it.

      1. jake Silver badge

        Re: CEO once spotted a developer typing at a computer...

        "Emphasis on speed and cost, and actively sacrificing all quality in order to get it."

        DevOps, then?

        1. Anonymous Coward
          Anonymous Coward

          Re: CEO once spotted a developer typing at a computer...

          Agile.

    2. G.Y.

      Re: CEO once spotted a developer typing at a computer...

      Got this query "why not test all possible ...") at Intel. Among other things, we had a 16/16 divide procedure that had "only" 4 billion possible combination; spent a few nights testing 10^8 of them at random -- on the ONE real chip we had at hand. (This is 1981, 1MHZ top instruction rate)

      1. J.G.Harston Silver badge

        Re: CEO once spotted a developer typing at a computer...

        If you have a manageable finite set of values, iterating over all of them can be the most appropriate test. On the same subject, just recently I was testing a 32-bit integer divide routine built from 16-bit operations, and I just built a bit of code to test all 2^32 x 2^32 cases and left it running overnight. At least this was with 2020s CPU speed. ;)

        1. Michael Wojcik Silver badge

          Re: CEO once spotted a developer typing at a computer...

          232 x 232 is (232)2 is 264.

          You tested 264 iterations of a function "overnight"? Even for "2020s CPU speed" that's ... a lot of iterations. If "overnight" means 12 hours, that's doing more than 4 x 108 trials (which presumably includes verifying the result) each microsecond.

          Am I missing something?

  9. jake Silver badge

    Bottom line.

    Marketards & manglement need to stop trying to do engineering and leave it to the engineers. Between them, the M&Ms are cocking the technical world up completely. It's kinda like watching a liberal arts major trying to use a lathe ... spectacularly dangerous for onlookers, but funny in a morbid kind of way.

    1. Throatwarbler Mangrove Silver badge
      Thumb Up

      Re: Bottom line.

      I assume the reverse is also true, that you believe that developers should stick to their knitting and not weigh in on the marketing and management functions of the business.

      1. doublelayer Silver badge

        Re: Bottom line.

        In general, developers know what is possible better than do the marketing and management sides. Not always, but when the product is technical, yes. For the same reason, if your product was carpentry, you might want to include the people who know whether something's feasible or easy to build when deciding what products to advertise or which contracts to use. If your product had legal consequences, you might want to have the lawyers review what you were planning before you publicize it. The expertise in actually building the thing needs to be consulted before making management decisions, with the management responsible for coordinating actions afterward.

        Take a program someone suggested I write a while ago. They had seen that passwords were a problem, both simple-to-guess ones and reused ones. They thought it would be a great idea to write a program which could go through a network, check the passwords in use for strength, verify that they weren't reused on other services, etc. They thought this was a relatively easy thing to do and they could sell it to lots of places if we could just write it up quickly. Since I was interested in security and could write code, how would I like to be the lead [only] developer on the project? Fortunately, they hadn't already marketed this, because they found it a little disheartening when I described how salting and hashing meant it was basically impossible to do the first thing on any proper system, that salting and hashing were more important fixes than verification on any improper system, and that checking against other services would be at best a profound breach of privacy. If they had tried to promise things before, they would have been stuck with a promise to produce an impossible project.

      2. Tomato42

        Re: Bottom line.

        too often the MBAs give developers a screwdriver, hear developers complain, understand that the problem was the colour of the handle, while in reality the job was to hammer nails in

        1. jake Silver badge

          Re: Bottom line.

          Or they buy a job-lot of left-handed screwdrivers and don't understand why the entire staff bitches about it except Joe ... who is a southpaw. Shirley the rest of the staff can learnt to use their left hands? Look at Joe! He has no problems with them!

      3. jake Silver badge

        Re: Bottom line.

        Well, yeah. Thankfully, most developers wouldn't dream of doing marketing, and hate the concept of management. Sadly, the M&Ms are convinced that not only should they, but they can do engineering. Thus the slimy morass we find ourselves in today.

        Free advice[0] for sysadmins tired of the status quo: Take as many business related courses as you can stomach. Haul your ass[1] to your nearest post-secondary school that offers night courses and talk to a career counselor. Tell 'em that you are a techie, but are interested in management. You want to take courses that can be applied to a future MBA (should you want to go that route later).

        If you already hold a four year degree, and you can code fluently in one or more upper level languages, chances are you can snooze through an MBA in two years (or less, if the classes line up right). Lest you think getting an MBA is difficult, think about all the feckless idiots you know who hold one ;-)

        I realize that not all of us are cut out for management ... the objective isn't necessarily to become a manager, but rather to learn their lingo. It's amazing how fast long-closed doors open once you learn to talk to Moneybags in his/her own language. On top of that, an MBA will better prepare you for when the time comes to strike out on your own and become a consultant.

        [0] And worth every penny! No refunds without receipt.

        [1] Or arse, depending on which side of the pond you hail from.

    2. Michael Wojcik Silver badge

      Re: Bottom line.

      Could we drop the pretentious "humanities are for losers" bullshit? I know people with liberal-arts degrees who can use a lathe just fine. Two of my degrees are in the humanities, and I'm well-versed in quite a lot of power tools, thanks.

      This is one of the particularly pernicious forms of small-mindedness that infects far too much of the IT industry. And it's one of the reasons that most software is utter crap, frankly.

      1. jake Silver badge

        Re: Bottom line.

        I never said "humanities are for losers". Never even implied it.

        The lady doth protest too much, methinks.

      2. doublelayer Silver badge

        Re: Bottom line.

        It's not humanities which are at the root of the problem, and I see no comments which suggest it is. Check most people who manage without understanding. They're often not humanities people. Nor is management necessarily a problem. They have a role to play which is important, and without them, there is more chaos. What is the problem is that management is more often able to exceed their role and cause issues because they have more power.

        I posted on this topic a while ago. I noted there that it's not just engineering that needs this consultation. The discussion here has mostly been about engineering since A) most of us are engineering people (software included, please let's skip the linguistic discussion this time) and B) the article was about engineering. The general sentiment applies to any work where there is someone making the product and someone managing them. That product may be a technical one requiring hard science, or a legal one requiring lawyers (a lot of whom are humanities people), or an artistic one, or literally anything. The problems and suggestions apply equally well to them all.

  10. Boris the Cockroach Silver badge

    Manglement?

    Having been at the sharp end of things for many years, I've seen plenty of manglement... from the good... to the bad.... to the ugly.... to the downright insane.

    Case 1. new mangler comes in, notices we make a loss on providing a range of products to a company, but make a huge mark up on one product that covers those losses nicely.. decision ramp the price up on the loss making stuff to make even more cash. result #1 :customer dumps us because he knows we're gouging him on one part but gets the rest cheap. result #2 : we start losing money.

    Case 2. New mangler comes in replacing #1 above. endears himself to the technical staff by saying "A manager doesn't need to know what a company makes , just knows howto manage" result : we lose even more money. (and 23 people lose their jobs).

    Case 3. Another new mangler replacing #2 above , says "I started at 16 doing technical stuff, and worked my way up" Cynical workforce go 'hmmm' turns out he did start at the bottom, and does know his stuff result #1 : company hits profit sharing bonus target. result #2: workforce happy(if still slightly cynical) result #3 : entire company and mangler #3 go on strike when head office changes the accounting rules to eliminate us making said profit....

    A good manager needs to know the technical background of what the company is making, to be able to direct the workforce in the best possible way, he also does not need to know the utter technical details of what the employees are doing but must be able to step back and trust them to get on with it. #3 was an expert at that

    PS I missed out the other 3 manglers that company employed over the 7 years I worked for them !!!

  11. Mike 16

    I blame Picard

    for making so many managers believe that saying "Make it so!" will actually, um, make it so.

  12. find users who cut cat tail

    The business folk often don't understand…

    Make it a full stop.

    I am not even judging. It is just how it is.

    1. Tomato42

      what? You're trying to say that microservices that use blockchain in a devops managed environment don't solve all problems?! but how could that be!?

  13. a_yank_lurker

    Manglement vs Management

    My experience with manglement vs management is a manager understands in general what the troops are doing and why they are doing it. Also management understands how the various groups have to work together for the company to be successful. This does not mean they have a deep, detailed knowledge of each area. They are willing to form ad hoc teams when necessary to attack problems. Also, they understand the grunts have learned quite a bit of internal knowledge that a new hire does not know. So they are slower to get rid of staff if they can see a way not to lower the head count. Manglement always fails at least one of these, usually several, and sometimes all.

    When the pandemic hit, my company announced they were going to keep all the staff as they watched the pennies very carefully. No one was let go because of the pandemic, in fact the company has been hiring during the pandemic as the head count actually increased. While it may seem unimportant, the company did not lose any significant internal knowledge and moral seemed to stay fairly high has one worry was removed from all of us. Manglement would had a series of layoffs so they could make the profit numbers. Our profit numbers, while down some, were actually pretty good overall for 2020.

  14. sketharaman

    Software Developer Obfuscation

    It's not like all the digital transformation software that moves tech from backoffice to frontoffice is done by coders alone. "Software Developer" is one of the best examples of obfuscation I've ever come across. Coders monopolize the title "Software Developers" although the process of software development involves many roles other than coders e.g. designers, architects, testers.

  15. TheMeerkat

    Agile manifesto?

    Is it what management pay consultants to do, so that code monkeys click on keyboards quicker ?

  16. Paul Hovnanian Silver badge

    Better for us ...

    ... if they don't understand.

  17. Terry 6 Silver badge

    This is half of the equation though

    Those kind of can't-managers tend to sit between the devs and the users, not listening to or understanding what the users need then misinterpreting it to the developers. Who, if they're not careful, blame each other. From what I've seen from four or five abortive projects over the years they also seem to take great care to ensure that users and devs are kept well apart and not allowed to work together on the design even if they're all in the same company.

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