Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Applying “make invalid states unrepresentable”

kevinmahoney.co.uk

Post reply on HN
Print view View original

21–30 of 193 posts

Re: Applying “make invalid states unrepresentable”

#21

Post by jka »

lmm wrote: post #11
etripe wrote: post #3

This is a good introduction on a conceptual level. I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. To make unrepresentable states practical, Scott Wlaschin has an excellent write-up here (0). His book (plugged in that article) is also excellent. [0] https://fsharpforfunandprofit.com/posts/design…

> I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. I think that's exactly backwards. This kind of overcomplicated representation usually happens because people put too much effort into designing their representations up front. If you follow story-oriented development and only implement the parts…

To be fair, both are possible scenarios:

- A team spends too much time over-engineering a representation for something that could be more easily maintained using a simple model

- A team spends too little time considering the edge cases with a representation because they feel pressure to deliver the feature within a short space of time

Re: Applying “make invalid states unrepresentable”

#22

Post by Aeolun »

lmm wrote: post #11
etripe wrote: post #3

This is a good introduction on a conceptual level. I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. To make unrepresentable states practical, Scott Wlaschin has an excellent write-up here (0). His book (plugged in that article) is also excellent. [0] https://fsharpforfunandprofit.com/posts/design…

> I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. I think that's exactly backwards. This kind of overcomplicated representation usually happens because people put too much effort into designing their representations up front. If you follow story-oriented development and only implement the parts…

Our database gets shit added on an ‘as necessary’ basis, and I guarantee you it’s not a great thing.

Re: Applying “make invalid states unrepresentable”

#25

Post by dtech »

lmm wrote: post #11
etripe wrote: post #3

This is a good introduction on a conceptual level. I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. To make unrepresentable states practical, Scott Wlaschin has an excellent write-up here (0). His book (plugged in that article) is also excellent. [0] https://fsharpforfunandprofit.com/posts/design…

> I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. I think that's exactly backwards. This kind of overcomplicated representation usually happens because people put too much effort into designing their representations up front. If you follow story-oriented development and only implement the parts…

the flip side of this is that sometimes your initial designs need to be expanded to account for something new and that's hard, leading to tech debt and hacks.

personally I think that's a better trade-off than implementing something complicated up-front that you don't know will work and ending up with flexibility in the wrong places, leading to tech debt and hacks.

Re: Applying “make invalid states unrepresentable”

#26

Post by judofyr »

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, but that is a business requirement which might be changed in the future.

I mention this mostly from experience: Multiple times I've designed systems where I've reduced the representable states to the minimum, and when some requirements change I realize I have to re-design the full system.

The new presented representation might make sense in this situation, but I'd be very wary of taking current business practices and make all other alternatives impossible to represent. It's a balancing act of course as you can go in the opposite direction and make it way too flexible.

> This poor choice was not just a theoretical problem - gaps in contracts were found on more than one occasion, requiring hours of engineering effort to hunt down and fix.

I'd like to hear more about what happened here. Was the problem that the default contract was not re-applied correctly? If so, changing the representation might not actually solve any problems — it make actually make it _worse_. A renewal of a contract typically involves some automated process where other services are involved (payment, invoicing, emails). The previous representation (with explicit start/end dates) made it possible for you to verify that everything was correct and lined up.

Re: Applying “make invalid states unrepresentable”

#27

Post by seer »

While this is great if you know exactly what you want to achieve, it does “lock you in” those constraints on a more fundamental level. More times than I can count I’ve seen business requirements change to require those “unrepresentable” states, and since you’ve now designed you whole data model around it you need to add awful hacks to make it work.

The timeline example is actually very telling. A lot of times you’d actually want to encode overlapping time periods at the edges.

You’d be laughed out off a meeting where a business asks about this and you smugly explain how it is unrepresentable.

I guess what I’m saying is that it might be worth over designing your system a bit to leave you some wiggle room, unless you have hard guarantees that something should be “impossible”

Re: Applying “make invalid states unrepresentable”

#28

Post by thsealienbstrds »

etripe wrote: post #3

This is a good introduction on a conceptual level. I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. To make unrepresentable states practical, Scott Wlaschin has an excellent write-up here (0). His book (plugged in that article) is also excellent. [0] https://fsharpforfunandprofit.com/posts/design…

It doesn't sound to me like the kind of thing that any particular WoW is going to fix. As if it would suddenly naturally dawn on someone to do this given enough time. It's just lack of knowledge and/or discipline.

Re: Applying “make invalid states unrepresentable”

#30

Post by secondcoming »

matsemann wrote: post #17
joosters wrote: post #13

Earlier quoted context omitted.

A set doesn't necessarily imply an ordering (unless this article is about some specific programming language, but it seemed fairly generic to me). e.g. Java and C++ have many Set implementations, some sorted (e.g. a TreeSet) and some not (e.g. HashSet)

That's the point. There's no ordering of the items. So the representation can never have an error like [yesterday, tomorrow, today]. It's just a set of (yesterday, tomorrow, today).

So finding out a contract type from a timestamp is linear?
Post reply on HN