<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Decision Tables on Hillel Wayne</title>
    <link>https://www.hillelwayne.com/tags/decision-tables/</link>
    <description>Recent content in Decision Tables on Hillel Wayne</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 09 Sep 2020 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.hillelwayne.com/tags/decision-tables/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Decision Table Patterns</title>
      <link>https://www.hillelwayne.com/post/decision-table-patterns/</link>
      <pubDate>Wed, 09 Sep 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/decision-table-patterns/</guid>
      <description>Decision tables are easy, simple, and powerful. You can teach them in five minutes and write one in half that time. You can look at a table and understand what it&amp;rsquo;s saying, see if it matches your problem, and check for design flaws. So it&amp;rsquo;s kinda weird that there&amp;rsquo;s basically nothing about them online. I wrote an introduction a while back, but I want something a little more formal. So this post will reintroduce the core ideas in a more formal way and then talk about some of the techniques you can apply to make better tables.</description>
    </item>
    
    <item>
      <title>Modeling Missing Requirements</title>
      <link>https://www.hillelwayne.com/requirements/</link>
      <pubDate>Mon, 15 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/requirements/</guid>
      <description>Many bugs are implementation errors: there is a mistake in the code that makes it not do what you wanted it to do. For example, you may have accidentally left out the &amp;ldquo;list is empty&amp;rdquo; case, or written a nonterminating function. You can identify it as &amp;ldquo;definitely wrong&amp;rdquo; for a given input. Most testing, in fact most writing on software correctness, deals primarily with implementation errors.
Above that we have specification errors.</description>
    </item>
    
    <item>
      <title>Decision Tables</title>
      <link>https://www.hillelwayne.com/post/decision-tables/</link>
      <pubDate>Mon, 09 Jul 2018 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/decision-tables/</guid>
      <description>I really like decision tables but they&amp;rsquo;ve fallen out of common knowledge. Let&amp;rsquo;s fix that.
A decision table is a means of concisely representing branching and conditional computations. In the most basic form, you have some columns that represent the &amp;ldquo;inputs&amp;rdquo; as booleans and some columns that represent outputs and effects. It looks like this:
   A B C f(A, B, C)     T T T 1   T T F 3   T F T 7   T F F &amp;ldquo;cucumber&amp;rdquo;   F - - NullError    - means that it doesn&amp;rsquo;t matter what the value is.</description>
    </item>
    
  </channel>
</rss>