4 ms·

His main point is that you should only start work once 100% of the requirements are clear. And you should get them clear by asking people, several of them. But

His main point is that you should only start work once 100% of the requirements are clear. And you should get them clear by asking people, several of them. But in my experience, it's often my job as a developer to decide on the last so many percent of the requirements, and asking other people doesn't help much because they all have their own work to do. And many of the things left not completely specified are often not that crucial, and can be changed later, so this is how it should be.

quickthrower2 5y ago
That’s the judgement call to make and sometimes I don’t ask but assume when (i) it’s easy to change later, in other words a 2 way door (ii) asking will cause meetings, scheduling challenges (need to get everyone in the room!) and delay work and (iii) the people I’m asking might bike shed it taking up lots of their time and mine. It’s the developers discretionary power! Perhaps the colour of the capacitor inside the iPhone … you don’t need to run past Jobs (back in the day…)
IshKebab 5y ago
Yes, people who say you should never assume anything just don't realise that they assume things all the time. They have to or they would never get anything done. Assumptions go wrong sometimes, but they go right and save so much time so often that you can't just throw them all out. The real advice is "learn when to question assumptions" but that just takes experience and you can't write blog posts about it.
Sammi 5y ago
Yeah I kinda balked at the "figure out 100% of the requirement up front" statement. That's usually how I define waterfall development. I like to go fast and make a test build to show someone else and get feedback. Cause I know one person can never see the whole picture. Code is a conversation. This is the essence of Agile (not the Agile that paid management consultants teach).
- datavirtue 5y ago
  But we're working stories with points that are mapped to days and all the epic deliverables are planned according to the story estimates and this epic HAS to be done before the next epic and those epics both must be done by X date. Now picture you are reworking almost an entire process or part of the system that has already been delivered (management jumped up and down congratulating everyone, promotions handed out), and is highly complex where new issues are discovered that were never thought of in planning. There is no "fast" in this situation and it's where most of us live every single day. And they want it all by X date or everything goes tits up (not really but managements' metrics: dates and "done," are causing them to pressure people--and by people I mean junior devs who are running on the career treadmill at a corp). Meanwhile there are devs who go fast because they like the immediate praise. They literally print bugs with their keyboard--and they bite hard.
  - Sammi 5y ago
    Yeah that's the Agile I added a caveat about at the end.
- agent327 5y ago
  He isn't saying that 100% of requirements must be understood up front, but that each stated requirement must be 100% understood by the developers. Not really understanding a requirement means you don't understand what the customer is asking for, and are likely to go build the wrong thing. It's a communication failure between the developer and the customer, and while I'll happily blame the customer for that, I also see it as my job to figure out what was really meant. Understanding each requirement fully does not, unfortunately, imply you know everything there is to know about the desires of the customer, but at least you are on much firmer ground than if you only barely know what you are supposed to be making in the first place.
- forgotmypw17 5y ago
  I think that's the "building a brige" model of software. But there is also the "writing a book" model, where a general plot outline is first, but the characters write themselves and often surprise the author.
dgb23 5y ago
> But in my experience, it's often my job as a developer to decide on the last so many percent of the requirements, and asking other people doesn't help much because they all have their own work to do. (Note: The article addresses the issue with incremental development.) I agree, not necessarily because people have other stuff to do, but rather because that is what programming _is_: you operationalise a vague process into something detailed and clear so a computer understands it. It's really a spectrum that is never clear cut. The article suggests that one should take time to get close to a clearer picture by thinking, investigating and communicating before writing actual code. I tend to agree.

quickthrower2 5y ago

That’s the judgement call to make and sometimes I don’t ask but assume when (i) it’s easy to change later, in other words a 2 way door (ii) asking will cause meetings, scheduling challenges (need to get everyone in the room!) and delay work and (iii) the people I’m asking might bike shed it taking up lots of their time and mine. It’s the developers discretionary power! Perhaps the colour of the capacitor inside the iPhone … you don’t need to run past Jobs (back in the day…)

IshKebab 5y ago

Yes, people who say you should never assume anything just don't realise that they assume things all the time. They have to or they would never get anything done. Assumptions go wrong sometimes, but they go right and save so much time so often that you can't just throw them all out. The real advice is "learn when to question assumptions" but that just takes experience and you can't write blog posts about it.

Sammi 5y ago

Yeah I kinda balked at the "figure out 100% of the requirement up front" statement. That's usually how I define waterfall development. I like to go fast and make a test build to show someone else and get feedback. Cause I know one person can never see the whole picture. Code is a conversation. This is the essence of Agile (not the Agile that paid management consultants teach).

datavirtue 5y ago
But we're working stories with points that are mapped to days and all the epic deliverables are planned according to the story estimates and this epic HAS to be done before the next epic and those epics both must be done by X date. Now picture you are reworking almost an entire process or part of the system that has already been delivered (management jumped up and down congratulating everyone, promotions handed out), and is highly complex where new issues are discovered that were never thought of in planning. There is no "fast" in this situation and it's where most of us live every single day. And they want it all by X date or everything goes tits up (not really but managements' metrics: dates and "done," are causing them to pressure people--and by people I mean junior devs who are running on the career treadmill at a corp). Meanwhile there are devs who go fast because they like the immediate praise. They literally print bugs with their keyboard--and they bite hard.
- Sammi 5y ago
  Yeah that's the Agile I added a caveat about at the end.
agent327 5y ago
He isn't saying that 100% of requirements must be understood up front, but that each stated requirement must be 100% understood by the developers. Not really understanding a requirement means you don't understand what the customer is asking for, and are likely to go build the wrong thing. It's a communication failure between the developer and the customer, and while I'll happily blame the customer for that, I also see it as my job to figure out what was really meant. Understanding each requirement fully does not, unfortunately, imply you know everything there is to know about the desires of the customer, but at least you are on much firmer ground than if you only barely know what you are supposed to be making in the first place.
forgotmypw17 5y ago
I think that's the "building a brige" model of software. But there is also the "writing a book" model, where a general plot outline is first, but the characters write themselves and often surprise the author.

dgb23 5y ago

> But in my experience, it's often my job as a developer to decide on the last so many percent of the requirements, and asking other people doesn't help much because they all have their own work to do. (Note: The article addresses the issue with incremental development.) I agree, not necessarily because people have other stuff to do, but rather because that is what programming _is_: you operationalise a vague process into something detailed and clear so a computer understands it. It's really a spectrum that is never clear cut. The article suggests that one should take time to get close to a clearer picture by thinking, investigating and communicating before writing actual code. I tend to agree.