I’m a big fan of cohesive development, design that takes the present/past environment into account, and looking to others to see how they may have solved a problem.

To emphasize, I look for things that:

  • acknowledge the environment, work with what’s already there (and discuss what flaws and limitations that highlights)
  • acknowledge the other entities in the space: similar technologies, cooperative technologies
  • acknowledge and discuss the existing solutions to discuss why they may be unsuitable, necessitating a new development
  • respect the time and efficiency of others
  • accurately distribute labour: automation for automata, innovation for the “meatware” the users

Unfortunately, I can be a bit harsh on those who don’t. I can be scathing to solutions that are obviously flawed, ignore the issues resolved by others, ignore the possibility of compatibility, and try to re-invent a brand new wheel. This can be as simple as Inventing new codes and formats, or using charming (but non-portable) colloquial ones where the ISO has laid out guidelines that many others already follow:

  • Date formats: ISO-8601 narrowed by RFC-3339 has been around a long time, and the benefits are explained in detail elsewhere (google?) (note: also a key part of XML)
  • File formats: why did you invent one? Did you check to see if there’s an existing format used anywhere else?
  • File formats again: CSV is error-prone and unportable (comma is a decimal in some countries); XML is a bit wider but has numerous advantages, including conversion and portability

There are ways to unambiguously show a date. How about one that meatware can read, and software can take apart as math or as text?

There are only so many countries in the world, and they’ve been encoded down to the prefecture/county level. Why invent your own new system?

To design a solution so that it accounts for one pre-existing issue with the environment, and so that it’s compatible with one tool that exists in the implementation space, that makes it work with one other thing. That puts that solution in the top-half in terms of quality. Compatibility with anything at all shows that consideration was made for preexisting entities, and the deliverable itself was designed in a portable fashion. The benefit is that other tools that address that one environmental limitation (ie “works with COBOL”) and/or use that one other-tool’s format are immediately more compatible with everything else that uses that format or “works with COBOL”.

There are many standards entities out there — don’t be a new one. Just because one that’s out there for 22 years wasn’t invented in your head, it might still be useful. Look before inventing a new one. Just because you’ve been using your own time-notation for 6 years doesn’t mean anyone else has — so see what any two others are using, and already it’s easier to join them. It’s easier to change one rather than two, and to assume you’ll never work together might be a bit of a silly wall to throw in the way.

Look around, choose something to work with, and do so. It’s like choosing one person to work with in a new group. We are better as a team when we speak the same “language”.