6 ms·

> the programmers know but think it's not their problem I disagree. We know it's our problem. But we quite often don't get a, or too little, say in the decisio

> the programmers know but think it's not their problem I disagree. We know it's our problem. But we quite often don't get a, or too little, say in the decisions made to manage that problem properly. Because yes, it would be nice if we would "explore the whole problem space with stakeholders", and it would be great if we could "decide together". What ends up happening quite often however, is some "stakeholder" saying yes and thank you to whatever he-who-holds-the-money (or his career-advancement) says, with little to no regard whether the promised addon/feature/whatever is feasible and/or accomodated by the existing architecture. Suddenly, the space that needs to be explored may be galaxy-sized, or moebius-strip-shaped. What also tends to happen: The "exploration of the space" is outsourced to some consultant or architecture astronaut, who wont write a single line of code, and certainly won't have to deal with any unforseen difficulties. It would also be nice if, once the "exploration of the space" is done, devs get to implement based on what was explored. Which, given the aforementioned unforeseen properties of the problem domain, is laden with unforeseen change as it is. What tends to happen quite often is that in addition to that, requirements, and thus the problem domain change mid project...sometimes multiple times.

ebiester 3y ago
Congratulations, you just rediscovered the pains that led to agile. The key insight is that it is incredibly hard to capture a system that has the flexibility of handling every past, present, and future edge case while providing consistency for the happy path and preventing "bad" things from being done. XP and the proto-agilists said, as such, that it was futile to try and capture the whole problem because it turns into contract negotiation and pitting stakeholders against each other. Further, they found out that what stakeholders said and what they really needed ended up being not-quite-right and it wasn't exposed until people actually used the software. (Why? Because the stakeholders are representing a team, and sometimes they themselves are playing a game of telephone. And sometimes they describe a problem in a way that doesn't capture the real problem.) So, the idea was to have the business representative in the same room. The problem was that those representatives still had to do their jobs, so they ended up burning out and quitting. And that's how we got all of these product owners lying around - because we just punted the problem and went back to business analysts and gave them a slightly different mission. And that's why people talk about "dark agile." But I think it's easy to understand why the misalignment exists but very very hard to fix. For internal development, I think the real answer is that the development team and any analyists should be required to do the job as if they were an intern. If there are multiple stakeholders, they have to do all of the jobs, at least for a few weeks, and meet the people who they are building for. Then, they can at least understand the full complexity and why all of these contradictory requirements exist.
jfengel 3y ago
An awful lot of programmers seem come out of college thinking that their problem is to find the fastest algorithm that solves some well-defined spec. Requirements gathering gets short shrift, if it's mentioned at all. But really, it's the overwhelming majority of the job.
- nine_zeros 3y ago
  > Requirements gathering gets short shrift, if it's mentioned at all. But really, it's the overwhelming majority of the job. Tell that to managers - oh wait - hire on algorithms and performance review on BS such as commit count.
- usrbinbash 3y ago
  That's something that continues to baffle me whenever I interview people fresh from college. So many of them think their leetcode scores actually help them understand whats required in this job. It doesn't, and it always baffles them when I don't even give them a whiteboard problem to solve. I don't need people who have memorized all graph search algorithms, I don't need people who can code them up in 6 languages without looking anything up. People who can google competently (or use a textbooks index) can do the former just as well, and LLMs can do the latter. What I need are people who can take requirements, anticipate as much as humanly possible what else the client will do over time, and find a maintainable architecture that implements those and maybe is resilient when facing further changes down the road. And that is a HARD skill, that leetcode and most of what CS curricula will not teach.

ebiester 3y ago

Congratulations, you just rediscovered the pains that led to agile. The key insight is that it is incredibly hard to capture a system that has the flexibility of handling every past, present, and future edge case while providing consistency for the happy path and preventing "bad" things from being done. XP and the proto-agilists said, as such, that it was futile to try and capture the whole problem because it turns into contract negotiation and pitting stakeholders against each other. Further, they found out that what stakeholders said and what they really needed ended up being not-quite-right and it wasn't exposed until people actually used the software. (Why? Because the stakeholders are representing a team, and sometimes they themselves are playing a game of telephone. And sometimes they describe a problem in a way that doesn't capture the real problem.) So, the idea was to have the business representative in the same room. The problem was that those representatives still had to do their jobs, so they ended up burning out and quitting. And that's how we got all of these product owners lying around - because we just punted the problem and went back to business analysts and gave them a slightly different mission. And that's why people talk about "dark agile." But I think it's easy to understand why the misalignment exists but very very hard to fix. For internal development, I think the real answer is that the development team and any analyists should be required to do the job as if they were an intern. If there are multiple stakeholders, they have to do all of the jobs, at least for a few weeks, and meet the people who they are building for. Then, they can at least understand the full complexity and why all of these contradictory requirements exist.

jfengel 3y ago

An awful lot of programmers seem come out of college thinking that their problem is to find the fastest algorithm that solves some well-defined spec. Requirements gathering gets short shrift, if it's mentioned at all. But really, it's the overwhelming majority of the job.

nine_zeros 3y ago
> Requirements gathering gets short shrift, if it's mentioned at all. But really, it's the overwhelming majority of the job. Tell that to managers - oh wait - hire on algorithms and performance review on BS such as commit count.
usrbinbash 3y ago
That's something that continues to baffle me whenever I interview people fresh from college. So many of them think their leetcode scores actually help them understand whats required in this job. It doesn't, and it always baffles them when I don't even give them a whiteboard problem to solve. I don't need people who have memorized all graph search algorithms, I don't need people who can code them up in 6 languages without looking anything up. People who can google competently (or use a textbooks index) can do the former just as well, and LLMs can do the latter. What I need are people who can take requirements, anticipate as much as humanly possible what else the client will do over time, and find a maintainable architecture that implements those and maybe is resilient when facing further changes down the road. And that is a HARD skill, that leetcode and most of what CS curricula will not teach.