Cargo Cult Software Engineering (2000)
stevemcconnell.com
stevemcconnell.com
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".
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.
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.
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.
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.
Cargo culting only by name.
EU might have more population, but USA has population that speaks single language and largely zero trade barriers for typical SV product.
Japan has a lot of cultural exporting, but certainly has its differences. And is not exactly known for being internet-forward. Korea is internet forward but is similarly culturally niche; kpop stans are pretty much in their own bubble, one that’s big enough to cause havoc in international music charts but still a bubble. And China’s Internet is double different because of the insulation of the Great Firewall.
Of course, how much stock one actually should put into this is up to the reader.
Is Silicon Valley actually a valley though? Isn't it a plateau? We have plenty of those.
It’s like the difference between a chef and a cook. You can make good food by following a recipe, but your aren’t going to get anything unique.
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.
In fact, they work faster and more reliably than competitors. Office 365 web sucks, for example.
The other big cargo cult you often see is agile. Press an "agile" company on what agile practices the follow and more often than not you'll just get "we do daily stand ups". Ask them what they think the most important rule in the agile manifesto is and you'll get blank stares, they can't even read the cults literature.
- 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
- figure out something to make
(because the what always seems to come after the how)
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.
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.
Shame really, Software Philosophers like Kent Beck kind of got lost in all that noise, who always emphasized the human aspect of software creation
My current employer doesn't do it (they have a 'stand up' but it's just everyone telling what they're working on while nobody listens), and I have no clue when what will be finished - and neither does management.
I mean for my current project which will probably keep me occupied until the end of the month, I got a design document with a pretty decent todo list, but someone had already Decided that it would take about 5 days.
So far they don't seem confrontational or critical about it though, so idk, I guess they're okay with it.
Scrum reports = documentation.
Sources of truth are: the implementation, the business, customer satisfaction. And if you want to go deeper: technical debt, developer satisfaction, developer retention.
The more distracted you get with planning, the worse your product becomes and the more disempowered your developers become.
Scrum can work only if it is kept down to earth. But as soon as product managers stop meeting with developers, you have entered the path to technical bankruptcy.
Scrum is meant to promote collaboration between product manager and developers, but in most cases, product managers get away with avoiding this responsibility. And the reason is because scrum does not have provisions to keep product managers accountable...
Scrum does not define real deliverables for product managers, therefore in practice it becomes the opposite of what it promotes.
That said, I had a project last year where we used a serverless platform for a product / ecommerce platform (Gatsby, Netlify, Contentful, Commercetools, JS/TS) where it worked pretty well.
I just doesn't necessarily create any useful software.
- React / Redux / <and everything under the sun>
- NodeJS + Typescript everything or die
- GraphQL but we don't know why
- React native because we wouldn't know what native is
- Postgres with replication and fail over for 10 concurrent users
- Docker everything on AWS <every possible keywords>
- Don't forget lambdas, but batch with Kafka first
- Route 53 just cause the name is too cool not to have it
Joking about their Angular rewrite into React is a fireable offence.
See you in 2 years. /s
I think a lot of this “using frameworks without knowing why” is just because people read articles about them and how-tos and get excited too quickly, and Google just shows way more tutorials about how to do something in React than in plain JS.
What are lambdas in this context? I thought those were just another name for closures?
> 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.
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...
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.
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.
Is that the big five personality traits? Seems as if in your experience they mean something for workplace performance and team efficiency?
> openness and agreeableness
Tends to create better teams?
How come you've heard about the big five? (You didn't study psychology?)
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.
(If you're the interviewer, looking to hire a manager)
Makes sense, humans are so good at quickly learning what sounds good and others want to hear, are they not
Whilst at the same time I'd suppose such extremely short-sighted selfish lords are at least a bit rare, also among the humans.
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
Replace “whites” with “establishment” and “cargo” with jobs and “the apocalypse” with revolution and you have the essence of a conspiracy theory or extreme political movement.
Edit: this next bit is disturbingly prophetic:
> Of course the cargo never comes. The cults nonetheless live on. If the millennium does not arrive on schedule, then perhaps there is some failure in the magic, some error in the ritual. New breakaway groups organize around "purer" faith and ritual. The cult rarely disappears, so long as the social situation which brings it into being persists.
Say a dozen crates of stuffed Pokémon toys and one crate of carabiners.
https://calteches.library.caltech.edu/51/2/CargoCult.htm
For mine, it is one of the great pieces of writing/oratory of the last couple of hundred years and addresses so many of today's issues head on. It would be nice if it became very dated, let's work on that.
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).
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
Will the company pay someone else to take my wife on a 2 week romantic get away?
If they did, you'd have a lot more free time for them to exploit in the future.
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.
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.
The simple solution is no meetings after 15:00.
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.
/s :)
That's basically the business plan in a lot of places.
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.