[HN Gopher] Cargo Cult Software Engineering (2000)
___________________________________________________________________
Cargo Cult Software Engineering (2000)
Author : srirangr
Score : 145 points
Date : 2021-02-03 18:08 UTC (4 hours ago)
(HTM) web link (stevemcconnell.com)
(TXT) w3m dump (stevemcconnell.com)
| mlthoughts2018 wrote:
| There are some fundamental limits to commitment-focused culture
| though. People have life obligations. Even if they wanted to work
| 60 hours a week, their sick mom or their childcare or their
| kitchen renovation or an especially busy graduation season for
| nieces and nephews just requires their time, and their knowledge
| that their job is secure and they won't be penalized on raises,
| rewards, etc., for simply _having a life._
|
| Because of this, the commitment-focused path just doesn't work,
| flat out. At best you can use it briefly to exploit unwitting
| young people who don't know their worth and don't have enough
| self-confidence to say no, and ride that into a pump and dump IPO
| situation, after which your company will promptly become process-
| focused and all the young people will quit and be replaced by
| mid-career people who don't mind inheriting the mind-melting tech
| debt as long as you pay well and only expect 40 hours per week.
| dboreham wrote:
| So much truth here.
| 908B64B197 wrote:
| There's a trick to get more out of employees that's almost
| never discussed: Make their life easier.
|
| Childcare for a late meeting is an issue? Why not have
| childcare at the office? Pay enough and the kitchen
| improvements are the contractor's problem and not your
| employee's.
| kortilla wrote:
| This only works for people whose "life" only consists of
| chores.
|
| Will the company pay someone else to take my wife on a 2 week
| romantic get away?
| 908B64B197 wrote:
| > Not having childcare is not the issue, wanting to spend
| times with your children is the issue. You can't outsource
| that.
|
| It's simple accounting really: If you want your employees
| to work 5 more hours a week, you need to free 5 hours from
| their schedules. Obviously, quality time spent with
| children or a spouse is the last thing employees will be
| willing to sacrifice. But running errands? Cleaning the
| house? Doctors appointments? Meals at work? Make these
| frictionless and you'll gain in productivity.
| Jtsummers wrote:
| You'll gain _hours_ , but not necessarily _productivity_.
| Which is a common mistake in management thinking. An
| extra hour of work out of an assembly line can produce an
| extra hour 's worth of product, there's a pretty clear
| and measurable extra output there. In software, and a lot
| of other design work, this correspondence is less
| precise. For Cody the Coding Machine you may get a real
| extra hour of output from him. From many others, you'll
| find they extend their breaks from 15 minutes to 20
| minutes, lunch goes from 30 to 45 minutes, and the extra
| time is taken up by meetings or answering emails.
|
| The productivity doesn't come from extra time, it comes
| from alleviating stress and increasing the ability to
| focus. If my thoughts at 2pm are, "Wait, is it my day to
| pick up the kids? I've got a 3pm meeting, I've got to
| text the wife to let her know I can't get them today."
| I'm unfocused. Childcare, consequently, can relieve me of
| those thoughts. Same thing with bringing in food or
| having medical and fitness options available. They
| relieve some stress/unproductive time spent thinking and
| planning, which will hopefully improve productivity
| overall, but extra hours recovered from this are not
| necessarily more productive just by being available.
| hinkley wrote:
| Don't give them any ideas.
|
| If they did, you'd have a lot more free time for them to
| exploit in the future.
| sgt101 wrote:
| Mate - email me and I'll do it for free!
| _underfl0w_ wrote:
| This solution has potential to permanently remove the
| overhead introduced by "marriage".
| rightbyte wrote:
| Childcare at the office seems like a great way to put too
| many eggs in one basket. Changing child care centre is no
| small thing.
|
| The simple solution is no meetings after 15:00.
| steveBK123 wrote:
| The sociopath parents in management solve this for everyone
| by putting in lots of 8am meetings instead ...
| w0mbat wrote:
| Google tried this. They set up this cadillac in-house
| childcare system, as you'd expect from Google, but it got
| out of hand as it scaled. When they switched to charging
| the parents more of the program cost, there was a huge
| backlash. Even with the higher price they couldn't meet
| demand, leading to waitlists and eventually a random
| lottery just to get a place. I bet Google management wish
| they'd never started the whole thing now.
| hinkley wrote:
| If there's one thing you can count on 'disruptors' to not
| understand, it's grandfather clauses. You raise your rate
| for all new 'customers' and your overhead rate stops
| looking like a line going toward infinity.
|
| Your reward for being at Google for 5 years should be
| that you get the rate plan from 2 years ago when your
| first kid was old enough for daycare.
|
| My reward for being a Netflix customer for 6 years
| _should_ have been that I still got the old rate.
| gilbetron wrote:
| Not having childcare is not the issue, wanting to spend times
| with your children is the issue. You can't outsource that.
| jodrellblank wrote:
| Well, now you can work from home and homeschool at the same
| time. Closing this support ticket as 'resolution found'.
| ericbarrett wrote:
| Saves the extra drive to daycare as well as the stress of
| not meeting the pickup time (most daycare charges very high
| after-hours rates to discourage this; I've seen $50/15
| minutes).
| bluefirebrand wrote:
| > At best you can use it briefly to exploit unwitting young
| people who don't know their worth and don't have enough self-
| confidence to say no, and ride that into a pump and dump IPO
| situation
|
| That's basically the business plan in a lot of places.
| mlthoughts2018 wrote:
| Agreed, and we software engineers just keep letting them do
| it to us by agreeing that leetcode algorithm hazing should be
| the absolute measuring stick by which all software hiring is
| judged.
|
| If you feel like you barely squeaked your way in the door as
| someone was whipping you and yelling "dance monkey dance"
| then you're helping them identify you as a gullible goober
| they can pay peanuts (relative to your value add) while
| overworking you, and get you to _thank them_ for the sweet
| ping pong and happy hours.
|
| Until young candidates just say no to this shit, then it's an
| abyss of open-office, grab-ass culture we have no one to
| blame for but ourselves.
| tempodox wrote:
| > _... we should be looking for ways to raise the average level
| of developer and manager competence._
|
| Ha, I wish! The vast majority of companies I worked for never
| wasted a thought on this. It seems clear to me that there is much
| room for improvements on that axis, irrespective of
| organizational style.
| sidlls wrote:
| We should be debating process versus commitment, though. "They
| can both work" is a bit facile.
|
| Work isn't (typically) done except in the context of workers'
| lives. These paradigms incentivize different behaviors and
| cultures and there are real impacts on the lives of workers as a
| result. It's a mistake to purport that we can ignore those
| consequences in an evaluation of what works.
| Jtsummers wrote:
| I think one of the points in the conclusion is that these two
| ideas aren't actually on a spectrum, but rather are more
| orthogonal with each other. It's not a true binary choice so
| there isn't a real debate to be had between the two. Process
| doesn't preclude (though it may constrain) individual
| empowerment, and individual empowerment does not preclude
| (though it may constrain) process.
|
| There are processes which actually do, to some extent,
| encourage individual empowerment. I would put the trend to
| distributed version control systems like git as a boon to both
| process _and_ individual empowerment, as an example. I can use
| it much more freely to experiment in my feature branch than
| when using a system like SVN (in many classical scenarios of
| using SVN), but the pull request system integrated into many
| git server systems is itself a process approach to control (and
| hopefully improve) the development work.
| sgt101 wrote:
| I agree, but also consider the choice of the worker. Commitment
| comes from motivation; the motivation can have a very large
| impact. A friend of mind went to work for Google, did 5 years
| as a Senior, got a load of cash, married his dream girl from
| high school back home and is now traveling the world with her.
| This is his idea of heaven. Personally I would never have
| committed like he did; but this is my choice. The problem comes
| when people are lied to and bullied into doing things that they
| don't want to with no positive outcome for them.
| 908B64B197 wrote:
| Selective cargo culting is great.
|
| I recall talking to someone who was very very happy to brag that
| his company was doing "everything just like Google" and following
| the exact same practices he read the company did on various
| engineering blogs.
|
| I asked him what was the compensation like and how he managed to
| get kids from Stanford to work at his company instead of their
| startups and he just gave me a blank stare. Said something about
| how they were not in Silicon Valley and paid median salaries and
| that he had "no trouble finding Google caliber talent in the
| local market." and that "it's not really the local market's
| customs to give stocks to coders".
| renewiltord wrote:
| Well, isn't that the magic of picking the right tooling? You
| then don't need superstars to operate the system. That sounds
| like a productivity coup. It is, natural, of course that the
| productivity accrues to capital rather than to labour in this
| relationship.
| jimbob45 wrote:
| In fairness, cargo culting can be good in very targeted ways.
|
| My company didn't have a clue on what to purchase for software
| development equipment or how to organize it. As a result, they
| observed what Google did and copied it to the best of their
| ability as their pocketbook would allow. Although it's not
| perfect and they have no idea why it works, it's certainly
| better than anything they could organically have come up with.
| the-dude wrote:
| Are you talking about computers or chairs and desks?
| gowld wrote:
| Those are all the same class of tools. The other side of
| that "or" is datacenters and networking infrastructure.
| the-dude wrote:
| > software development equipment
|
| You seem to be talking about production equipment.
|
| At least I have never needed a datacenter to develop
| software. But hey, that is just anecdata of course.
| 29athrowaway wrote:
| Does your company maintain operating systems, compilers, web
| browsers, libraries for cryptography, machine learning,
| compression, etc?
|
| Do you have services used by billions of people that process
| petabytes of data every day?
|
| If not, you do not need Google caliber engineers. You need
| common sense.
| gowld wrote:
| Google also makes a bunch of webapps and phone apps.
| yks wrote:
| I don't understand your point, you don't need "kids from
| Stanford paid in stock" to run a monorepo, k8s (borg), bazel
| (blaze), SRE and whatever else you can read on the blogs.
| That's literally the point, to spread ideas around the industry
| so everyone can try them out.
|
| Now I would understand the complaint if that company had the
| same hiring hoops as Google but a dud of TC but that's an
| orthogonal issue.
| georgeecollins wrote:
| I think the point the author was trying to make was that the
| example company was doing "everything like Google" EXCEPT
| being as picky about who you hire, paying as much, and
| aligning employees with stock options.
|
| If you try to bake a cake following a recipe, but only using
| half of the ingredients listed, you are going to get an odd
| cake.
| yks wrote:
| I guess I disagree. Yes, you need a high class talent to
| move the field forward but once the new frontier is
| conquered, it ceases to be a frontier and everyone else can
| enjoy the fruits. Regular engineering practices of today
| are cutting edge of yesterday.
| the-dude wrote:
| And still all initiatives to clone SV successes failed (
| The Netherlands is full of _Valleys_ , we have a _Food
| Valley_ , an _Energy Valley_ etc )
|
| Cargo culting only by name.
| gowld wrote:
| When Google builds all their super duper stuff, then they
| hire a bunch of people use that stuff (not create it),
| and pay them a lot.
| InfiniteRand wrote:
| On a tangent, Cargo Cults in the Pacific are a more complex
| phenomenon than many people assume.
|
| I remember in college I had a great Pacific studies professor and
| one of the topics he touched upon was the idea of cargo cults as
| a form of disruptive political protest. I forget the details of
| his argument, but I think this article captures the gist of it -
| https://www.scientificamerican.com/article/1959-cargo-cults-...
|
| I also think there was an element of trying to play Americans off
| of other colonial powers, although I can't find any citation for
| that.
|
| Interesting to note that at least one cargo cult made the
| transition into an actual political party -
| https://en.wikipedia.org/wiki/Nagriamel
| antiquark wrote:
| > When presented with more effective, new practices
|
| Yeah but... how can you judge the actual effectiveness of some
| practice if it's new? There's no long-term empirical evidence to
| judge it by.
| Jtsummers wrote:
| Experiment. If you desire evidence-based management, you have
| to seek out case studies (and actually consider them, not
| discard them when brought to you like one manager did to me,
| "Show me the evidence." "Ok." "Whatever") or run your own
| experiments. Even if you do seek out case studies, you will
| still want to run your own experiments because what works for X
| may not work for you.
|
| Find a low impact project or a project that can absorb a
| potential setback and try it out. If it fails, you at least
| gave it a shot. If it succeeds, promote the idea among other
| teams and projects. You can always apply a sanity check on
| ideas before trying them, just like in other things.
|
| "I heard that having a foosball table in offices increases
| productivity by 25%."
|
| "That doesn't sound right, but we can try to create better
| break areas."
| Gibbon1 wrote:
| > Find a low impact project or a project that can absorb a
| potential setback and try it out.
|
| That's how I introduce every new thing to the companies I've
| worked for. Use it in a non critical project first. The
| problem with using a new thing is a critical project is if
| anything goes wrong the company hive mind will scapegoat the
| new thing and you.
| cle wrote:
| I don't think the author is trying to say "don't try anything
| new unless you have evidence", but "don't use something without
| understanding why". Experimenting with a practice to understand
| it better is a perfectly valid reason. Adopting a practice and
| expecting it to magically solve your productivity problems,
| without understanding why and whether the tradeoffs are
| appropriate, is not a valid reason...that's cargo culting.
|
| Another way to look at it is...what are your expectations? If
| you are using something with the expectation that it'll
| magically solve your problems, and you don't really know
| why...you're cargo culting. If you're using something and
| _suspecting_ that it 'll solve your problems, and you expect to
| watch it and gather feedback and evidence on whether it's
| actually helping or not, and potentially axe it in the future
| if it's not working out...that's not cargo culting at all, but
| effective process.
| Jtsummers wrote:
| This is a good article, written in 2000. I think it was my
| introduction to the term "cargo cult" way back when.
|
| > We call the imposter organizations sweatshops because they
| emphasize working hard rather than working smart
|
| I wrote on a whiteboard at an office, early in my career,
| "Company motto: Work harder, not smarter" out of frustration
| following a meeting with a manager where that phrase was nearly
| stated verbatim. I had thrown in a ton of OT getting things
| working (I was young), including a nearly 36-hour run (7am Monday
| to 6pm Tuesday, with a few hours off for lunches, dinner on
| Monday, and a trip home to shower and change Tuesday morning).
| The OT was worth it, I fixed the thing that was blocking us and I
| set it up so that we wouldn't have that issue in the future. I
| identified various areas where procedural improvements would
| reduce our error rate in cases where we had repeatedly run into
| the same issue (or similar issues with a common root cause), and
| it was discarded by this manager with something like the above
| motto and "We don't do that here". This meant that I was going to
| get _lots_ more OT (yay money!) but I just wanted to sleep at
| night again.
| kevin_thibedeau wrote:
| Lords don't like serfs who go about shrinking their fiefdom
| with efficiency measures. That just embarrasses them in front
| of the other lords.
| Jtsummers wrote:
| I left my last job for many reasons, but fiefdoms were one of
| the big ones. I had a manager, when I brought up increasing
| automation in testing, say: But then what would the testers
| do?
|
| My answer was: Automate more tests and test more systems, no
| one is being let go but now we can do _more_ across the team
| and organization.
|
| The threat of losing personnel though, to a reorg as the
| needed numbers changed, was enough to stop managers from
| doing things that would improve their product and the quality
| of life of their teams. It was pathetic.
| gowld wrote:
| A smart manager would use the free time to quietly pay his
| staff to invent something new and useful and then pitch it
| upstairs to grow his fiefdom.
| devlopr wrote:
| I send in my procedural improvement reports and always assume
| they will get ignored. Rarely do I get surprised.
| lumost wrote:
| Many engineers/Creative professionals chafe at being told how
| to work, so they will resoundingly push back on _any_
| procedural change. Usually you 'll find that as an individual
| contributor you have wide latitude to develop in any manner
| you see fit as long as you earn the trust of your manager and
| can satisfy his leadership's tracking requirements.
|
| On paper I often work in a scrum team, in practice I
| subdivide my own work along arbitrary story guidelines to
| make sure that at the end of the spring I have the requisite
| number of points + 20% on average. If someone else needs to
| pick up some work, I'll slice off a whole workstream for them
| - and then we'll subdivide the workstream to have the
| requisite number of points + 20% for them as well. I've
| worked in agile shops for 8 years at this point, and this
| approach has yielded the best results for both myself and the
| company - but "not using scrum/agile" is a great way to be
| viewed as rocking the boat in an unhelpful manner.
| _jal wrote:
| Process improvements are typically valued at zero unless and
| until a director (or above) is annoyed by the issue addressed
| or, worse, their bonus may be impacted.
| numpad0 wrote:
| aka don't fix what ain't broke
| corty wrote:
| Process improvements are perfect CYA. You hand it in in
| writing, get a written turndown because too
| expensive/annoying/whatever. When shit hits the fan, you
| are covered. I like process improvement.
|
| Other than that, I only saw one improvement realized. It
| was one a colleage turned in, got rejected. Then turned in
| again almost verbatim by a manager 2 layers up, who got it
| accepted and got the bonus for it...
| slowmovintarget wrote:
| Or they get read by the consultants who then take credit
| for the suggestion and get paid. Granted, the consultants
| are also a blame sink if the suggestion doesn't work, or
| ruffles feathers.
| chartpath wrote:
| I still do this after 15 years! Commitment means creative
| autonomy though. If valid solutions get tossed out by impostors
| then it becomes impossible to sustain. Or when authoritarians
| and people low on agreeableness traits start trying to make
| everyone predict all implementation details up front under the
| guise of process improvement (it allows unexperienced managers
| to pretend they understand details).
|
| There is a minimum level of mutual co-operation and diplomacy
| required to nurture commitment and ownership, and alas it seems
| so uncommon as soon as a team goes over 5 people IME, unless
| the business is REALLY careful about hiring for openness and
| agreeableness.
| tra3 wrote:
| Steve McConnell is great. Of the "Code Complete" fame. I recently
| read his "More effective agile" and it's a great modern
| introduction to Agile. Lots of actionable advice.
| okl wrote:
| His "Software Project Survival Guide" is great too, a bit dated
| but a great read. Saved more than one project that was close to
| the abyss when I joined.
| zabzonk wrote:
| Better than ""Code Complete" in the context of this post -
| "Rapid Development". Probably the best book on software project
| management I've read.
| nelsonenzo wrote:
| Neither approach is wrong when used correctly! What a wonderfully
| written article.
|
| I feel like 98% of articles and opinions in popular media could
| learn a lesson from this articles template. So often folks are
| busy arguing the obvious extremes that they completely miss the
| point of what actually matters.
| sorokod wrote:
| Reminds me how some children play chess by mirroring the moves of
| the oponent. It sort of works up to a point.
| satya71 wrote:
| Article from 2000. Still seems relevant
| blaufast wrote:
| Isn't the whole appeal of this kind of article that you get to
| believe you are an insider to 'correct' knowledge?
| kerblang wrote:
| > these organizations look at successful companies like Microsoft
|
| Except they don't anymore, because nobody worships at the altar
| of Microsoft, because while they were once revered as Gods, they
| no longer are. Now substitute Google, Tesla, etc...
|
| The tech industry would advance faster if we paid more attention
| to technology than market dominance.
| okl wrote:
| It's from 2000.
| Jtsummers wrote:
| The publication date for the article is in 2000. Take "like"
| and extrapolate to today, you don't actually seem to be
| disagreeing with the author under that view.
| jayd16 wrote:
| Is the business goal technology or market dominance?
| AnimalMuppet wrote:
| This is really more "cargo cult software engineering _management_
| ".
|
| Cargo cult software engineering is also a thing: Patterns (chosen
| without knowing when to use them or why). OO vs FP (picked
| without knowing when to use which, and why). Languages and
| frameworks (chosen without knowing when to use which, and why).
| umvi wrote:
| How to make a cargo cult project:
|
| - Read the latest AGILE books and learn how to be a scrum master
|
| - Choose the _hottest_ languages and frameworks as the foundation
| of the project
|
| - Hire a bunch of developers with experience in those
| languages/frameworks
|
| - Get JIRA and setup a sprint board
|
| - Do a daily standup
|
| - Figure out how Kubernetes/blockchain/marketing buzz can fit
| into your project to help make it more successful
|
| - (optional) Tell devs to upgrade to even hotter languages and
| frameworks as they come out so that your project always uses
| cutting edge tech
|
| - Wait for the airplanes to land
| 29athrowaway wrote:
| You pick a language because:
|
| 1) You can hire people that can use it effectively.
|
| 2) It is robust, production ready.
|
| 3) Emphasizes a set of traits that you are interested in, such
| as productivity, performance, high concurrency, low latency,
| binary size, compatibility, etc.
|
| To the clueless this may seem like bikeshedding and cargo
| culting, but that is not necessarily the case.
| dr-detroit wrote:
| I like how people who don't learn out of school think nobody
| else can
| geoelectric wrote:
| Now that I've been stuck actually working with agile in the
| field for 15-20 years, not sure I think we get to call that and
| Scrum cultish anymore. They're more just popular productivity
| footguns at this point.
| 29athrowaway wrote:
| Scrum exists to expand scrum.
|
| The role of scrum master is about scrum indoctrination.
|
| The authors of scrum created that role to make the
| methodology viral.
|
| The methodology is also vague enough to blame you for
| anything that goes wrong with it.
| geoelectric wrote:
| At the very least, I fully buy they created that role to
| create a secondary market training and certifying them.
| 29athrowaway wrote:
| Scrum works because Brawndo has electrolytes.
| Jon_Lowtek wrote:
| it's what plants crave!
| jodrellblank wrote:
| If the airplanes are VC monies, and those things do attract VC
| monies, can it really be described as a cargo cult if it works?
| woodrowbarlow wrote:
| and the last step:
|
| - figure out something to make
|
| (because the what always seems to come after the how)
| prox wrote:
| That's simple, it's a blockchain federated privacy hardened
| pandemic resistant... thing.
| ajford wrote:
| You know, like Uber meets Facebook with a dash of Netflix
| (for that sweet, sweet ChaosOps) and a sprinkle of...
| thing.
| potta_coffee wrote:
| You forgot to mention microservices brah. If your services
| aren't micro enough, forget about it, you aren't gonna make it.
___________________________________________________________________
(page generated 2021-02-03 23:00 UTC)