I respectfully disagree. Things look the same only if you look at the same things.
Fashion and trends where always a thing. They spread faster and more globally today because the communication is rich and easy, and of course there are a lot of followers of any trend.
But, not everything is "average". That bell curve is probably very high today, but there is a lot beyond the ±σ , just need to look there.
There used to be more regional diversity, though. Things had distinctive characteristics that could easily be associated with the culture that produced them. A German car looked restrained and taut and had no cupholders. A French car looked kinda unusual and Avant-garde. Now everyone is driving the same blobby thing with several cupholders decided after a customer survey among Americans driving through McDonalds.
McDonaldization = globalization? The world is smaller now than it was in the 80's, and even then there were trends in design and fashion that spread across the world.
They are not quite the same idea. In a globalised but diverse economy, a Japanese buys a Swiss watch and a Swiss buys a Japanese air conditioner. McDonaldization refers to the incessant urge of Western societies to over-rationalise every aspect of the economic and cultural life, resulting in bland uniformity. It is a progression of Max Weber's ideas on bureaucracy and rationalisation.
I think globalized but diverse was always kind of a pipe dream because along with things you're trading across the globe you're also spreading information back and forth. And as the article points out, human preference is roughly the same in aggregate across the globe, so we all loosely converge on a local maximum of "the best" rinse, repeat, and you suddenly get homogenization.
> there is a lot beyond the ±σ , just need to look there.
Of course, the world if large and kaleidoscopic. But the rate of homogeneity in the middle 80% is higher than it's even been, and that really affects everyone.
I actually want diversity in the mainstream, since some projects are only enjoyable if you can share them with others and if they get the most talented people to work on them.
The fact that nobody would make a Doctor Zhivago or even a Back to the Future today is not something I can fix with all my searching.
> The fact that nobody would make a Doctor Zhivago or even a Back to the Future today is not something I can fix with all my searching.
What do you mean by that?
I'm not familiar with Doctor Zhivago so I had to look it up, the 1965 film is based on a 1957 novel, which seems to match just fine with the pattern of The Martian, The Three Body Problem, Game of Thrones, Fifty Shades of Grey, etc.
Back to the Future is a fun trilogy, but the first film was mostly set in 1955 (so if it had been done today the past would have been 1994, compare to Captain Marvel being mostly set in 1995), the second film was 1985's idea of 2015 (and we still get plenty of what-if fiction in the near-ish future, e.g. Blade Runner 2049, Cyberpunk 2077), the third was yet another wild-west Cowboys-and-Indians gunslinger (1885) — but if you mean to focus on the more playful and fun aspects of how it was put together, or the positive vibes of good people working to solve problems and where it's clear who the goodies and baddies are, BttF reminds me more of The Orville or Lower Decks. (And The Martian if you want to consider the environment/time travel itself, rather than Biff, to be the problem).
I don't mean in broad genres, but more in terms of the range of emotions and thoughts that the top movies of the year evoke. The Martian is great movie, and does thankfully hit a different spot than the generic dystopian Sci-Fi, but there still seems to be a compression of that range, one which unfortunately nobody can quantify so that's why it's mostly opinion here.
For that issue, I think that as any medium ages, it transforms from "explore" to "exploit", which is also why films have a lot more sequels and reboots.
So, if you want more range, explore new media: games, youtube, etc.
> For that issue, I think that as any medium ages, it transforms from "explore" to "exploit", which is also why films have a lot more sequels and reboots.
I've never agreed with this argument, it just felt like an excuse. For 100 years movies kept changing as society also changed, and all of a sudden they hit the exploit phase somehow after 2000, when GCI was still improving.
Movies are in part a product of a social climate, and that climate is never static, so to me it seems like there should always be something to explore. It just seems that financier no longer want to put any money in exploring, and culture becomes poorer while the GDP grows.
It wasn't a sudden change, it's been a gradual tendency towards them. James Bond was already 19 films by the turn of the century (or 20 if you include the other Casino Royale), King Kong and Star Trek both got to 6, Batman 8, Star Wars had just had the 4th, Friday the 13th had reached 9 films.
Even BttF itself was three films, and in the second one was parodying the tendency towards sequels with the holographic Jaws 19.
there are a million million subcultures with pretty stark differences in taste/aesthetics that you can dig up on the internet. looking at what's grossing in mega-dense populations of millions of people then yeah, perhaps in aggregate at large N, things their individuality -- surprise?
there are parts of every major city that feel the same, but if you're willing to take a train out 45 minutes in any direction without google maps, i'm willing to bet you get into spaces that are incredibly local!
Honest question: but what can a company really do if it goes bankrupt and shuts down, since there is no money to pay for infrastructure and workforce?
Of course, they could probably release code to the open-source. Still someone needs to run the service. Also, if the code contains intellectual property, wouldn't existing investors enforce the company of selling the IP rights in case of a bankruptcy?
I am not taking sides here, just trying to understand what options a company (any company) could explore in this case.
If you sell a product with a promise to run servers for N years, you put a deposit to run servers for N years, or you have a contingency plan to let a third party run it for N years after you went out of business.
If you can't deliver on a promise and didn't make a good faith effort, maybe you committed fraud.
I have no idea about bankruptcy law -- does the company defaulting on their contractual obligations make their customers their creditors? Maybe the customers are entitled to get rights to whatever code the company had and is free to run it at their own expense. Or maybe nobody really cares enough about 800 dollar teddy bears.
Allocate money for 5-10 years of support for this contingency, beforehand, as long as the seed round is secured (so in this case: in the past). $800 is an okay investment for a household item for 10 years. For 2-3 though, or even 5? Not at all.
Sounds like you can't sell the product then. Maybe the product is bullshit and it should not be on the market. General sentiment in the comments says the product is bullshit and can't work. Maybe it's correct. Or maybe you should be smart about it somehow and invent a contingency plan and legal structure that doesn't involve putting that much money into escrow. And everybody who isn't that smart will become rich.
Imagine you have 10k and want to become rich by building a luxury appartement building. Can you start selling property titles without first having funding? Can you raise capital, sell not-yet-existing properties, then close up and expect everything to be okay?
A few years ago, I was a frequent visitor to a public swimming pool, same day, same time. Apparently with similar swimming habits, there was an elderly person who was humming all the time. In the pool, in the shower, in the lobby, rather loud but not too much. I initially attributed it to elderly quirkiness. It was only after several encounters that I realized he was blind. The point is, I only figured that out when I saw him with a white cane outside, not at all by the way he moved inside or used the objects - he was navigating the space just like anyone else, and it was a rather crowded place. That was the day I learned that echolocation in humans is a thing.
I feel like a pool is an especially good place for it too. Everything is hard surfaces, providing a good echo. The ambient noise probably helps a lot too with not needing to make noise yourself.
I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here.
The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want - but we all need some form of organization.
The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place. But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight. Less is more.
Just as one example:
> "We don’t do Figma mocks. We don’t write PRDs. We don’t really have a design system. We don’t do agile.".
Well, right from the Agile manifesto:
> "Working software over pointless documentation."
So it sounds like we've come full circle. That's really a pity. I wonder how we can break the cycle. I also think we should take a look at the original ideas in the old-school methodologies (Agile, etc.) because they’re not bad, just abused. They were created 20 years ago by people who were in the same situation we are in now, so there's a lot of wisdom there that shouldn't be outright rejected.
Agile and Scrum was great when it was introduced bottom-up and then accepted top-down.
"We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together.
The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely.
The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database).
Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.
The top-down recognition was useful - not only did projects go noticeably better, managers could also boast that they, too, are now doing this new Agile thing! And they didn't even need to do something!
That was all before Scrum of Scrums, SAFe, LeSS, you name it.
As you said, we've come full circle in many aspects. It's ironic.
Sorry for a bit of a blunt comment following -- but your rose-tinted view of even the original Agile / Scrum ticked me off. I have to push back here, severely so.
> The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely.
You should qualify your statements with "for me" and "for our project" because dailies have not been a net positive over my 23 years long career. Yes, not even once. I can't remember a single time I enjoyed them, nor a single time they ever helped me with anything at all related to work.
I am not introverted, nor autistic (though I very likely have ADHD). I am quite outgoing in fact, yet I will hate the dailies until my grave.
The only thing they achieved was put some juniors back on track because when they get blocked they also close up and don't talk to anyone (for whatever reasons that I'll never understand apparently), and give excuse to introverted people to open up a little and have some casual chat. I am not against the latter but I dislike work meetings being hijacked and turned into half therapy sessions.
I've suggested to them to do periodic screen-share pair-developing sessions, they did it, they absolutely loved it and kept doing it even after I left, and us who didn't want to do casual chats in supposed work meetings enjoyed the work meetings slightly more. Everybody won.
> The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database).
And again, please add "for me" and "for our project". Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers I was ever under viewed them as: an opportunity to "correct velocity".
Masters whipping up the slaves because they don't pick cotton quick enough. Try and sugarcoat it as much as you like -- it's that and it was always that, and the people in power will always try to swing everything in that direction. It's who they are. It's what they are.
> Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.
Really cute, until you had my life and career and saw the "scrum masters" being one of the managers cousins who saw an opportunity to give them income while pretending they are useful.
In my defense, I never witnessed a managerial system that helped me, so bear with me here.
> "We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient.
And for the third time: maybe in your teams. I worked in no less than 6 teams that did this very, very well. To the point of us not needing a manager because I and one other guy (we were 7 in total) basically said "OK, things A / B / C are more or less done but we still need X and Y; me and Joel are busy with infra stuff, anybody wants to pick those up?" and somebody always stepped up.
Is that what a scrum master is supposed to be doing? I've never seen it though. But we managed to distribute load and responsibility between ourselves pretty well.
Predictably, that team was eventually disbanded because we had actual power during the executive meetings (me and the other guy attended them). Nobody likes programmers who can push back in an informed manner that ruins the CEO's prepared graphs and slides. Who wants their beautiful illusions shattered by facts? Not these "adults" for sure.
And yes all of us left shortly after. And yes 3 out of the 7 of us were called back some months later to fix the messes of the others. We beat the code back into shape in less than a month, charged them triple and laughed our way to the bank.
---
Bigger point is: we all know the beautiful theory. But there are people out there who don't like it and want to skew the practices to what serves their interests, not yours and not mine.
Glad that you had such a positive experience. Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.
Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere. Reading through my post I do think it's sufficiently obvious, as I am specifically mentioning how I remember certain projects.
Looking through your counterpoints I think I need to emphasise my opening sentence a bit more strongly: It was fantastic _when it was introduced bottom-up_.
This is important, because the ceremonies were all engineering-driven and managers usually not present. So there was no rushing and "whipping" during the retros, there was no scrum master being the manager and everyone wanted to be done with the daily quickly, and so on.
> Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.
I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.
> [...] over my 23 years long career.
Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.
> I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.
Agreed, and apologies for the assumption. I got a little bit pissed, not at you though. :)
> Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.
Oh I know, but I believe both you and I witnessed a lot of similar techniques during our careers. At one point they just figured they'll give them a lot of names.
> Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere.
Yeah I know I was a bit difficult here, my idea was to bring visibility to our different bubbles. I've heard positive stories about Scrum / Agile many times but I am yet to live in one. :(
Sounds like you worked in some dysfunctional places. If things worked that bad on the communication/management level, I'm not sure any system really had a chance of working well. If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this.
I've never seen a perfect place, but I'm sorry you had experiences like that. There really are places which function better and actually do friendly cooperation across levels.
> If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this.
Oh, absolutely. Agreed. That's why I left several places during the course of the last 10-ish years.
> I've never seen a perfect place, but I'm sorry you had experiences like that. There really are places which function better and actually do friendly cooperation across levels.
Well, I just recently finished a limited term contract and started looking for a full-time employment (contracting is exhausting). Shout if you have anything. :) I mellowed out quite a lot in the last years and my comment above is just a triggered reaction.
Regional work culture is a thing and it took me a long time to start looking outside of that bubble. I was pretty stupid when it comes to work negotiations and people abused that.
Secondly, I don't think you'll find many programmers praising Scrum.
But, think what you will. I'm absolutely the villain, congratulations, you cracked the code.
Same here. Daily stand ups (no matter if they last 5 min. or 20) have not being useful for me any single time. They are used by managers to force us to show what we have been doing the day before. No more, no less. If I ever get stuck with something, I go and ask for help to my colleagues; I update the corresponding Jira ticket status and whatever is needed to keep my work visible.
Same for retros or any other kind of ceremony. They are just for managers.
> Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers
Dude, no. Kick managers out of the retro. The retro is a place for uncomfortable candor between peers, not another place for your manager to hold court. They need to leave the room while you decide what’s a problem, and what is not a problem (yet). Once you have a plan on the table you can bring the boss back in to discuss the redacted summary of the meeting and any proposals that require their assistance.
They didn’t work for you because you’ve done them wrong at every single place. I’ve had to fight twice to do it right, but we won both times via solidarity.
I haven't "done" anything. They were forced on me.
I get what you're saying and with time I started fighting for something 90% the same as you are describing. But most of the time I had no choice. It was "our way or the highway".
And since I was financially and career-wise extremely stupid for most of my life and career... yeah. I worked with idiots and slave-drivers.
I am looking to finally change that by changing the way I conduct myself. You hiring? Yeah, I didn't make myself an excellent advertisement with my original comment but at least people will know where I stand.
I've met some pretty obnoxious and difficult programmers but statistically most managers I ever met were difficult.
So yep, agreed with your point.
Problem with hiring good people is that you also have to give them the space and time to show their talents. Shoving them into meetings mostly aimed at people who are bad at communication and/or are junior in terms of abilities is the best way to destroy their motivation.
> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.
At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.
Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.
management is very creative, they just sometimes don't realize that agile is not a management process, it's an engineering process. it's an easy mistake to make because they want to measure engineering output somehow and introduce measurements which cause decoherence of the engineering process state if I may use a quantum analogy instead of a car one.
IOW they're trying to do their jobs (manage employees) but engineering is a high trust profession and some managers just don't have the trust (not to say that all engineers have the integrity...)
That’s because Scrum is so easy to turn into a management process. It makes more sense to them than all the other forms of Agile combined. So like children reaching for candy instead of vegetables, or who will only eat carrots as a vegetable, you have to work to make them reach for something else, otherwise they will be unhealthy.
> agile is not a management process, it's an engineering process
That's interesting - I've always thought of it slightly more broadly as a team-running process. You don't have to be doing engineering to do it; you might be building a website in Wix. You just need to iterate and inspect. What do you think?
What you described, I wouldn't accept generally under my definition of creativity.
In order for creativity to be such it must ultimately deliver value; managers "doing their job" in ways which hinder instead of supporting engineers is not creative, it's disruptive.
> At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.
I think most commenters on HN understand this.
But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades to understand Agile (Scrum et al) can fail just just as often and is as prone to mismanagement and meddling as the methods it was meant to replace.
It takes a strong team (leadership and stakeholders included) to make Agile work and reap its benefits. But such a strong team will probably work well with whatever methodology -- strong teams are effective regardless.
What about average teams, which Agile was supposed to be helping? In my experience, they'll fail just as often.
A method that works for a team of focused superheroes is not really applicable to the general population of developers.
Capital-A Agile is for companies that want the benefits of agile (higher velocity) but don’t want to trust their employees or make any meaningful changes in how the management team operates (micromanagement, committing to rigid feature scopes on rigid schedules).
Obviously this doesn’t increase work but companies get to say they are “agile” and the management team gets to keep doing all the counterproductive management they were doing before. No hard conversations about changing how management operates or unpredictable things like giving engineers autonomy.
This sounds cynical on its face but it is my experience as well. Management does not actually trust engineers to provide value without close oversight (sometimes with good reason!), so any framework that purports to give engineers more autonomy will eventually be subverted by the management. And since management always has more power than line engineering, they always win.
The only way for "true" agile to really take root would be for management to trust engineering to add more value on their own than when being micromanaged. That's a tall order, and gets much taller in larger organizations.
Agile is not there for higher velocity! It is sold to management that way often, but intrinsically - no.
Agile though is meant to reduce waste. In other words, you don't march faster, but are supposed to spend more time marching in the right direction. (I personally loathe agile and find it intrinsically broken.. I just find it kind of funny that a process oriented around dynamic environments is supposed to give predictability and speed, when it gives neither. If anything, a lack of predictability since direction can change)
I think there's some truth that process slows down development. (Full disclosure, I work for a company in the same space as these folks.)
I love a provocative essay as much as the next person.
But the authors are in a relatively new, smaller company focusing on devtools[0]. This has a couple of ramifications related to process need:
- they are the customer to a great extent, so they don't need to involve external customers to discover what is needed.
- they are fast followers (an OSS WorkOS competitor[1]), so can rely on product need discovery from other competitors. That's not a bad thing (I've done the same!), but it isn't sustainable forever.
- they have a small team, which means everyone has autonomy and knowledge.
- at the size of 2, they don't have other departments with schedules and deadlines and goals. Process is critical to getting input and coordinating across departments to achieve company goals.
All of these factors mean process is an impediment without any benefit.
Not every company is like this company. Not every dev team is like this dev team. My opinion is that this company in three years won't be like this company is now.
I'd wager that in 3 years, if ssoready is successful, there'll be process. It'll be an impediment but a necessary one, as the attributes they currently have won't be enough to keep delivering.
Happy to bet on that if either Ned or Ulysse is reading :)
Every team has process. It doesn't matter if it's documented or not, or whether improvements (or impediments) are intentional or not. Every team has their process.
Source: Identifying teams' principles and practices is one of the tools I use.
Agile, in practice, has turned into "disorganized waterfall." Witness absurdities like the existence of the "Agile Gantt Chart for Jira." The reason Waterfall, or modern Agile, are the way they are, is that they are systems that allows the smallest possible number of people to take responsibility, while allowing everyone to perform accountability. Basically nobody wants to lay it on the line and say to the CTO, "I'm going to make this project succeed." Much easier to say, "we're using best practices and modern processes."
This is a consequence of failing to train managers, especially in the moral dimension of management, which is entirely about accepting responsibility, and of promoting into management individuals who are not prepared to do so.
It turns out for large cross-team initiatives, organizing the work is as hard as doing it.
I like the example of internationalization. You need involvement from all parts of the product to release it - you rarely can sell a half-internationalized product. You need to work with external teams of translators who need to be fed the work in a consistent interface. There will be pieces of the work that nobody is going to forsee (e.g. pulling text from the database) that will be surfaced and handled consistently.
So, to get it out, you need to have each team prioritize the work. You effectively need a deadline, or the work will never happen. (The work is valuable for the company, but does not drive any individual team's customers.) You will have dependencies: Team A has to address part of the work before team B can. And you need a way for teams to report that they are done so that it can be reviewed for consistency across the product.
This is a bad fit for most agile methodologies, but you're not going to take everyone out of it temporarily and then go back in. So you have to accommodate a project within your system.
But these exceptions become more and more common as your company gets bigger and bigger. The only truth that I can find is that the only way to stay agile is to stay small: small teams naturally do the things that are agile.
The Agile manifesto is great. It is simple, straightforward, and most importantly, it clearly defines itself as a statement of opinion, with a counterpart to each of its value. And yet so many people do exactly what the manifesto tells them not do to. Why? Just why? It is as if a clothing brand has "beach and sun over mountain and snow" as its value and people go to ski with them and complain that they get cold.
Agile is not on size fits all, sometimes you need comprehensive documentation for instance. In this case, just don't do Agile, the manifesto is really explicit in that it is not the right methodology for you. But for some reason, Agile is fashionable, so you take it anyways and try reshape it into the V-model you should have used in the first place and get the worst of both.
> And yet so many people do exactly what the manifesto tells them not do to. Why? Just why?
The manager on the top says "do Agile" because his friends say that this is now the cool thing. The managers on the bottom have no idea what it means, so they do some random thing and call it "Agile", and report job done. The manager on the top is happy and gives them a small bonus.
And as managers circulate across companies, they keep introducing the "random thing we did at my previous job and called it Agile" as the one true Agile, so the whole randomness converges to one specific version (with Jira and long meetings and other stuff).
Much of this has, I think, to do with mutuality. If person A and person B need to work together both need to change their preferred way of working to accommodate each other. In larger groups there is a problem if one person gets to decide on too much and does not have to take other people seriously.
And that usually breaks, as another reply said, when the manager of the two people delegates responsibility for the problem getting solved to one of those two people instead of keeping it for themselves.
If you have a boss who cares whether the task gets done, you can’t make excuses about how it violates your moat to have to do it. Shut up and help your coworker. Now. Or you’re on PIP.
The coworker who isn’t getting useful collaboration gets blamed for their soft skills, when it’s the boss’s soft skills that should have reigned over both.
The fundamental issue, I think, is that there is a strong tendency for management to value process (measurable) over progress (often seems like nothing for weeks or months and then bam out of “nowhere” revolutionary new features.
Agile, scrum, etc al are supposed to be guidelines for engineering teams to maintain coherence on progress, but they describe a process, so inevitably management either interjects in the process, tries to use it as a handle to control the process, or pulls engineers out of the project to “manage” the process… all at the expense of progress.
Management can’t see progress, but they can see process. So naturally, they become focused on what they can see, and conflate the process for progress.
Take a hopelessly disorganized team, apply any, literally any, management framework on top of that team and productivity will increase.
Since management frameworks do not contain intrinsic fixpoints, keep applying the framework and things will halt to a stop, because whole effort will be spent serving the framework. Ditch the framework, start doing random stuff and productivity will magically increase.
All developers know all the wisdom. Everyone who had a manager knows the problems in any process.
The only ones who seem to not know or see or understand the problems are various layers of management. This is weird because ostensibly that is their one job.
I can understand how a junior manager who only worked one year in the industry can get fooled into believing in the rigid processes with pointless artifacts.
But if you worked building software for five or even two or three years, I cannot possibly imagine how one goes about their day managing a software project in this fantasy land.
By “manager” I mean all the chickens that decide how the pigs work, and all the chicken in pigs clothing. I do not mean all kinds of management.
"Hire former software engineers at management positions" would be the answer, but of course there are various factors that makes it difficult to do so.
In theory, management should be held accountable for getting in a way, but it is not possible either because of the nature of software development: one cannot really measure productivity because it is to a more-or-less large extent a research activity.
I think probably the best option is to introduce some more democracy (or rather "technocracy" in the literal sense, "power to those who build") in the mix: management evaluated and chosen by the engineers. Call me communist all you want...
I think the issue with Agile was that it was named. After something is named and codified it becomes a thing and everyone can mangle the thing to fit their desires until it becomes antithesis of the initial intents.
This guy doesn't name or codify his approach. So it's fine, there are only intents, there's barely anything to mangle.
We never went anywhere. I had such high hopes for the agile manifesto when I first read it in 1999. "Whew," I though, "finally, they realize that software can't be managed like an automobile assembly line." Nope, they just rebranded the "manage software like an automobile assembly line" methodology as... AGILE! Don't get me wrong - the signatories on the agile manifesto did seem to understand how to realistically plan and manage software. Nobody else who read it and had any position of authority seemed to.
There is no breaking cycles. Humanity is on an approximately periodic 20-year oscillation around the mean. Just look at programming languages, ai cycles, web iterations, etc.
It's just human nature - we deplore the tools our parents used.
However, as long as that mean drifts in the right direction!
I didn't take the article as a "lack of organization" is best. I took the overall theme as that most methodologies are a distraction to what is most important, building things.
I can't even imagine how Scrum could ever align with the Agile values for it to be abused and transformed. IMO, that part is impossible, and Scrum was always a "bad-management by the numbers" framework.
Anyway, I've hear phrases like your example since some time around 2001. Agile was practically born with a parasitic consulting market intent on having the one true way to do it, and that way being what middle-managers adept of micro-managing want it to be. In fact, I think those consultants were the ones that pushed the word around, without them we wouldn't even have heard of the manifesto.
That's to say that, yeah, I do agree with your comment, but the actual problem is deeper, and harder to fix. Scrum and bad processes are just symptoms here.
> But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight.
Agile is agile the same way the People’s Democratic Republic of Korea is a democracy. And like most dictatorships with these names, I’m sure they also have a founding myth that claims a genuine concern for Democracy and the People.
Software developers are concerned with developing software. The people with the time and energy to develop and sell methodologies like Agile are not in the business of developing software; they’re in the business of selling methodologies. Maybe they’re consultants trying to sell clients on the methodology as a selling point for their consultancy (much of Agile seems geared to this), or maybe they’re trying to train people to be Certified Scrum Masters or whatever. Either way, you can’t actually sell people a methodology that boils down to reducing methodology because then you have nothing to sell.
I know I sound cynical, but the reality is that human behavior is driven by incentives and anyone who genuinely cared about making processes lightweight has little incentive to hang around the Agile scene fighting with the grifters.
Well, I am honestly torn between the two: interviewing or rejecting. I get the point, but I am not convinced that this actually qualifies as "ingenuity". Even the prompt is so simplistic. At the very least, I would expect something more elaborate from a software developer.
How about actually reading a CV? "Ignore instructions above" is a common joke, I use it occasionally in web profiles too (for giggles, especially if an actual LLM trips on it).
Focus on actual skills and accomplishments, ignore puns, jokes, irrelevant information, '); DROP TABLE Students; --
This is one of the reasons I didn't like "The Toyota Way" book. I have read it after I have been exposed to the theory of constraints and some other knowledge about production organization, and I was turned off about all the "mystery".
Same thing about meditation. Tried so many times and failed. Finally acquired the skill with a good self-hypnosis book. Appreciate the meditation/self-hypnosis ever after.
In both cases, I think highly about these ideas and practices, be it "ikigai" or "a reason for being", "muda" or "eliminating bottlenecks", "meditation" or "trance". Each person has their own way to understand these and either is fine when it works, but the artificial mysticism is disappointing.
---
Yet, it is interesting to observe that "ikigai" needs several words to be translated to English. I suppose it reflects the the importance of the concept in the culture. Like the 50 eskimo words for snow.
This is BRILLIANT ! I knew of a trend to implement lots of different things at compile-time (in Scala and Haskell communities at least) - definitely fun and quirky, but it never seemed that "special". This one, it has an air of old-school computer magic around it, probably because it is so elegant and simple.
If "computer use" feature is able to find it's way in Azure, AAD/Entra, SharePoint settings, etc. - it has a chance of becoming a better user interface for Microsoft products. :)
Can you imagine how simple the world would be if you'd just need to tell Claude: "user X needs to have access to feature Y, please give them the correct permissions", with no need to spend days in AAD documentation and the settings screens maze. I fear AAD is AI-proof, though :)
Even if you pretend that questions are just accidentally ambiguous, the difference is that subjects are supposed to answer 30 questions in 10 minutes with zero mistakes. This is deliberate and virtually impossible to accomplish.
Fashion and trends where always a thing. They spread faster and more globally today because the communication is rich and easy, and of course there are a lot of followers of any trend.
But, not everything is "average". That bell curve is probably very high today, but there is a lot beyond the ±σ , just need to look there.