Moxie Marlinspike: Agile is killing software innovation
theregister.com
theregister.com
We have this idea in modern management theory that responsibility and decision making must travel up the corporate hierarchy. That execs are best positioned to make product level decisions. Or decisions of any kind. And peons at the bottom - the “individual contributors” who do all the programming must know the least about the product.
But that’s completely backwards. The people on the ground in any organisation know the most about what’s really going on. If we disempower them, and try to turn software engineering into an assembly line process (jira tickets go in, code comes out) then of course programmers stop innovating. They’re explicitly, and intentionally distanced from their capacity to improve the product in creative ways.
To be clear, I also don’t think the answer is to pretend we’re all equal and have an entirely flat management hierarchy. Different people have different skills, and a healthy organisation needs lots of talents to thrive. But there’s lots of ways to do that which don’t disempower the people on the ground.
The book Reinventing Organisations is a gem of a book. It totally blew my mind on this stuff. It talks about all sorts of different ways that innovative companies have upended their corporate structures, and along the way have been able to get the best from their people. If / when I start a company, I’m tempted to make it required reading.
The problem is that the decision making is not about the product. The decision making is about making money. Unfortunately, for a lot of companies, making money is not equal to building good product. IC is completely unequipped to make decisions that would maximise the company top/ bottom line (this is a descriptive statement, and it is not about the individual either: modern corporation is famously broken)
I think in most cases, building a good product makes money in the long term. In the short term it might be possible to make money despite having a bad product, but as soon as the short term ends... look at Boeing and Intel.
Right; companies want and expect ICs to keep their heads down and close tickets. Of course they’re ill equipped to make decisions outside the scope of their job role. If you expect nothing of someone, they will give you nothing in return.
I recently started work at a new company that tries to turn everyone in to a cog. No agency, every step requires other teams and people that may or may not respond. It's maddening.
It is almost like the modern software enterprise optimises towards minimising productivity, an emergent self-sabotaging. Everything is just avoiding responsibilities and blaming the proces, others or just the universe in general for things going to shit.
Anyway, I'm going to read that book now before i start my own company ;)
I really don't know what it is, but the corporate folks are just obsessed with hierarchy. It feels like it's in their blood. Even at the lower levels, they want to move up the chain so that they can have "real input," and they believe that culture must be set "from the top." Why? This is certainly one way to run things but it's not inherently the only way to run things. Individual teams _can_ set culture, and an individual team _could_ have better input on a strategic decision than the "decision makers." It just seems to be a forgone conclusion in the corporate world, and I can't see any reason for it other than status-seeking.
You should read "The Dictator's Handbook." While it primarily applies to politicians in both democracies and authoritarian regimes, the thinking proposed in the book also applies to the corporate world. In other words, some people thrive on power, but these individuals are not always the best for the company due to a misalignment between their desires and the company's needs. Nevertheless, the system still works because... well, just read the book (or at least a summary of it)!
I'm somewhat pessimistic about corporate culture: companies have an instinctual drive to hunt for profit. If they didn't, they would go extinct by going bankrupt. This leads to a self-selection process that explains a lot. Combine this with the tendency of some people to strive for power—as you mentioned, "they want to move up the chain"—and we end up with a somewhat toxic mixture in today's economy.
Regarding the topic "Agile is killing software innovation," I would argue that it's not Agile itself that's stifling innovation, but rather the emergent structure and behavior of corporate entities. The combination of power-hungry individuals and profit-seeking companies stifles a lot of potential. It's highly inefficient and causes considerable misery, but it seems to function just well enough to keep the economy limping along.
One of the saving graces of corporate entities is their ability to buy up startups, for example.
And it's an extra hard war to fight in part because of what Moxie is saying, which I appreciate. The agile style promotes a cancerous software growth. Delivery deliver deliver, all the time, features forever.
It's good to be value minded, but making good long term decisions, thinking through your software and where it's headed, making long term decisions, and having artifacts and buy in for these long term plans is setting yourself up to resist the rot and decay that agile so easily lets in.
Agule and books like team topologies don't really have any commitment to the software as a whole. The team has a compact to ship ship ship ship, and so does every other team. But it imagines them all as islands, with only some interdependence. I struggle to think of examples to make this clear, but good software is holistic, good software tries to slam concerns & create smoothness across joints.
When agile lets software grow to be so very discombobulated, even if the corporation wants to be bottom up, the chaotic software architecture keeps engineers from seeing and springing on good ideas. Our potential as engineers is defined in sizable part by what we can understand and how well we understand the internals of our software, how well everything fits together, how legible the system is. Agile actively destroys this kernel for understanding, sacrifices the engineer's greatest leverage, for short virtue, for the reward of always be shipping.
If agile hasn't so overwhelmingly become a license for teams & product to do whatever, so long as the features keep shipping, the engineers would be in a better stance to have executive will & function, be able to go out there & steer & direct; we'd deserve to be heard better. But we are kept low by the thrashing chaos that comes in the absence of thinking ahead. The technical inadequacy erodes our ability to make political/organizational progress.
Most corporations are mediocre, slow to change, and their software projects are just not ideal. And agile is a mindset to accept this, focus on the people, both devs and stakeholders (who fund the project, and ultimately the company that pays their salary). Probably by now it's a cliche to reference the first line of the manifesto, but... people above process, etc.
Agile sets the stage, helps grease the gears, by default it doesn't keep the project "accountable".
How the actual plans come out of it is up to the actual team, the leadership (where the classic fish and head olfactory law applies).
Islands and cliques form naturally anyway. And in some sense it's okay, because making too big plans tends to fail. (Again, agile at best nudges folks to think about commitments, what their work items mean for the team, for other teams ... but if course the further the others the less relatable is the importance of their needs.)
> we'd deserve to be heard better
yes, of course. and other "bottom feeders" too (excuse my phrasing), and middle managers too ... alas corporations tend to be broken as I mentioned.
And as a consequence, I found that outside our vocal minority most people develop the "if I don't care it doesn't hurt" mindset, they do want to close tickets and nothing more.
This is the mindset, and a huge problem. But Agile does not cause it. (Or solve it, of course.) Money causes it. Features bring money, more than other things, most of the time. Money in the short term. And few managers seem to care about the long term.
If anything, Agile is liked by managers because it claims to allow building features non-stop.
The part that I think is not working is that managers neglect one of the basic behaviors they should be engaging in. Weekly one-on-ones done properly. That's the place for information to go from directs to managers.
But I'm not convinced that Agile is really to blame for the compartmentalization of knowledge and down-skilling of software engineering, as it has happened in every other industry too. It seems like a tendency of mass production. Car companies may be founded by small teams of master generalist mechanics, but they end up employing hundreds of thousands of ordinary technicians who know only what they need to know. Same for furniture factories and carpenters. Why not for software too?
He’s complaining that hierarchical silod black box teams are bad. Early agile was advocating that was bad!
The bigger issue is that Agile doesn’t mean anything anymore because when it came about it was just a reaction to the previous form of software management. It was at most a few completely different methodologies agreeing on some high level principles. You had to pick one of those methodologies to get any real practices out of it.
And many of those practices would today seem like no brainers. Of course we should be merging everyone’s software frequently (do quarterly merges exist anywhere anymore? They did). Developers writing automated tests is near universal now, it was rare then. And with the rise is SaaS we’ve taken frequent deployment to a level unthinkable when Agile was developed.
When people complain about “Agile” now it’s meaningless. It’s a catch all for everything unpleasant in software planning and coordination, just like waterfall was when Agile was ascendant.
You can make sense of the framework-ization of front-end that way. Monkey pick pre-fabbed block from framework basket, monkey wire together blocks, monkey get banana. But of course the reality is far different. Monkey no troubleshoot or bug-hunt. You need humans for that. Skilled labor.
My issue with them, though, is one that I don't usually see spelled out very often. All three promise, whether directly or implied, freedoms and responsibility being pushed further down the org chart. In reality all three are implemented in a way that further centralizes control towards the top of the org, leaving independent contributors at the bottom feeling almost entirely powerless.
I've always wanted to see a company flip OKRs on their head. Every employee should define key results for their little corner of the company. Managers should be responsible for taking those as fact and working to build a direction for the team that aligns as many of those results as possible. By the time you get to the top you have leadership setting the company's direction based on what the employees know to be most important rather than leadership seeming to energy on a hilltop to force key results down on everyone else.
Bottom up, not top down. Hire well, train well, and trust your people. It could fail spectacularly but at least your people would be respected and enjoy the ride, and we'd all learn something about the pros and cons of running a company without a dictatorship.
For example, in my experience, people will only take initiative if they believe that they’ll get support from their team and manager for doing so. If not, they’ll bitch and moan about how bad things are but if you suggest fixing things, they’ll insist that change is impossible.
Again, it isn’t a bad idea, it’s just something that only works when you have a lot of senior engineers that have experience with sales/commercial aspects. Alternatively, it’s an already very much established business, with lots of processes and management layers, but in those cases these processes and management layers are designed as a safety net against poor business decisions from developers.
- Software Engineers don’t understand the best way to make money - Bottom up means that everyone will optimize locally for their own turf instead of converging on a common goal/set of goals for the company (ie reaching a global optimum)
Why not? Isn't efficiency and profitability fundamentally an engineering problem? Design a product to be as profitable as possible, understanding which items to focus on, and which corners to cut?
IMO too much is lost in this translation step and you end up often with engineers not understanding why the product they're building actually needs to be the way it does, and then a product person chasing them in circles and telling them absolutely everything except what the business problem actually is.
The reasons disciplines like marketing and sales exist and also why processes like product discovery exist is that if we would leave product development to engineers, we’d get super efficient machines and software that are really elegant but don’t necessarily solve the problems customers have, are way too expensive to build and are not being sold.
Don’t take offense at the “mindless repetition” part though, please. I genuinely want feedback from somebody who says what you just said.
Yes, and this somewhat recent notion that corporations only exist to benefit their shareholders. Corporations exist in order to do the business that they’re in the business of doing, and their structure is such that it allows for the distribution of risk and the possibility of profit for investors. Ideally, people would make investment decisions based on whether the business was sound. Like, yeah, this business has tons of satisfied customers, is doing relatively efficient business and makes money doing it: I’ll invest because that company is a winner. Everything now, though, is entirely judged on growth and bottom lines that are easily manipulable quarter to quarter. You’re a successful corporation if number goes up. The financialization of literally everything erodes the real purposes the corporation exists. And the mindless repetition of the line that corporations exist simply to make profits for the benefit of shareholders is bullshit. How many times have we seen companies chasing those profits in such a way as to destroy the longer-term viability/success of their business? Yeah, they made profit for the shareholder in the short term. Hurray. And destroyed the business in the longer-term. That seems to me to be pretty anti-shareholder.
I would also add that if a company scales to such a size that this model wouldn't work, in my opinion the company is too large. I would expect this to work very well on a small team, if managed well. I'd expect it to scale okay for a while but to fail miserably at the scale of big tech. That's a feature in my opinion, I expect we'd be better off collectively without such massive corporations accruing so much power.
I'd also note that i don't think your concern is unique to the bottom up approach. With the usual top down approach, leadership at the top is likely very skilled in defining business goals and how to make money. They rarely are skilled at the day to day work that actually keeps the company running. I've personally worked at companies where having leaders define direction while so disconnected from the front lines led to a very poorly functioning company.
This has been my general experience with agile as practiced at three different outfits.
Agile per se isn't killing software innovation: training non-technical people who have no concept whatsoever of what's going on and then insisting they invent arbitrary funny money to express work size.
The ideal way to resist this appears to emerge naturally in most even vaguely experienced engineers: double your estimates.
I do remember conversations with him to the effect that Taylorism ab initio was as much ideological in aim as seeking efficiency, but (1) that’s obviously his view (though a considered one after studying the sources) and (2) I don’t have any citations I could give you to support that beyond vaguely recalled conversations after class.
I have yet to see a project management tool that even lets you write down uncertainty.
Estimated hours, in whole hour increments (i.e. 1 hour is the minimum allowed estimate). Usually you’d then multiply the engineering estimate by 3 to get something more realistic.
Uncertainty of the estimate, with a scale of 1 to 3, where 1 is “I’ve done this before and have a very good idea of how long it takes” and 3 is “I have no idea and making my best guess”
Impact to the project if it doesn’t get done in time on a scale of 1 to 3, where 1 is a small impact and 3 is high
Then the Exposure which is simply Uncertainty * Impact.
This method highlights the most critical areas so at least people can get an idea of when we’re entering into uncharted waters and to expect more possible delays.
An issue still unaddressed is that when you estimate 40 hours for something, management thinks “ok, great, it will be done in one week”, and then proceed to bury you in emails and meetings completely unrelated to the project.
And you are right, I don’t know anything about that code base, certainly not enough to know if estimates should be easy or not. But the fact that they aren’t is a sign of problems either way.
And I stand by my point that your boss’ question is reasonable, and the team should do some introspection to learn why such a fair question cannot be easily answered
To me, it is not a reasonable question because there are so many assumptions smuggled in with it.
Here's a theory on why (some form of) Agile is problematic: Subdividing work into smaller parts is typically beneficial. However, in computer programming, this approach often fails because even the smaller tasks require some creativity, and unexpected challenges are likely to arise.
The person who did the subdividing gains a lot of insight while breaking down the larger problem. However, when transferring a portion of the work to a developer, much of this knowledge is inherently lost. The developer must then devise a creative solution, and lacking the necessary information, may either come up with a suboptimal solution or need further communication with the original architect.
There is no clear-cut solution. Some might argue for more experienced developers who have all the necessary knowledge readily available in their heads. Others might advocate for better design diagrams and documentation to capture all the relevant information. Ultimately, it requires careful consideration, or luck, to strike the right balance. But the dogmas of Agile certainly aren't helping much.
I still think that the team layout in The Mythical Man month is one of the best for software projects.
> Others might advocate for better design diagrams and documentation to capture all the relevant information.
During the design phase group B made suggestions for the manner in which the extensions
should be accommodated and submitted them to group A for review. In several major cases
it turned out that the solutions suggested by group B were found by group A to make no
use of the facilities that were not only inherent in the structure of the existing
compiler but were discussed at length in its documentation, and to be based instead on
additions to that structure in the form of patches that effectively destroyed its power
and simplicity. [...] This is an example of how the full program text and additional
documentation is insufficient in conveying to even the highly motivated group B the
deeper insight into the design, that theory which is immediately present to the members
of group A. [...] A very important consequence of the Theory Building View is that
program revival, that is reestablishing the theory of a program merely from the
documentation, is strictly impossible. [0]
Do you not remember when it used to take minutes to boot your PC? Starting MS Word could easily take 30s. Unless your computer is broken it takes nowhere near that long now.
No, it never took that long if you took care of your PC, e.g. not have 50 things in your startup programs or a 99% full undefragged hard drive.
But yes, SSDs improved startup times massively, and were responsible for masking how bad software has gotten in the last 10 years.
You know, our torts and contracts common law is a powerful mechanism, but there’s always movement to limit people’s ability to make use of it (ranging from tort reform to various doctrines on warranties and so on).
It’s like they took 'mission briefings' and turned them into 'tell me why your sticky note isn't moved yet.' Collaboration is ....Daily micromanagement...
Last time I checked, the Agile Manifesto was drafted up by no less than 17 developers [1], the most prominent of them being Kent Beck, who's not directly famous for his US Military experience [2].
[1] https://en.wikipedia.org/wiki/Agile_software_development
At least Kent Beck had the integrity of calling Agile certifications: “dishonest”, “a pyramid scheme”, & “cancer”.
https://zhiminzhan.medium.com/agile-certifications-are-wrong...
And you know you can't spell Agile without reserving space for your Scrum Master... ;-)
Also selectively adding and removing characters of the Agile Manifest, to maximize or minimize their importance in the movement, as it is convenient for damage control purposes is not going to work out....
How to tell you’ve been in an industry for more than 20 years.
Spend time around excited young programmers, and you’ll find the magic is still there. It’s just different than it was 20 years ago. I remember the people with 20 years of experience back then telling me how awful everything was, but I was having way too much fun making things to give them much attention.
Value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Principles:
1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months).
4. Close, daily cooperation between business people and developers.
5. Projects are built around motivated individuals, who should be trusted.
6. Face-to-face conversation is the best form of communication (co-location).
7. Working software is the primary measure of progress.
8. Sustainable development, able to maintain a constant pace.
9. Continuous attention to technical excellence and good design.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. Best architectures, requirements, and designs emerge from self-organizing teams.
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.
https://en.m.wikipedia.org/wiki/Agile_software_development
For most of the critics, I would say "become more Agile" as a solution.
Not to mention the now capital-A Agile practices, courses, certifications(!!) and processes (!!?!?) which end up being exactly against the spirit of the original manifesto.
SCRUM isn't agile, it's SCRUM. Kanban isn't agile, it's Kanban. Doing something that has lots of process but that isn't waterfall isn't agile just because it isn't waterfall - it's a thing with lots of process.
Agile is about responding to the context of the team and the customer. You probably need a way to keep track of what needs to be done, and have regular updates about blockers and progress, but that's it.
The problem is if you ask people who have never been software engineers to manage a software engineering project, they're going to struggle to communicate, because they have no natural intuition of what the hell is going on. The project management industry is quite happy to serve these people by inventing big complex processes to keep them busy and sell them books, courses, certifications and conferences.
Most of big tech won't allow someone to manage an engineering team or project manage those projects without a good amount of hands-on engineering experience. The rest of industry needs to pick up on this.
People without that experience can learn. But they should adapt to software being what software is, not try and bring processes derived from those invented for other domains to software.
Agile done well is absolutely amazing, when its in the hands of teams who have all built software, understand their customer problem and the milestones they need to hit (yes, deadlines are unavoidable in any modern business environment, sorry), and each other.
Trust me, I remember when waterfall was the way. Waterfall is so bad, that even when you do 2-week long waterfall sprints (waves at SCRUM), it feels awful.
Go back to the Agile Manifesto [1]. It's all you need. Keep track of what was decided or discovered (bugs, features that are needed, and so on). If you have regular bottlenecks due to skill/knowledge imbalances, steal pairing from XP. Maybe explore Theory of Constraints but resist Kanban unless you understand exactly what it is doing and why. Have regular conversations as a group, and one-on-ones, not just between managers and reports, but between each other. Hold short but regular retros to understand systemic issues and then make sure the actions are actioned.
It's not that hard. It's just Agile.
If the bad managers are outliers, then fine. If the bad managers are the norm, then we need a way of working that fits the average manager, even if you call them "bad". Most people in most companies are necessarily going to be of average quality.
Judging from years of talking to devs and reading books and articles and comments on the net, what you call "bad managers" are not exceptions, but rather the norm.
> Agile done well is absolutely amazing
If your team is made up of very competent people, any methodology is likely to work great. But most teams are not. We need something that works reasonably well even when the managers and devs are just average.
Can you explain to me your thinking - which I might be implying and you might not actually think - as to how heavy processes like SCRUM and Kanban turn average teams into productive ones?
No. Not this please no. Where is that context where your team is constantly learning and discovering. ?
Please tell me what Software is that? A real time control system for a high speed train, airplane or space ship, where lives are at stake? A hospital or ER patient management system where a library bug can mean the patient get's a fatal dose of 250 ml of something instead of the life saving 2,5 ml?
Or a context where everyone is constantly "learning and discovering" the best color for the web page of your online shopping?
I prefer Software for stuff that matters....
Most software is used by customers with changing needs and competitive pulls. I've built software in the last 2 years that we would have taken a radically different approach to if LLMs were available, because they're great at summarising natural language. But they weren't. Imagine if we'd been building something for 2 years and never learned anything about changing technology or customer expectations - instead we shipped something fast, and then looked back after we learned about new things and made it better. That's how the World should work, and why software is not like building a bridge or a house or basically anything else in the history of engineering.
As to your specific exampleS: I have some detailed knowledge of hospital EHR systems, and they are so massively, hilariously broken in ways that modern software practices could easily help address. I suggest reading Accelerate [1] for data and examples of how agile applied to DevOps practice in particular means you can be more responsive and produce safer software, especially in that context.
I, like you, also prefer software for stuff that matters. I've been trained in formal methods, I've done embedded systems development, I've worked in medical/healthcare contexts. Your statement that what I've written above does not apply to those environments (including the use of formal verification methods), doesn't make sense to me.
[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...
Let's review the Agile Manifest from the perspective of delivering Software That Matters, that I define as Software where failures can cause significant loss of Lives, Money, or Reputation:
1. Early and Continuous Delivery
Speed over quality in critical software contexts invites catastrophic failures.
Instead just implement phased delivery schedules that prioritize comprehensive testing and stability over speed, ensuring system reliability.
2. Welcoming Late Changes
This flexibility often leads to scope creep and consequential delays, undermining system integrity.
Instead have a change control board to rigorously evaluate the implications of proposed changes, safeguarding project stability.
3. Frequent Software Releases
Regular release demands degrade software quality and exhaust development teams, detracting from critical system safety.
Instead base your release schedules on thorough testing and feature completion, ensuring each release enhances system robustness.
4. Daily Business-Developer Interaction
Frequent meetings disrupt productivity and can force development compromises, jeopardizing precise project requirements.
Instead opt for structured weekly updates and essential communication to maintain clarity and focus without sacrificing project integrity.
5. Trusting Motivated Individuals
Sole reliance on individual motivation without structured oversight introduces risks of inconsistent quality in high-stakes projects.
Instead clearly define roles and accountability metrics, aligning individual contributions directly with critical project outcomes.
6. Face-to-Face Communication
This traditional communication mode fails to accommodate remote participants or ensure accurate documentation of critical decisions.
Instead leverage advanced digital communication tools that enhance documentation, suitable for modern, distributed teams.
7. Working Software as Progress Measure
Focusing solely on functional completions neglects essential aspects like security, scalability, and user experience.
Instead expand progress indicators to include comprehensive evaluations of non-functional requirements, providing a holistic view of system health.
8. Sustainable Development Pace
The ideal of an unvarying pace is impractical under the variable pressures of high-stakes software development.
Instead adopt development rhythms to real-world project dynamics, accommodating natural workflow variations to prevent burnout and ensure quality.
9. Continuous Technical Excellence
An unrelenting pursuit of technical perfection can obstruct pragmatic and timely deliverables in critical scenarios.
Instead aim for pragmatically viable solutions that meet current needs with provisions for iterative enhancements as future requirements evolve.
10. Maximizing Work Not Done
Striving for minimalism can neglect essential complexities, endangering the whole system.
Instead prioritize a thorough approach that covers all necessary bases, balancing simplicity with comprehensive risk management.
11. Self-Organizing Teams
Teams without structured guidance can diverge from critical safety and performance standards.
Instead implement a framework that offers direction and support, ensuring teams adhere to best practices essential for system reliability.
12. Regular Reflection and Adjustment
Constant reassessment cycles can disrupt ongoing projects and dilute focus on strategic goals.
Instead space out reflective practices to better assess their impact and refine processes without compromising ongoing project stability.
Every study of continuous delivery suggests it improves quality by finding bugs earlier (because it has continuous integration - automated and rigorous testing to help identify unintended regressions - as a dependency), and reducing MTTR when undetected bugs do occur, because releasing fixes is quick and standardised. I'll refer you to the book in my comment above which demonstrates this with data collected from thousands of companies.
If you don't understand the reasons behind this, you're not going to understand why any of the other things lead to safer software, released earlier, and producing more value in the short, medium and long terms. So we should stop here.
I'd strongly encourage you to start by reading Accelerate and then come back and take another swing at it if you want, but given your current perspective - which sounds highly authoritarian, cynical, and divorced from data collected over a wide range of industry contexts - there's no point in us discussing this further.
The key distinction between waterfall and agile (or even Agile for that matter) is: do you change your product when your customer changes his mind?
If you agree to build x, then your customer wants y, what do you do at the margin?
Building stuff your client no longer wants is guaranteed not to matter.
But for most software, the customer keeps changing his mind and requesting new or different things. This includes hospitals. What's the impact of a bug have to do with it? I don't see the logic in "bugs are very bad -> this proves requirements don't change". Non sequitur.
If you have not experienced this, you're very lucky. But look around, in this thread and elswhere, and see how many people are claiming the "adapt to constant change" claim of Agile is pointless. You'll find very few.
Not that Agile is great. But this particular problem exists, and needs a solution. Software where requirements don't change is rare. It just is.
There may be some outliers where its not... but this is the cult like bullshit i'm seeing everywhere.
agile is the Ivermectin of business process. except it makes me WANT to inject bleach.
The meme that any critique of agile is not "true agile" should be first.
Great article. If only we could make the people holding the bags of money understand...
The smaller software is, the less it needs to be designed by committee.
I get that this isn't ALWAYS doable. And that when you're designing things for end users that are allergic to reading any documentation, in-line or otherwise, it's an uphill battle. But it's an ideal to strive toward where possible to avoid monstrosities like systemd and pulseaudio.
Some of the best code is the code written by one person.
Want to stay creative as a programmer, be a lone wolf... Do what you like and whenever you like, follow the creative spark...
Closing and locking thousands of Signal issues automatically and locking all conversations for "spring cleaning"...
... which feels exactly like something somebody oversubscribed to agile methods in the wrong way would do.
That's the magic phrase that really does the heavy lifting here.
Companies and leadership have to define what "good enough" is for them, and in almost every case that comes down to profit and prestige (or power if you take it a step further).
As you said, developers are costly. When a company just wants profit it usually makes sense to hire someone just skilled enough to make the product shippable.
I believe the flow state is why it's so easy to believe the idea of the 10x engineer, we've all experienced the feeling of flying through code without barriers, and we have all felt the below average days where you may be tired and just can't quite load all that complexity into your head to get any real work done. So we believe that there are people out there who are so skilled that they exist in this flow state all the time.
Yes, developers should work on themselves to rely less on a state of flow to be high performers, but even so there will always a benefit to being "in the zone".
We might not have killed software engineering as much as we are exhausting the list of things that very smart programmers will just figure out on their own.