RayFrankenstein

There was a lot of pressure in the Perl community to write things as succinctly as possible instead of as maintainably and understandably. That’s not realistic for use in a field with a lot of turnover and job hopping.

The guy is such a web zealot that he refuses to make the sensible engineering tradeoff that favors speed and offline capabilities over platform ubiquity. Most sane people would write a native app for this sort of thing if money was on the line.

So this person has never been a developer?

Traditional agile practices always sucked and were beyond problematic.

Maybe the speed of AI is just making it more apparent.

It's actually pretty amazing that you extracted the very worst, most very destructive practices and ideologies of agile and put it into a package that would allow toxic managements to maximally hurt their developers.

I maintain a compendium of developers' best negative comments about agile

https://github.com/rayfrankenstein/AITOW/blob/master/README....

Here's what I've learned from maintaing this compendium about why Lean manufacturing doesn't translate.

1. Japanese car companies companies were focused on long-term growth. Software companies, on the other hand, are extremely short-termist.

2. In Japanese car companies, anyone can stop the assembly line by yanking a cord and there is no dishonor in that. Try stopping working on a feature for half a day to refactor some code.

3. In Japanese manufacturing's golden age, workers had lifetime employment and there was a mutual concern by the company and workers for each other; a Japanese worker might be at a company for thirty years. In the software industry, the average tenure of a software company employee is, like, two years or something. And the environment is often very adversarial. You can't ahve

4. Japanese manufacturing focused very heavily on having very high quality vendors that make stuff that didn't require a lot of debugging. There was a heavy focus on part re-use in other designs; the same engines would be used in different generations of different models for years. The software equivalent of this would having a fully fleshed out, batteries included stack where little custom-invention would be required because the API's are just so damned good and comprehensive. How many times have you gotten a Not Invented Here or "that's too opinionated for my taste" approach from leads?

I maintain a compendium of 100's of the best developer comments about agile. Check it out and make your own conclusions.

https://github.com/rayfrankenstein/AITOW/blob/master/README....

I worked on a mobile app dev team that tried to Ui logic with the backend. With many of the justifications you mentioned being justifications for doing it that way. White labelling, A/B testing, avoiding redeploying, etc.

The result was a mess, with many of the possible concerns and drawbacks you’ve cited ending up manifesting themselves. It was an unmaintainable mess that tried to re-invent the web browser wheel badly, except using json instead of HTML. Maintaining the abstraction framework became a full-time job for people already just trying to barely deliver features on time.

And with the backend people already being busy and tied up with other stuff, the mobile app developers ended up having to become impromptu full stack developers, have to code PHP on backend to complete features in addition to the code they had to write in Objective-C/Java for their native app level portion of the feature.

The backend approach was so resented and hated by the mobile app devs that the business eventually got rid of it.

There are no agile trainings, only agile indoctrinations. Not that you can't have a bit of fun with them (at your own risk).

1. Ask if they've worked as a professional software developer? If not, enjoy them squirming as you subtle question why they're trying to train in things they don't understand.

2. If they do the penny flipping excerise, when it's your turn sweep all the pennys into a book, close the book, and flip it over and sweep the coins back out. You'll do the exercise 10 times faster than your coworkers and show them innovation is more important than agile.

3. When the agile training talks about splitting work down into small bits, as them what happens if there's a large chunk of work that can't be split down and has to be done in a large serial chunk. Think of as many examples as you can of this in the real world, and generally be a skeptical jerk when they tell you that any task can be broken down into tiny bits. If they're not technical, make sure you pick the most technical examples as possible, to further erode their credibility.

4. Bring a tub of single cell legos with you, and if they do the Lego excerise, ask them what to do if your team is given a tub of these and the other team (or your competition) is allowed to have broad-stretching legos.

Ideally you should use types, but if you have to use any because of some complicated situation where the compiler’s bitching, it’s no big deal. Anyone who tells you otherwise is a shamey OCD a-hole.

Quite a few experienced developers contributed their opinions on why found agile so problem. Check it out

https://github.com/rayfrankenstein/AITOW/blob/master/README....

Agile has fundamental structural problems which, combined with office politics which it can destructively amplify, make it an inevitable nightmare to work in.

Is AI being used to moderate comments now on HN? I ask because I don’t find this comment to be particularly moderation-worthy according to most modern standards of flamebait.

1. Options: give them the answer they’re looking for, even if its bullshit.

2. Stonewall and give them answers so confusing and incongruent they’ll eventually stop asking.

Here’s a compilation of hundreds of social media comments explaining why agile/scrum is so problematic

https://github.com/rayfrankenstein/AITOW/blob/master/README....

My problem is not whether I “like” management’s tradeoffs they force me as a developer to make; my problem is that managements typically don’t take accountability for choosing to make them.

And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.

Another from AITOW

“I regularly ask ‘Why are we running a marathon in a thousand sprints?’.

Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for ‘high velocity’. There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, https://news.ycombinator.com/item?id=20017854#20021832

Another from “Agile In Their Own Words”

“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832

From “Agile In Their Own Words”, https://github.com/rayfrankenstein/AITOW/blob/master/README....

“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.

I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.

I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.

I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...

Testimony from dozens upon dozens of developers that think that scrum is useless, toxic bullshit:

https://github.com/rayfrankenstein/AITOW/blob/master/README....

And here is a list of every rebuttal you could give them:

https://github.com/rayfrankenstein/AITOW/blob/master/README....

I fail to see the problem with that

These designs are usually added to show the executives of the company that a branch of the org chart and its Important People can "add value".

Conversely, the fastest way to turn around a failing company is to search through company e-mail archives, find everyone who has ever used the phrase "add value", and purge them from the company.

I've come to understand that the most important part of any software project is the Critical Twenty, the first 20% of the project's timeline where developers' need to do things like gain a deep understanding from reading documentation and lay down the infrastructure and architecture and foundation necessary to support features above.

On a 10 month project, this translates to reading docs and putting down foundation stuff, and delivering no features, for the first two months.

Attempts to abrogate The Critical Twenty are what causes the majority of problems later on in most software projects.

Borrowing from sci-fi, I call it the “Agile Expanded Universe”

What developers really think about Agile

https://github.com/rayfrankenstein/AITOW/blob/master/README....

(From “Agile In Their Own Words”)

“This agile witch hunt has to end, but it never will unless we start politely asking for the things we want.

i know for a fact that 90% of engineers dislike agile but many don't even imagine there can be an alternative, and most who do are terrified to say anything. Just look at the other answers to this question, most are from the very non engineers that have imposed this nonsense in the first place.”--Anonymous,

Which is exactly why Agile In Their Own Words exists.

Most everything else that’s been written about agile has been pure propaganda that you’re not allowed to question. There needs to be other viewpoints that are critical of agile.

One of the problems with agile is that it demands that every act of developer productivity be couched in a user story, a user-visible unit of change.

And the catch-22 is that only things that “deliver value” can be user stories, only things that are user stories can easily get into backlog, and only by doing things in the backlog can a developer prove they’ve done actual work that justifies them continuing to have a job at the company.

So to get around this restriction for something that isn’t a user-facing feature, devs have to be creative and you end up with these completely insane-sounding user stories like “As a user whose data is stored in the database, I would like the database schema to be overhauled so it can support a many-to-many relationship”.

Agile fails because it gives management fine-grained control over developers’ todo lists.

Agile’s term “customer” is actually very ambiguous about whether it’s trying to define the relationships between developers and employers or developers and users who buy the software.

It’s not a blog post but a sort of dataset, my research for an “Agile Considered Harmful” essay I’m writing. Which is why I’ve kept the citations.