4 ms·

Why was this not defined in a spec document and checked in a unit test? Everywhere I've worked where there were defined formulae (or formulae to be defined) th

by duped 5y ago

Why was this not defined in a spec document and checked in a unit test? Everywhere I've worked where there were defined formulae (or formulae to be defined) this kind of thing was meticulously checked for correctness. No one should have shipped the service without knowing if the calculations were correct!

MetallicCloud 5y ago
At faang companies, there's never a spec document.
- xyzzyz 5y ago
  In FAANG, if people had to write accurate spec in addition to all of the other steps of the process to launch something at a big corp, nothing would ever get done.
ALittleLight 5y ago
One problem with high turnover is that the people who have developed an understanding for how the systems should work, and which documents are definitive, are long gone and if you're lucky you know the people who knew them. A big part of the problem with the situation I'm discussing here is that the people who were using the tool were using it incorrectly. The people using the tool (which made offers available to specific customers in certain conditions) did not understand the nuances of the different price values on offers and how they connected with royalties. I forget the specifics, but imagine someone working with publishers to setup special offers and entering prices into our tool and they just populate two of the three different "Price" fields with the same price because they don't know the difference between "list price" and "my price" and they put the right value in "discount price" (or whatever the terms were). Totally unknown to the person entering the offer, royalties are (incorrectly) calculated based on one of those columns that they have now put a technically incorrect value into. Even if there was a perfectly clear spec, and there wasn't, and it had been implemented perfectly, the tool still would've failed because the people using it didn't really understand the system either.
rtpg 5y ago
What happens in reality is someone writes the spec as "40% of the unit price" or something, and that gets taken from some DB table at Amazon that has "unit price", but the meaning is different from what the spec refers to as "unit price". Meanwhile both sides of the interaction (Amazon and the publishers) are using words they recognize, but with different meanings behind them! And both sides are so used to seeing the words that _of course_ it's the right thing (until it's not!). Of course the reality is probably more subtle than this, but spec documents don't save you from domain knowledge (or lack thereof) 100% of the time. Definitely helpful as a reference document, of course! And it eliminates a large class of discussions.
Dave3of5 5y ago
> Why was this not defined in a spec document and checked in a unit test? Most companies now-a-days don't write spec up front. That's called Big Design up Front (BDUF) and it was seen in this industry that this was prone to failure which could cause the whole project to fail. That's because it's impossible to know everything up front and often during the project the requirements will change as the stakeholders learn of the consequences of their decisions. In fact most companies don't do a "spec document" at all they design their system in small iterations called "sprints" typically 2-weeks and the "spec" is a ticket in a system like Jira (others are available). This process is part of Agile Project Management methods > Everywhere I've worked where there were defined formulae (or formulae to be defined) this kind of thing was meticulously checked for correctness There are some industries where they still do that kind of thing (BDUF) for example government work, defence, oil and gas. These are older industries that just haven't changed the way they approach projects. Amazon here is a bit a front runner when it comes to updating it's practices to be more leading edge so they likely adopted an Agile approach here learning about what was required as they go through the project.
- germanier 5y ago
  In cases like this, the spec already exists though: in form of binding contracts. Lawyers already took that matter into their hand and created that spec. Customers agreed to it. Not translating them into technical requirements early in the process is usually followed with a world of pain.
  - Dave3of5 5y ago
    This isn't a way that software is typically made. The contract will most likely be done and dev are not normally involved and it'll be written after the process of the software being made. I don't think in 16 years I've ever gone through a legal contract and translated that into a technical requirement. It's normally done the other way round that some requirement is translated into legalese. Reading legal documents is not a skill I would expect of any developer and I would be extremely wary of building software using this technique. Reading contracts requires many years of training that almost all developers do not have. Also note that laws are not universal and different jurisdictions will often allow different interpretations. An example of this is USA vs UK law, they are quite different and so if you are trying to interpret a USA contract as some from the UK you'll probably need a lawyer from the US on hand to help explain what they mean by certain terms. Without this training it can be very easy to misinterpret what is actually being said in a legal document. I'd also say that as a dev/po/pm/qa or basically anyone involved in the actual development it's not in my job description to be able to read legal documents so I'd be quite within my rights to refuse to do this work. The point I made which you seem to be ignoring is that from the original Agile Manifesto: "Working software over comprehensive documentation" So you don't write a spec document up front but discover the requirements as you progress through the project. I suspect for Amazon this is exactly what they are doing there is no "spec document" and there was no contract but as they progressed through the project they just built a overly simplistic approach to the Royalty calc. Afterwards they got a contract written and the lawyer either wasn't told what the software actually done or just wrote what was the standard industry contract for Royalties. Please Note: I'm not advocating for Agile vs any other technique but I was responding to the comment that you should just read a spec and code that directly into code that's just not the way you do things in an Agile environment.

by duped 5y ago

MetallicCloud 5y ago

At faang companies, there's never a spec document.

xyzzyz 5y ago
In FAANG, if people had to write accurate spec in addition to all of the other steps of the process to launch something at a big corp, nothing would ever get done.

ALittleLight 5y ago

One problem with high turnover is that the people who have developed an understanding for how the systems should work, and which documents are definitive, are long gone and if you're lucky you know the people who knew them. A big part of the problem with the situation I'm discussing here is that the people who were using the tool were using it incorrectly. The people using the tool (which made offers available to specific customers in certain conditions) did not understand the nuances of the different price values on offers and how they connected with royalties. I forget the specifics, but imagine someone working with publishers to setup special offers and entering prices into our tool and they just populate two of the three different "Price" fields with the same price because they don't know the difference between "list price" and "my price" and they put the right value in "discount price" (or whatever the terms were). Totally unknown to the person entering the offer, royalties are (incorrectly) calculated based on one of those columns that they have now put a technically incorrect value into. Even if there was a perfectly clear spec, and there wasn't, and it had been implemented perfectly, the tool still would've failed because the people using it didn't really understand the system either.

rtpg 5y ago

What happens in reality is someone writes the spec as "40% of the unit price" or something, and that gets taken from some DB table at Amazon that has "unit price", but the meaning is different from what the spec refers to as "unit price". Meanwhile both sides of the interaction (Amazon and the publishers) are using words they recognize, but with different meanings behind them! And both sides are so used to seeing the words that _of course_ it's the right thing (until it's not!). Of course the reality is probably more subtle than this, but spec documents don't save you from domain knowledge (or lack thereof) 100% of the time. Definitely helpful as a reference document, of course! And it eliminates a large class of discussions.

Dave3of5 5y ago

> Why was this not defined in a spec document and checked in a unit test? Most companies now-a-days don't write spec up front. That's called Big Design up Front (BDUF) and it was seen in this industry that this was prone to failure which could cause the whole project to fail. That's because it's impossible to know everything up front and often during the project the requirements will change as the stakeholders learn of the consequences of their decisions. In fact most companies don't do a "spec document" at all they design their system in small iterations called "sprints" typically 2-weeks and the "spec" is a ticket in a system like Jira (others are available). This process is part of Agile Project Management methods > Everywhere I've worked where there were defined formulae (or formulae to be defined) this kind of thing was meticulously checked for correctness There are some industries where they still do that kind of thing (BDUF) for example government work, defence, oil and gas. These are older industries that just haven't changed the way they approach projects. Amazon here is a bit a front runner when it comes to updating it's practices to be more leading edge so they likely adopted an Agile approach here learning about what was required as they go through the project.

germanier 5y ago
In cases like this, the spec already exists though: in form of binding contracts. Lawyers already took that matter into their hand and created that spec. Customers agreed to it. Not translating them into technical requirements early in the process is usually followed with a world of pain.
- Dave3of5 5y ago
  This isn't a way that software is typically made. The contract will most likely be done and dev are not normally involved and it'll be written after the process of the software being made. I don't think in 16 years I've ever gone through a legal contract and translated that into a technical requirement. It's normally done the other way round that some requirement is translated into legalese. Reading legal documents is not a skill I would expect of any developer and I would be extremely wary of building software using this technique. Reading contracts requires many years of training that almost all developers do not have. Also note that laws are not universal and different jurisdictions will often allow different interpretations. An example of this is USA vs UK law, they are quite different and so if you are trying to interpret a USA contract as some from the UK you'll probably need a lawyer from the US on hand to help explain what they mean by certain terms. Without this training it can be very easy to misinterpret what is actually being said in a legal document. I'd also say that as a dev/po/pm/qa or basically anyone involved in the actual development it's not in my job description to be able to read legal documents so I'd be quite within my rights to refuse to do this work. The point I made which you seem to be ignoring is that from the original Agile Manifesto: "Working software over comprehensive documentation" So you don't write a spec document up front but discover the requirements as you progress through the project. I suspect for Amazon this is exactly what they are doing there is no "spec document" and there was no contract but as they progressed through the project they just built a overly simplistic approach to the Royalty calc. Afterwards they got a contract written and the lawyer either wasn't told what the software actually done or just wrote what was the standard industry contract for Royalties. Please Note: I'm not advocating for Agile vs any other technique but I was responding to the comment that you should just read a spec and code that directly into code that's just not the way you do things in an Agile environment.