<story><title>Applying “make invalid states unrepresentable”</title><url>https://kevinmahoney.co.uk/articles/applying-misu/</url></story><parent_chain><item><author>judofyr</author><text>In general I agree that it&amp;#x27;s nice to make invalid states unrepresentable, but I&amp;#x27;m not sure if I agree that this counts as a fundamental &amp;quot;invalid state&amp;quot;. 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.&lt;p&gt;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 &lt;i&gt;business&lt;/i&gt; requirement which might be changed in the future.&lt;p&gt;I mention this mostly from experience: Multiple times I&amp;#x27;ve designed systems where I&amp;#x27;ve reduced the representable states to the minimum, and when some requirements change I realize I have to re-design the full system.&lt;p&gt;The new presented representation might make sense in &lt;i&gt;this&lt;/i&gt; situation, but I&amp;#x27;d be very wary of taking current business practices and make all other alternatives &lt;i&gt;impossible&lt;/i&gt; to represent. It&amp;#x27;s a balancing act of course as you can go in the opposite direction and make it way too flexible.&lt;p&gt;&amp;gt; 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.&lt;p&gt;I&amp;#x27;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&amp;#x2F;end dates) made it possible for you to verify that everything was correct and lined up.</text></item></parent_chain><comment><author>goto11</author><text>&amp;gt; Multiple times I&amp;#x27;ve designed systems where I&amp;#x27;ve reduced the representable states to the minimum, and when some requirements change I realize I have to re-design the full system.&lt;p&gt;Yes, if requirements change, you change the design and code to support the new requirements.&lt;p&gt;Compromising the consistency and maintainability of the current design to accommodate a hypothetical future requirement change is a bad trade-off IMHO, since you can&amp;#x27;t predict the future. A requirement change may happen in a completely different direction than the one you anticipated, and then you have the worst of both worlds.&lt;p&gt;It is better to make code &lt;i&gt;maintainable&lt;/i&gt; than making it &lt;i&gt;flexible&lt;/i&gt;.</text></comment>
<story><title>Applying “make invalid states unrepresentable”</title><url>https://kevinmahoney.co.uk/articles/applying-misu/</url></story><parent_chain><item><author>judofyr</author><text>In general I agree that it&amp;#x27;s nice to make invalid states unrepresentable, but I&amp;#x27;m not sure if I agree that this counts as a fundamental &amp;quot;invalid state&amp;quot;. 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.&lt;p&gt;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 &lt;i&gt;business&lt;/i&gt; requirement which might be changed in the future.&lt;p&gt;I mention this mostly from experience: Multiple times I&amp;#x27;ve designed systems where I&amp;#x27;ve reduced the representable states to the minimum, and when some requirements change I realize I have to re-design the full system.&lt;p&gt;The new presented representation might make sense in &lt;i&gt;this&lt;/i&gt; situation, but I&amp;#x27;d be very wary of taking current business practices and make all other alternatives &lt;i&gt;impossible&lt;/i&gt; to represent. It&amp;#x27;s a balancing act of course as you can go in the opposite direction and make it way too flexible.&lt;p&gt;&amp;gt; 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.&lt;p&gt;I&amp;#x27;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&amp;#x2F;end dates) made it possible for you to verify that everything was correct and lined up.</text></item></parent_chain><comment><author>steve_g</author><text>There are trade-offs, of course, but I&amp;#x27;m generally not a fan of using implicit defaults for business applications (i.e., the application infers the default when there&amp;#x27;s no data).&lt;p&gt;If things go well, business data outlives business applications.  After years or decades, it can be a major pain to figure out all the &amp;quot;secret&amp;quot; values that aren&amp;#x27;t actually in the data.</text></comment>