Brookes
You'd almost think no-one ever read 'The Mythical Man-month'.
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 …
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.
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.
"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.
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!
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.
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!)
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 ?
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.
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".)
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.
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".
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.
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)
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. ;)
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?
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.
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.
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!
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.
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.
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.
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 !!!
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.
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.
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.