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.
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.
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 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.
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.
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.
“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
“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
“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...