6 ms·

Weird title (one of these "true but wrong" things humans keep doing when they reason by analogy), but the post itself meshes with things I've been saying for a

Weird title (one of these "true but wrong" things humans keep doing when they reason by analogy), but the post itself meshes with things I've been saying for a few years in order to explain the otherwise inexplicably awful and continually worsening quality of software coming out of companies with effectively infinite resources. I think there's an additional aspect, though: insufficient supply of "people who care" coupled with compensation levels attracting too many people who don't. That maps better to the weird title, I suppose.

pavel_lishin 3y ago
> I think there's an additional aspect, though: insufficient supply of "people who care" coupled with compensation levels attracting too many people who don't. That maps better to the weird title, I suppose. You can care as much as you want, but if the people responsible for making the final decisions and cutting your paycheck don't care, your ability to write good software in that place is limited.
- nsxwolf 3y ago
  I have 4 tickets in this 2 week sprint. I lose a couple of productive days for scrum ceremonies and meetings. The last 2 or 3 days must be spent scrambling for code reviews and QA sign off. With the time that’s left I can make the software as good as I want.
  - munk-a 3y ago
    That's a terrible bastardization of agile. Agile and related practices aren't about delivering increased volume of work but just about making the team more responsive to changes. If you feel like you're always rushing to finish a sprint either your manager is pushing on the gas to squeeze past a deadline (a good sign of bad management) or you're in over your head and not performing at the level expected of you. In either case a manager should see this and work out a solution that lowers your workload. Down your road lies early burnout.
    - argiopetech 3y ago
      In other words, Scrum as practiced.
    - agentultra 3y ago
      "Agile," as advanced by management and coaches peddling Scrum and various "methodologies," is exactly like this in practice. It's micromanagement in disguise. You can argue that's, "not true Agile," but then... what is? The process being forced upon developers the world over or the ideal version you have in mind? I agree, as described, it generally leads folks to burnout. And anecdotally it seems most organizations are fine with that.
      - Arch-TK 3y ago
        On the one hand, yes, at this point "that's not true Agile" is starting to sound like a no true Scotsman fallacy. On the other hand, the way the term "agile" is used now really has no relation to anything in the agile manifesto. And this is in part due to ignorance (people adopting agile trusting that their "scrum certified" trainers know what agile is instead of just ... reading the short manifesto), in part due to how (intentionally) vague agile is, and in part due to complacency of the people who _do_ know what agile is not pushing back more against the idiocy. I don't think you can blame people who happen to have actually some clue as to what agile was supposed to be repeatedly complain that the crap which most organisations implement and call "agile" has nothing to do with agile. I like terrible analogies so here is one: It's akin to finding a paint bucket in the building supply store marked "red paint" and finding it filled with blue paint, and then when you go to the store to complain, they say: "but this _is_ red paint, you will find the same colour paint in these buckets in _every_ store". Then when you do a bit of research you realise that the only reason this happened is because people who really liked to paint walls blue heard about "the red paint craze" and started calling blue pain red to avoid having to change the colour of their walls. Why should we stand for this utter nonsense?
        agentultra 3y ago
        When a group of people pick a manifesto and are empowered to work towards improving their own working conditions, it's great. My comment has the flavour of a, "no true scotsman," situation but it's not necessarily, in my view, a matter of calling a spade a spade. The problem is that the spirit of the manifesto is a socialist one which runs counter to how capital runs businesses. The manifesto says "we," meaning the developers doing the work, should prefer customer collaboration over negotiating contracts. However most developers in most companies do not have the power to enforce this preference. The executives, founders, and managers sign the contracts. The developers are hired to write the software. There is no negotiation: your team doesn't meet their deadlines people will start getting fired or the business will go under. "Business people and developers must work together daily," they sure do. Every stand up, every morning, to tell the manager/lead what you did yesterday, what you got stuck on, what you're going to do today. "But that's not how it should be," well... again, what should it be? The manifesto isn't prescriptive about this. Agile-as-practiced is what we observe teams and companies doing out there. This is often how it's done. Individuals and interactions over processes and tools? What part of agile-as-practiced isn't about processes and tools? Capitalists love processes and tools ever since they brought their own clocks and bells into their factories and started docking people's wages when they didn't show up for work on time. Planning poker, retrospective meetings, kanban boards... all processes and tools. No businesses I've heard about or worked at have enabled developers to self-organize. This, again, would be anathema to how capitalists expect to run businesses. The other problem with the manifesto is that it's starting to show it's age. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," is a good way to ensure that your later maintainers have no idea how the software works anymore... and hasn't been true for decades: most of Linux and much OSS is developed by remote teams who've never met face to face. Writing is generally considered the best way to pass on information and it has been quite effective for a good portion of human civilization.
  - nradov 3y ago
    If you're scrambling at the end of an iteration to complete quality control tasks in order to accept user stories then you need to shift those left. Split the user stories into smaller chunks (as long as they still deliver value), have multiple team members work together on a single story to complete all the tasks (swarming), and write the automated test scripts in parallel with coding or even before (TDD). People sometimes try to tell me that this approach is impractical or won't work, and yet when I led Scrum teams and forced them to do it that way it produced good results and the team members were happier.
- bluGill 3y ago
  There are many dimensions of good. On a large project I have to assume someone else is doing good useful work in order to get my own work done. Thus if I'm not assigned some issue I assume someone was it will take care of it. I might write up a bug report, but that is as far as it goes: I don't prioritize them or track them. Things do fall through the cracks all the time. However in the end the software I'm writing is still good, it just that I'm sitting in my level and not jumping around.
- liquidpele 3y ago
  I think for people that care the biggest obstacles are when a company makes it very clear that you’re just wasting your time by caring. I had a previous company where I worked my butt off on a product for a year and got a bad review. The next year I basically slacked off and didn’t care anymore and got a good review that year (my theory is I socialized and went to meetings more, which got me “seen” lol). After that I found a new job.
Titiriti59nj 3y ago
[flagged]
- SteveDR 3y ago
  What?
yannis7 3y ago
your last sentence I think puts the 2nd pillar into the problem, which is not only technological (i.e. the abstraction problem mentioned in the original article) but also cultural
BoorishBears 3y ago
I find it's the exact opposite in FAANG: hiring people who care too much, but in directions not aligned with delivering value. If you hire the best in a narrow sense, you get people who find problems where others wouldn't. That's fine in theory but it becomes downright crippling if these people don't understand where their output falls in terms of the final value delivered to customers. You end up with organizations where precious little ships, and it's usually a crappy product because every team was convinced their little nugget needed to be perfect, and eventually market forces forced them to shove all their half-polished nuggets into a ball of filth. Normally managers are supposed to be a counter for that, but at engineering driven orgs they just get sucked into the games too.
titzer 3y ago
It's incredible to me how often YouTube is broken on Safari. Like, broken to the point where clicking on a video just doesn't work. Two trillion dollar companies cannot make clicking work. Don't get me started on the constant UI redesigns. They're just rearranging the deck chairs endlessly now.

pavel_lishin 3y ago

> I think there's an additional aspect, though: insufficient supply of "people who care" coupled with compensation levels attracting too many people who don't. That maps better to the weird title, I suppose. You can care as much as you want, but if the people responsible for making the final decisions and cutting your paycheck don't care, your ability to write good software in that place is limited.

nsxwolf 3y ago
I have 4 tickets in this 2 week sprint. I lose a couple of productive days for scrum ceremonies and meetings. The last 2 or 3 days must be spent scrambling for code reviews and QA sign off. With the time that’s left I can make the software as good as I want.
- munk-a 3y ago
  That's a terrible bastardization of agile. Agile and related practices aren't about delivering increased volume of work but just about making the team more responsive to changes. If you feel like you're always rushing to finish a sprint either your manager is pushing on the gas to squeeze past a deadline (a good sign of bad management) or you're in over your head and not performing at the level expected of you. In either case a manager should see this and work out a solution that lowers your workload. Down your road lies early burnout.
  - argiopetech 3y ago
    In other words, Scrum as practiced.
  - agentultra 3y ago
    "Agile," as advanced by management and coaches peddling Scrum and various "methodologies," is exactly like this in practice. It's micromanagement in disguise. You can argue that's, "not true Agile," but then... what is? The process being forced upon developers the world over or the ideal version you have in mind? I agree, as described, it generally leads folks to burnout. And anecdotally it seems most organizations are fine with that.
    - Arch-TK 3y ago
      On the one hand, yes, at this point "that's not true Agile" is starting to sound like a no true Scotsman fallacy. On the other hand, the way the term "agile" is used now really has no relation to anything in the agile manifesto. And this is in part due to ignorance (people adopting agile trusting that their "scrum certified" trainers know what agile is instead of just ... reading the short manifesto), in part due to how (intentionally) vague agile is, and in part due to complacency of the people who _do_ know what agile is not pushing back more against the idiocy. I don't think you can blame people who happen to have actually some clue as to what agile was supposed to be repeatedly complain that the crap which most organisations implement and call "agile" has nothing to do with agile. I like terrible analogies so here is one: It's akin to finding a paint bucket in the building supply store marked "red paint" and finding it filled with blue paint, and then when you go to the store to complain, they say: "but this _is_ red paint, you will find the same colour paint in these buckets in _every_ store". Then when you do a bit of research you realise that the only reason this happened is because people who really liked to paint walls blue heard about "the red paint craze" and started calling blue pain red to avoid having to change the colour of their walls. Why should we stand for this utter nonsense?
      - agentultra 3y ago
        When a group of people pick a manifesto and are empowered to work towards improving their own working conditions, it's great. My comment has the flavour of a, "no true scotsman," situation but it's not necessarily, in my view, a matter of calling a spade a spade. The problem is that the spirit of the manifesto is a socialist one which runs counter to how capital runs businesses. The manifesto says "we," meaning the developers doing the work, should prefer customer collaboration over negotiating contracts. However most developers in most companies do not have the power to enforce this preference. The executives, founders, and managers sign the contracts. The developers are hired to write the software. There is no negotiation: your team doesn't meet their deadlines people will start getting fired or the business will go under. "Business people and developers must work together daily," they sure do. Every stand up, every morning, to tell the manager/lead what you did yesterday, what you got stuck on, what you're going to do today. "But that's not how it should be," well... again, what should it be? The manifesto isn't prescriptive about this. Agile-as-practiced is what we observe teams and companies doing out there. This is often how it's done. Individuals and interactions over processes and tools? What part of agile-as-practiced isn't about processes and tools? Capitalists love processes and tools ever since they brought their own clocks and bells into their factories and started docking people's wages when they didn't show up for work on time. Planning poker, retrospective meetings, kanban boards... all processes and tools. No businesses I've heard about or worked at have enabled developers to self-organize. This, again, would be anathema to how capitalists expect to run businesses. The other problem with the manifesto is that it's starting to show it's age. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," is a good way to ensure that your later maintainers have no idea how the software works anymore... and hasn't been true for decades: most of Linux and much OSS is developed by remote teams who've never met face to face. Writing is generally considered the best way to pass on information and it has been quite effective for a good portion of human civilization.
- nradov 3y ago
  If you're scrambling at the end of an iteration to complete quality control tasks in order to accept user stories then you need to shift those left. Split the user stories into smaller chunks (as long as they still deliver value), have multiple team members work together on a single story to complete all the tasks (swarming), and write the automated test scripts in parallel with coding or even before (TDD). People sometimes try to tell me that this approach is impractical or won't work, and yet when I led Scrum teams and forced them to do it that way it produced good results and the team members were happier.
bluGill 3y ago
There are many dimensions of good. On a large project I have to assume someone else is doing good useful work in order to get my own work done. Thus if I'm not assigned some issue I assume someone was it will take care of it. I might write up a bug report, but that is as far as it goes: I don't prioritize them or track them. Things do fall through the cracks all the time. However in the end the software I'm writing is still good, it just that I'm sitting in my level and not jumping around.
liquidpele 3y ago
I think for people that care the biggest obstacles are when a company makes it very clear that you’re just wasting your time by caring. I had a previous company where I worked my butt off on a product for a year and got a bad review. The next year I basically slacked off and didn’t care anymore and got a good review that year (my theory is I socialized and went to meetings more, which got me “seen” lol). After that I found a new job.

Titiriti59nj 3y ago

[flagged]

SteveDR 3y ago
What?

yannis7 3y ago

your last sentence I think puts the 2nd pillar into the problem, which is not only technological (i.e. the abstraction problem mentioned in the original article) but also cultural

BoorishBears 3y ago

I find it's the exact opposite in FAANG: hiring people who care too much, but in directions not aligned with delivering value. If you hire the best in a narrow sense, you get people who find problems where others wouldn't. That's fine in theory but it becomes downright crippling if these people don't understand where their output falls in terms of the final value delivered to customers. You end up with organizations where precious little ships, and it's usually a crappy product because every team was convinced their little nugget needed to be perfect, and eventually market forces forced them to shove all their half-polished nuggets into a ball of filth. Normally managers are supposed to be a counter for that, but at engineering driven orgs they just get sucked into the games too.

titzer 3y ago

It's incredible to me how often YouTube is broken on Safari. Like, broken to the point where clicking on a video just doesn't work. Two trillion dollar companies cannot make clicking work. Don't get me started on the constant UI redesigns. They're just rearranging the deck chairs endlessly now.