4 ms·

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

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.
- germanier 5y ago
  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.

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.

germanier 5y ago
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.