Selective cargo culting is great.<p>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.<p>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".
How to make a cargo cult project:<p>- Read the latest AGILE books and learn how to be a scrum master<p>- Choose the <i>hottest</i> languages and frameworks as the foundation of the project<p>- Hire a bunch of developers with experience in those languages/frameworks<p>- Get JIRA and setup a sprint board<p>- Do a daily standup<p>- Figure out how Kubernetes/blockchain/marketing buzz can fit into your project to help make it more successful<p>- (optional) Tell devs to upgrade to even hotter languages and frameworks as they come out so that your project always uses cutting edge tech<p>- Wait for the airplanes to land
This is a good article, written in 2000. I think it was my introduction to the term "cargo cult" way back when.<p>> We call the imposter organizations sweatshops because they emphasize working hard rather than working smart<p>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 <i>lots</i> more OT (yay money!) but I just wanted to sleep at night again.
On a tangent, Cargo Cults in the Pacific are a more complex phenomenon than many people assume.<p>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 - <a href="https://www.scientificamerican.com/article/1959-cargo-cults-melanesia/" rel="nofollow">https://www.scientificamerican.com/article/1959-cargo-cults-...</a><p>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.<p>Interesting to note that at least one cargo cult made the transition into an actual political party - <a href="https://en.wikipedia.org/wiki/Nagriamel" rel="nofollow">https://en.wikipedia.org/wiki/Nagriamel</a>
Anyone who hasn't read Feynman's original speech or just hasn't re-read it for a couple of years:<p><a href="https://calteches.library.caltech.edu/51/2/CargoCult.htm" rel="nofollow">https://calteches.library.caltech.edu/51/2/CargoCult.htm</a><p>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.
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.
This is really more "cargo cult software engineering <i>management</i>".<p>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).
> When presented with more effective, new practices<p>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.
We should be debating process versus commitment, though. “They can both work” is a bit facile.<p>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.
We're heading towards an era of cargo cult where Apple's silicon is viewed as pure magic and developers scratch their heads over why they are now paying 60% to be in the App Store considering that they are doing the exact same things as when the rate was still 30%.
> these organizations look at successful companies like Microsoft<p>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...<p>The tech industry would advance faster if we paid more attention to technology than market dominance.
> <i>… we should be looking for ways to raise the average level of developer and manager competence.</i><p>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.
Neither approach is wrong when used correctly! What a wonderfully written article.<p>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.
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 <i>having a life.</i><p>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.