> 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.
I'm not talking about any specific PM strategies though. For the software to be written, it must be specified. Whether that's in a ticket or design doc is irrelevant.
As you point out, the agile manifesto eschews documentation for working software. This is not about having documentation, it's about defining "working" for the software. The ticket could not be written or handled without consultation with legal or BA teams on how the formulae are defined, similarly to how if you're implementing any kind of system where the formulae are critically important for correctness you need to consult back and forth with the expert stakeholders to double check.
I don't know any other way to do this that isn't negligent, not just by the developer, but by the reviewer, the stake holders, and ultimately the PM that signs off on accepting the task as "done" when it hasn't been checked for correctness.
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.
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.
I know it's not the "Agile way" and it often isn't done but I am advocating for leaving the details of core business decisions (e.g. how royalties are calculated) to the people who's competence lies in this question: the business development and legal teams - and not the software development team to whatever is easiest to implement for them. The latter might not always be what's best for the business. If you are not doing that, you need many iterations to rediscover what's already known to the organization.
> "Working software over comprehensive documentation"
Working includes correctly working. As soon as you interface with the legal world this means to actually calculate whatever your business agreed to and not something else just because it's easier, produces some random numbers, and exists without printing to stderr. That's not working software.
This typically can't be worked out by development teams themselves, for the reasons you mentioned. And that's exactly why some kind of spec (in whatever form necessary - probably not a document of hundreds of pages but also not a one sentence user story) is needed to capture that. That's what I mean by translating and I'm not proposing to leave that to some product manager.
Of course this can also be fixed by adapting your contracts (which can be an enormous task) but for that you also need some documentation on whatever the system is doing (just as developers can't read contracts, lawyers can't read code) and will discover that many stakeholders won't agree to that and demand changes.
This is all not to be confused with doing a big design of the technical architecture and all features beforehand.
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.