Applying “make invalid states unrepresentable” • Hacker News Board

Re: Applying “make invalid states unrepresentable”

#191

Post by arwhatever » Tue, Oct 06, 2020, 7:58 PM UTC

judofyr wrote: post #26

In general I agree that it's nice to make invalid states unrepresentable, but I'm not sure if I agree that this counts as a fundamental "invalid state". There is nothing about contracts which require that you can only have one active at the same time, or that that current one must be open ended. From a practical point of view it might be advantageous if you maintain only a single contract with a customer at all times…

I suspect there might exist a fundamental difference in the way automated-testing, static-type-leveraging software developers view software design and requirements compared to those who don't.

I have no idea about the commenter here, but in my direct personal experience, the "those who don't" developers tend to regard software design and requirements to be toward the "write-only, then try to never change" end of the spectrum.

I get a lot of "are you crazy? We can't change that!" type of pushback from the those-who-don'ts, regarding functional changes that should be reasonably manageable to my testing/typing mind.

Re: Applying “make invalid states unrepresentable”

#192

Post by ovi256 » Thu, Oct 08, 2020, 12:45 PM UTC

arethuza wrote: post #108

dkarl wrote: post #105

Earlier quoted context omitted.

The requirements here aren't clear, but I'm guessing the requirement is to model the contracts the company actually has with customers. The business also tells you that there are never two contracts running at the same time. But are you actually going to believe that? Is this condition really "impossible?" A vital and necessary factor here is whether the system being designed has complete control of the creation of c…

I once did weeks of work trying to unpack what my employer meant by the term "customer" - if your customers are large companies with hundreds of legal entities and hundreds of locations across the world things can get pretty complex pretty fast e.g. does "never two contracts running at the same time" mean that you can't have a contract with a subsidiary and another separate subsidiary of the same parent (which might…

A method that works well for this kind of analysis in my experience is to start by looking at the data, together with a business person and then ask the needed question until you can model it. "Oh so I see we have customers that are sites of large corporations, so that is a requirement" "Oh and these rows look like subsidiaries" etc

Re: Applying “make invalid states unrepresentable”

#193

Post by ric2b » Fri, Oct 09, 2020, 11:18 AM UTC

thewebcount wrote: post #171

goto11 wrote: post #142

Earlier quoted context omitted.

Under what circumstances did following YAGNI lead to added complexity?

A real world case I recently ran into where thankfully we realized we would need it and added it is versioning. A struct you pass to or receive from an API that has a version in it means the difference between being able to make changes to the internals without changing the externals and not being able to. We didn't need the version field until the second version was released. Had we just said, "Oh, we aren't going t…

That's slightly different, that is not predicting future requirement changes but making it easier to make breaking changes when needed.