2 ms·

So... how do you know what those people want? How do you know what you're building in 3 weeks isn't something totally different from what the users now want?

So... how do you know what those people want? How do you know what you're building in 3 weeks isn't something totally different from what the users now want? The answer is that you, alone, don't. By spending more than a small amount of time building out the simplest possible version of what the customer wants, you get their feedback along the way. It's generally not true that you need many weeks, or even a full week, to build something you can show a user. Usually you're not being creative enough to figure out what to show your customer if you can't think of a way to provide value in a few days. There are rare exceptions, but in the vast majority of cases you can build something for the user quickly, even when you initially think you can't. This isn't even my opinion, it's the observed practice of a whole generation of developers. Read "The Art of Agile Development" if you want to know more, it's extremely helpful if you're trying to understand how to achieve the delivery I'm talking about.

jlokier 5y ago
Ah, I left that out by mistake when editing. You know what they want because they told you, up front, when they hired you. In the example, let's say the customer has said they would find it really useful if the GPU could calculate twice as much on the same power, but they don't know how that could be done. Perhaps it's in a self-driving car and these are hard specifications. And then they crank up some agile "creative" process, encouraging devs including you to work on whatever areas of the system make sense to improve it. As long as you ship code PRs daily and a little report. You talk to them about your idea, and they don't understand it. It's not convincing to them, but it is to you - and you're the expert on this. You are hired for your expertise and the customer doesn't have anyone else with it in the GPU algorithm design area. Your team peers are either busy or don't understand the area well enough. They can't recognise what will solve their stated problem, and you can't convince anyone that your method will work until you have reached the "proof" stage after 3 weeks of not producing any PRs, which is against what the customer or your managers incorrectly believe a competent developer would invariably produce almost daily. I'm not saying you should do that as a dev. I'm saying it's an example of what "proof" refers to, while being something that gives a customer what they said they need, and is not a dev's pet project. Addressing the incorrect assumptions implied in "Proof to whom? Shouldn't you be developing things your customers need, not some pet project you enjoy working on for its own sake?" There is no pet project, and you don't actually enjoy workng on it all that much. You're just trying to solve the customer's stated problem in an environment where they openly say what they'd really want and have set up a process which prevents it - a very common combination.
- TameAntelope 5y ago
  > You know what they want because they told you, up front, when they hired you. This is, very often, a fatal mistake, and what they hired you to do is not what they need, nor what they want you to do in three weeks, let alone three days.
  - jlokier 5y ago
    Sure but now that's just arguing in circles. Whatever I'd say about what they've shown they need in a simplified example for discussion, you can find a matching argument that it's not what they really need, but that argument doesn't address anything. It's a "no true scotsman". Assume for the sake of the point, that you are a competent and experienced dev, and somehow you have correctly ascertained something that the customer needs, most likely by talking with them. The point of this discussion is to ask, are there circumstances where someone needs to "work on one's own" for a while before others will recognise a solution is in progress to the clear need of their customer. And are there circumstances where not doing that will result in the solution being blocked, without any other useful replacement taking its place. There are countless anecdotes, and in all walks of life not just software development, pointing to the answers to both of those questions being a strong yes.
    - TameAntelope 5y ago
      That's your mistake; it's not a matter of competency and experience. You are not a solo venture, you are a member of a team, and part of that team needs to be a customer representative who can tell you, in real time, what the customer wants. There is no room for a hero engineer in modern software development. That's not how it works anymore, and it may never have worked that way. Your countless anecdotes of this working stack only a fraction as high as the countless anecdotes of what you're describing completely failing. This battle was fought in the 00s and won in the early 2010s. Agile produces results, waterfall generally does not.

jlokier 5y ago

Ah, I left that out by mistake when editing. You know what they want because they told you, up front, when they hired you. In the example, let's say the customer has said they would find it really useful if the GPU could calculate twice as much on the same power, but they don't know how that could be done. Perhaps it's in a self-driving car and these are hard specifications. And then they crank up some agile "creative" process, encouraging devs including you to work on whatever areas of the system make sense to improve it. As long as you ship code PRs daily and a little report. You talk to them about your idea, and they don't understand it. It's not convincing to them, but it is to you - and you're the expert on this. You are hired for your expertise and the customer doesn't have anyone else with it in the GPU algorithm design area. Your team peers are either busy or don't understand the area well enough. They can't recognise what will solve their stated problem, and you can't convince anyone that your method will work until you have reached the "proof" stage after 3 weeks of not producing any PRs, which is against what the customer or your managers incorrectly believe a competent developer would invariably produce almost daily. I'm not saying you should do that as a dev. I'm saying it's an example of what "proof" refers to, while being something that gives a customer what they said they need, and is not a dev's pet project. Addressing the incorrect assumptions implied in "Proof to whom? Shouldn't you be developing things your customers need, not some pet project you enjoy working on for its own sake?" There is no pet project, and you don't actually enjoy workng on it all that much. You're just trying to solve the customer's stated problem in an environment where they openly say what they'd really want and have set up a process which prevents it - a very common combination.

TameAntelope 5y ago
> You know what they want because they told you, up front, when they hired you. This is, very often, a fatal mistake, and what they hired you to do is not what they need, nor what they want you to do in three weeks, let alone three days.
- jlokier 5y ago
  Sure but now that's just arguing in circles. Whatever I'd say about what they've shown they need in a simplified example for discussion, you can find a matching argument that it's not what they really need, but that argument doesn't address anything. It's a "no true scotsman". Assume for the sake of the point, that you are a competent and experienced dev, and somehow you have correctly ascertained something that the customer needs, most likely by talking with them. The point of this discussion is to ask, are there circumstances where someone needs to "work on one's own" for a while before others will recognise a solution is in progress to the clear need of their customer. And are there circumstances where not doing that will result in the solution being blocked, without any other useful replacement taking its place. There are countless anecdotes, and in all walks of life not just software development, pointing to the answers to both of those questions being a strong yes.
  - TameAntelope 5y ago
    That's your mistake; it's not a matter of competency and experience. You are not a solo venture, you are a member of a team, and part of that team needs to be a customer representative who can tell you, in real time, what the customer wants. There is no room for a hero engineer in modern software development. That's not how it works anymore, and it may never have worked that way. Your countless anecdotes of this working stack only a fraction as high as the countless anecdotes of what you're describing completely failing. This battle was fought in the 00s and won in the early 2010s. Agile produces results, waterfall generally does not.