<dl> 
  <dt>Modularity</dt>
  <dd>Modularity is the degree to which a system's components may be 
    separated and recombined.</dd>
  
  <dt>Reusability</dt>
  <dd>Reusability is the use of existing assets in some form within the 
    software product development process. Assets are products and by-products 
    of the software development life cycle and include code, software 
    components, test suites, designs and documentation.</dd>
  
  <dt>Combinatoriality</dt>
  <dd>Combinatoriality is a sociological quality of software that can be 
    combined (or piped together) in any combination to meet, exactly, the 
    unique vision of the creative individual or team. This is achieved by 
    using uniform function arity, argument order, name schemes and 
    conforming to a spartan set of well-established standards appropriate 
    for the programming language and stack at hand (e.g. streams or 
    Promises).</dd>
</dl>

<p>Combinatoriality is what we really want when we say modularity or reusability. 
  Modular code is separated code. It can be like turning a block of chocolate into
  chocolate chips with a hammer. The chocolate is not broken up, but not exactly
  designed to be fit back together in any configurations. Re-use is the right word
  for an aspect of what we mean, but doesn't get at how re-use is encouraged / or 
  when, why and how we re-use. Hence, combinatoriality to the rescue.
</p>

<p>
  Combinatorializing code is one of those things in life where you just can't do it
  unless you have guiding principles for it. It's too complicated to handle it well
  any other way. The great news is that it's not so hard once you solidify the 
  principles and excersice them in a team context a few times. Team context is 
  needed because combinatorialization is not very meaningful unless there are 
  teammates to combine your creations into creations of their own.
</p>

<p>
  I can't stand here and tell you what your combinatorial guiding principles are.
  I'll share a few of those that have worked for me and my teams as an example.</p>

<ul>
  <li>Functions should never have more than 4 arguments</li>
  <li>If there's a callback, it should be last</li>
  <li>If there's an options object but no callback, the options object is last</li>
  <li>All functions should be designed with partial application or currying in mind</li>
  <li>Options objects should be prefered over individual arguments</li>
  <li>Never call a directory or module utilities when a more specific name can be used</li>
  <li>Eliminate all naming redundancies: FooView/BarComponent/BazElement/QuxVisualization—pick one</li>
</ul>

<p>
  There are a few practices that will naturally aide in combinatoriality.</p>

<ul>
  <li>Unit testing</li>
  <li>Asking people to use your code in front of you</li>
</ul>