3 ms·

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 ma

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

by Sammi 5y ago

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.