6 ms·

Moxie Marlinspike: Agile is killing software innovation

84 points by signa11 2y ago

JKCalhoun 2y ago
Just let an engineer “own” a section of the code. That was the era of my own career when I felt that the software our team worked on was at its best.
- belter 2y ago
  Can't do it...It's not...Agile....
- OutOfHere 2y ago
  This is the simple and best way. It is also sustainable unlike a persistent state of Scrum. The engineer can take on features as the engineer sees fit. In fact it works this way for freelancers.
- therealdrag0 2y ago
  I don’t know about “own”. But you gotta let engineers lead projects that let them soak in a single code base enough to develop expertise. Letting every ticket go to a random dev, so it’s constant context switching is really silly.
smokel 2y ago
I think this touches on an interesting problem. I don't see a reason to praise security experts though. 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.
- skydhash 2y ago
  There are always interdependent units and I think the main issue is when we broke down those units into smaller tasks and then transfer the individual task to be implemented in isolation. There should always be someone that own that unit as a whole even if his job is only to answer architectural questions. A unit is assigned to one team (ad hoc or fixed) and a person (if the members count is greater than 3) is directing the implementation. I still think that the team layout in The Mythical Man month is one of the best for software projects.
  - ryandv 2y ago
    Right; "the surgeon" in Brooks' proposed team structure has the responsibility of maintaining the "theory" of the program as described by Peter Naur in 1985.
- ryandv 2y ago
  > lacking the necessary information, may either come up with a suboptimal solution or need further communication with the original architect. > 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] [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
  - 2y ago
deleted 2y ago
[deleted]
tritiy 2y ago
My take on this is that the developers are costly. A working hour of single developer costs a lot of money. The organization will always try to get the maximum out of that one hour. Spending more money so that the developers are 'better' is not efficient. They just need to be good enough.
- josephg 2y ago
  You’ve contradicted yourself. Which is it? Will companies try to get the maximum out of each hour of developer time, or do they just need to be good enough?
  - RunSet 2y ago
    They will pay for "good enough" while still attempting to extract the maximum.
  - mwcampbell 2y ago
    Perhaps what they meant is that companies will try to get the maximum in terms of development speed, while settling for good enough in terms of quality. And that's why we have so much crap software.
    - josephg 2y ago
      But they so consistently get terrible development speed and crap software. I’ve never been less productive than when I worked in a team that did big-A Agile.
- _heimdall 2y ago
  > They just need to be good enough. 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.
- 2y ago
deleted 2y ago
[deleted]
nvr219 2y ago
He's right.
baby 2y ago
Had to do it at a company and thank god we fought against daily standups, but the constant retrospectives, the useless breaking down of tasks into subtasks and ranking how long it’ll take just for the benefit of the non technical manager and nobody else… I admit it was so bad I never wanted to work for a company after that.
- belter 2y ago
  Both creators of the Agile movement come from US Military experience. You did not realize the Agile daily stand-ups are basically military morning formations in disguise?....Just a way to keep Developers in line? 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...
  - smokel 2y ago
    > Both creators of the Agile movement come from US Military experience. 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 https://en.wikipedia.org/wiki/Agile_software_development [2] https://en.wikipedia.org/wiki/Kent_Beck https://en.wikipedia.org/wiki/Kent_Beck
    - belter 2y ago
      Last time I checked...Ken Schwaber of infamous fame, of the pyramid scheme called Scrum and their Certifications pyramid... and also Jeff Sutherland of infamous Scrum fame, are considered two of the core forces behind the Agile Manifest. And are two of the 17 Developers behind the manifest and both ex-US Military. At least Kent Beck had the integrity of calling Agile certifications: “dishonest”, “a pyramid scheme”, & “cancer”. https://zhiminzhan.medium.com/agile-certifications-are-wrong-5a90a6f2b140 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....
j_m_b 2y ago
Software has gotten so bad over the past couple of decades. It's not as responsive as it was even in the 80-90s, yet we have orders of magnitude more powerful machines. Even simple website forms are often broken, due to everything from poor implementations to bit rot. It's perhaps just a coincidence that this time period has also been the rise of agile.
- belter 2y ago
  I can tell you for a fact that there was a period of 2 to 5 years in many parts of Europe—ranging from the Netherlands to Luxembourg, Belgium, Austria, France, and beyond—where you would not be hired as a contractor or consultant if you even dared to question some of the core tenets of Agile.
- skydhash 2y ago
  There are good software, but you have to look at the indy side or the FOSS side. It’s like how big companies conduct projects is not how it should be done.
- IshKebab 2y ago
  Nah you're misremembering. I'd say it's stayed about the same. I think it took a step improvement when SSDs became available so maybe it's slightly better than it used to be. 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.
  - antisthenes 2y ago
    > 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.
- dmvdoug 2y ago
_heimdall 2y ago
Agile, scrum, and OKRs have always bothered me (I know, how profound!) 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.
- stingraycharles 2y ago
  This only works when you’re able to hire the best of the best people, that are able to weigh both business and technical concerns against each other.
  - josephg 2y ago
    In my experience, most people I’ve worked with have a lot more capacity than they show at work. Who knows what your people are capable of if you empower your people to fix their own problems and treat them like adults? I’m sure they won’t all be able to step up to the plate, but it’s amazing how much of a difference the right corporate culture makes to the psychology of your employees. 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.
    - 2y ago
roenxi 2y ago
Seems unlikely. A more plausible countertheory is that software is a very young industry and we're leaving the era where there were a lot of easy unknowns. The industry as a whole has figured out social networks, got a pretty good bead on the economics of software (especially open source). Databases are well developed, networking is well developed, new basic algorithms seem to have stopped appearing with regularity. 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.
nh2 2y ago
You know what kills software progress and bug fixing? 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.
isoprophlex 2y ago
Can't spell "fragile" without "agile"! Great article. If only we could make the people holding the bags of money understand...
- sam_lowry_ 2y ago
  If only engineers had courage to call out stupid ideas and bad decisions...
josephg 2y ago
I agree with Moxie. But I’d go even further: I think the real problem stems from the modern corporate structure. 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.
- NhanH 2y ago
  > 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. 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)
  - lucianbr 2y ago
    > making money is not equal to building good product 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.
dangsux 2y ago
[dead]
gedy 2y ago
The same management and teams that turn agile into the hellscape many folks experience, would make waterfall or whatever the same mess. I've seen pre and post agile, it's all due to attitude, skills, and experience.
- hkt 2y ago
  Training, too. The people who load up on certifications then attempt to make reality conform to their understanding of the course content they learned rather than vice versa are the culprits here.
gyomu 2y ago
> the Signal founder stole the show with an opening chat laying out a case for reclaiming the "magic" of software development that's been lost after 20 years 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.
adonovan 2y ago
The industry took the good ideas of Agile (don't overplan, work in small steps, reassess regularly, oh and write tests and do code reviews) and absorbed them into normal software engineering. So now whenever someone describes themselves as an "agile" programmer it suggests a strict devotion to stand-up meetings, kanban boards, and various other cultic rituals. 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?
- kasey_junk 2y ago
  And Moxie is complaining about something that goes against the early tenets of agile as listed in the manifesto. 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.
- dmvdoug 2y ago
  Yes, interchangeable parts are a central component of mass production. And you have to remove the application of skilled labor to get to interchangeable parts, because that requires mechanization, not the intensively individualized input of skilled workers. 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.
delichon 2y ago
We had a backlog grooming meeting yesterday. The boss asked me to estimate a task that was a bug fix for some code I am completely unfamiliar with. If I had a dollar for every time that has happened I think I could buy a used jet ski in good condition. So I did the usual thing. I told her that I didn't know how long it would take. Then she said ok, then this is a task to estimate the size of the bug fix task, how long will that take. Rather than continue to struggle I said "I'm about to lie to you" and then pulled a (Fibonacci) number out of my butt. That was enough to make her happy and we moved on. I'll give it my best effort and there will never be any accountability for my stinky estimate. This has been my general experience with agile as practiced at three different outfits.
- hkt 2y ago
  I've been around a bit while contracting and have experienced about 15 organisations, a handful of which did not estimate work except the occasional natural tendency of one engineer to say to another "this seems a bit big". That group that doesn't insist on boilerplate agile ritual is way more effective. The trouble is that some manager or another higher up the chain will assume time and motion studies on tech can be done locally (or at all) demands a dashboard of what is essentially made up information about what kind of work the organisation is doing. 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.
  - dmvdoug 2y ago
    Taylorism was bullshit in its original form too. I had a history professor in graduate school whose PhD/book was about this. I can try to find it if you’re interested.
    - hkt 2y ago
      I'm incredibly interested as it happens. I had honestly never questioned it before and I'm fascinated.
snovv_crash 2y ago
The people who originally created the agile principles devised it for consulting agencies, not product development. A lot of the ideas are relevant still, but there's a bit of chaff to sort through to get at the wheat. 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.
davidy123 2y ago
My impression is larger or more synthetic orgs don't want devs to lead things anymore, they want a very top down development of vision -> product -> ux -> project management, and then the developers scurry around and do whatever it is they do using cloud something something, hopefully in as commodity a way as possible. The article clearly states the problems with this; devs can no longer understand the whole picture or make important top level suggestions, and the cloud dictates what can be done.
PaulRobinson 2y ago
This meme that "Agile is evil", needs to die. No, people, you've just had really bad managers who don't know how to manage software engineering teams. 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. [1] http://agilemanifesto.org http://agilemanifesto.org
- lucianbr 2y ago
  > This meme that "Agile is evil", needs to die. No, people, you've just had really bad managers 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.
deleted 2y ago
[deleted]
chewz 2y ago
Agile isn't killing inovation. Corporations are. Agile is just a tool to do so. Want to stay creative as a programmer, be a lone wolf... Do what you like and whenever you like, follow the creative spark...
2OEH8eoCRo0 2y ago
Where can I view their entire talk?
koonsolo 2y ago
The problem is not Agile, the problem is that people have no clue what Agile is. Here's a refresher: 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 https://en.m.wikipedia.org/wiki/Agile_software_development For most of the critics, I would say "become more Agile" as a solution.
deleted 2y ago
[deleted]
cykros 2y ago
The big issue to me seems to be this idea that software should do everything under the sun, instead of doing one thing, and doing it well. 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.
Chinwe888 2y ago
[dead]
sianyancey307 2y ago
[dead]
Chinwe888 2y ago
[dead]

84 points by signa11 2y ago

Just let an engineer “own” a section of the code. That was the era of my own career when I felt that the software our team worked on was at its best.

belter 2y ago
Can't do it...It's not...Agile....
OutOfHere 2y ago
This is the simple and best way. It is also sustainable unlike a persistent state of Scrum. The engineer can take on features as the engineer sees fit. In fact it works this way for freelancers.
therealdrag0 2y ago
I don’t know about “own”. But you gotta let engineers lead projects that let them soak in a single code base enough to develop expertise. Letting every ticket go to a random dev, so it’s constant context switching is really silly.

smokel 2y ago

I think this touches on an interesting problem. I don't see a reason to praise security experts though. 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.

skydhash 2y ago
There are always interdependent units and I think the main issue is when we broke down those units into smaller tasks and then transfer the individual task to be implemented in isolation. There should always be someone that own that unit as a whole even if his job is only to answer architectural questions. A unit is assigned to one team (ad hoc or fixed) and a person (if the members count is greater than 3) is directing the implementation. I still think that the team layout in The Mythical Man month is one of the best for software projects.
- ryandv 2y ago
  Right; "the surgeon" in Brooks' proposed team structure has the responsibility of maintaining the "theory" of the program as described by Peter Naur in 1985.
ryandv 2y ago
> lacking the necessary information, may either come up with a suboptimal solution or need further communication with the original architect. > 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] [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- 2y ago

deleted 2y ago

[deleted]

tritiy 2y ago

My take on this is that the developers are costly. A working hour of single developer costs a lot of money. The organization will always try to get the maximum out of that one hour. Spending more money so that the developers are 'better' is not efficient. They just need to be good enough.

josephg 2y ago
You’ve contradicted yourself. Which is it? Will companies try to get the maximum out of each hour of developer time, or do they just need to be good enough?
- RunSet 2y ago
  They will pay for "good enough" while still attempting to extract the maximum.
- mwcampbell 2y ago
  Perhaps what they meant is that companies will try to get the maximum in terms of development speed, while settling for good enough in terms of quality. And that's why we have so much crap software.
  - josephg 2y ago
    But they so consistently get terrible development speed and crap software. I’ve never been less productive than when I worked in a team that did big-A Agile.
_heimdall 2y ago
> They just need to be good enough. 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.
2y ago

deleted 2y ago

[deleted]

nvr219 2y ago

He's right.

baby 2y ago

Had to do it at a company and thank god we fought against daily standups, but the constant retrospectives, the useless breaking down of tasks into subtasks and ranking how long it’ll take just for the benefit of the non technical manager and nobody else… I admit it was so bad I never wanted to work for a company after that.

belter 2y ago
Both creators of the Agile movement come from US Military experience. You did not realize the Agile daily stand-ups are basically military morning formations in disguise?....Just a way to keep Developers in line? 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...
- smokel 2y ago
  > Both creators of the Agile movement come from US Military experience. 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 https://en.wikipedia.org/wiki/Agile_software_development [2] https://en.wikipedia.org/wiki/Kent_Beck https://en.wikipedia.org/wiki/Kent_Beck
  - belter 2y ago
    Last time I checked...Ken Schwaber of infamous fame, of the pyramid scheme called Scrum and their Certifications pyramid... and also Jeff Sutherland of infamous Scrum fame, are considered two of the core forces behind the Agile Manifest. And are two of the 17 Developers behind the manifest and both ex-US Military. At least Kent Beck had the integrity of calling Agile certifications: “dishonest”, “a pyramid scheme”, & “cancer”. https://zhiminzhan.medium.com/agile-certifications-are-wrong-5a90a6f2b140 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....

j_m_b 2y ago

Software has gotten so bad over the past couple of decades. It's not as responsive as it was even in the 80-90s, yet we have orders of magnitude more powerful machines. Even simple website forms are often broken, due to everything from poor implementations to bit rot. It's perhaps just a coincidence that this time period has also been the rise of agile.

belter 2y ago
I can tell you for a fact that there was a period of 2 to 5 years in many parts of Europe—ranging from the Netherlands to Luxembourg, Belgium, Austria, France, and beyond—where you would not be hired as a contractor or consultant if you even dared to question some of the core tenets of Agile.
skydhash 2y ago
There are good software, but you have to look at the indy side or the FOSS side. It’s like how big companies conduct projects is not how it should be done.
IshKebab 2y ago
Nah you're misremembering. I'd say it's stayed about the same. I think it took a step improvement when SSDs became available so maybe it's slightly better than it used to be. 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.
- antisthenes 2y ago
  > 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.
dmvdoug 2y ago

_heimdall 2y ago

Agile, scrum, and OKRs have always bothered me (I know, how profound!) 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.

stingraycharles 2y ago
This only works when you’re able to hire the best of the best people, that are able to weigh both business and technical concerns against each other.
- josephg 2y ago
  In my experience, most people I’ve worked with have a lot more capacity than they show at work. Who knows what your people are capable of if you empower your people to fix their own problems and treat them like adults? I’m sure they won’t all be able to step up to the plate, but it’s amazing how much of a difference the right corporate culture makes to the psychology of your employees. 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.
  - 2y ago

roenxi 2y ago

Seems unlikely. A more plausible countertheory is that software is a very young industry and we're leaving the era where there were a lot of easy unknowns. The industry as a whole has figured out social networks, got a pretty good bead on the economics of software (especially open source). Databases are well developed, networking is well developed, new basic algorithms seem to have stopped appearing with regularity. 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.

nh2 2y ago

You know what kills software progress and bug fixing? 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.

isoprophlex 2y ago

Can't spell "fragile" without "agile"! Great article. If only we could make the people holding the bags of money understand...

sam_lowry_ 2y ago
If only engineers had courage to call out stupid ideas and bad decisions...

josephg 2y ago

I agree with Moxie. But I’d go even further: I think the real problem stems from the modern corporate structure. 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.

NhanH 2y ago
> 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. 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)
- lucianbr 2y ago
  > making money is not equal to building good product 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.

dangsux 2y ago

[dead]

gedy 2y ago

The same management and teams that turn agile into the hellscape many folks experience, would make waterfall or whatever the same mess. I've seen pre and post agile, it's all due to attitude, skills, and experience.

hkt 2y ago
Training, too. The people who load up on certifications then attempt to make reality conform to their understanding of the course content they learned rather than vice versa are the culprits here.

gyomu 2y ago

> the Signal founder stole the show with an opening chat laying out a case for reclaiming the "magic" of software development that's been lost after 20 years 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.

adonovan 2y ago

The industry took the good ideas of Agile (don't overplan, work in small steps, reassess regularly, oh and write tests and do code reviews) and absorbed them into normal software engineering. So now whenever someone describes themselves as an "agile" programmer it suggests a strict devotion to stand-up meetings, kanban boards, and various other cultic rituals. 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?

kasey_junk 2y ago
And Moxie is complaining about something that goes against the early tenets of agile as listed in the manifesto. 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.
dmvdoug 2y ago
Yes, interchangeable parts are a central component of mass production. And you have to remove the application of skilled labor to get to interchangeable parts, because that requires mechanization, not the intensively individualized input of skilled workers. 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.

delichon 2y ago

We had a backlog grooming meeting yesterday. The boss asked me to estimate a task that was a bug fix for some code I am completely unfamiliar with. If I had a dollar for every time that has happened I think I could buy a used jet ski in good condition. So I did the usual thing. I told her that I didn't know how long it would take. Then she said ok, then this is a task to estimate the size of the bug fix task, how long will that take. Rather than continue to struggle I said "I'm about to lie to you" and then pulled a (Fibonacci) number out of my butt. That was enough to make her happy and we moved on. I'll give it my best effort and there will never be any accountability for my stinky estimate. This has been my general experience with agile as practiced at three different outfits.

hkt 2y ago
I've been around a bit while contracting and have experienced about 15 organisations, a handful of which did not estimate work except the occasional natural tendency of one engineer to say to another "this seems a bit big". That group that doesn't insist on boilerplate agile ritual is way more effective. The trouble is that some manager or another higher up the chain will assume time and motion studies on tech can be done locally (or at all) demands a dashboard of what is essentially made up information about what kind of work the organisation is doing. 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.
- dmvdoug 2y ago
  Taylorism was bullshit in its original form too. I had a history professor in graduate school whose PhD/book was about this. I can try to find it if you’re interested.
  - hkt 2y ago
    I'm incredibly interested as it happens. I had honestly never questioned it before and I'm fascinated.

snovv_crash 2y ago

The people who originally created the agile principles devised it for consulting agencies, not product development. A lot of the ideas are relevant still, but there's a bit of chaff to sort through to get at the wheat. 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.

davidy123 2y ago

My impression is larger or more synthetic orgs don't want devs to lead things anymore, they want a very top down development of vision -> product -> ux -> project management, and then the developers scurry around and do whatever it is they do using cloud something something, hopefully in as commodity a way as possible. The article clearly states the problems with this; devs can no longer understand the whole picture or make important top level suggestions, and the cloud dictates what can be done.

PaulRobinson 2y ago

This meme that "Agile is evil", needs to die. No, people, you've just had really bad managers who don't know how to manage software engineering teams. 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. [1] http://agilemanifesto.org http://agilemanifesto.org

lucianbr 2y ago
> This meme that "Agile is evil", needs to die. No, people, you've just had really bad managers 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.

deleted 2y ago

[deleted]

chewz 2y ago

Agile isn't killing inovation. Corporations are. Agile is just a tool to do so. Want to stay creative as a programmer, be a lone wolf... Do what you like and whenever you like, follow the creative spark...

2OEH8eoCRo0 2y ago

Where can I view their entire talk?

koonsolo 2y ago

The problem is not Agile, the problem is that people have no clue what Agile is. Here's a refresher: 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 https://en.m.wikipedia.org/wiki/Agile_software_development For most of the critics, I would say "become more Agile" as a solution.

deleted 2y ago

[deleted]

cykros 2y ago

The big issue to me seems to be this idea that software should do everything under the sun, instead of doing one thing, and doing it well. 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.

Chinwe888 2y ago

[dead]

sianyancey307 2y ago

[dead]

Chinwe888 2y ago

[dead]