The following is a list of attributes I believe most high-quality software has in common. These attributes are coupled with our list of Artium’s default practices. I believe we should build software to this spec and use our default practices to achieve it. Each is a series of questions designed to ask ourselves if we are creating software to the standards that we hold.

Note that these are in no particular order; each is equally important to the others.

1. Achieves the Business Goal
   Does the software have business concerns baked into the system itself?  Does it fit itself to the realities of the market?  Does it get out of the way of making money or achieving another business goal?For example:  If it’s a social network, does the software encode and monitor a notion of virality?  If it’s a SaaS solution does the software automatically bill on a recurring schedule?  Does it measure and report on customer churn?

2. OperableI
   s the software easy to run & operate in production?  Is it easy to onboard & manage users of the software?  Easy to scale & debug?

3. Changeable
   Is it easy to add new features?  Is it easy to change functionality?  To ship new changes or versions?

4. Beautiful & Emotional
   Is the software designed in a compelling way that makes the users feel good?  Does it contain aspects of Art and Design that resonate with users in a difficult to verbalize way?

5. Learnable Code Base
   Is it easy for new team members to ramp up & understand how to make progress?Does the codebase contain the following?  Unit tests, integration tests, a readme file describing setup, documentation, style guides, roadmap, backlog, credential management, and workstation setup script

6. Scalable
   Is there a plan for the software to effectively scale?

7. Compliant
   Is the software compliant with relevant organizational & government requirements?

8. Secure
   Does the software follow security best practices?  Are we confident it would stand up to a security audit or penetration test?

Of course in actual engagements and on actual teams we have to respect the rule of specificity, more specific knowledge of a situation takes higher priority over these general guidelines, but consider this the default - we should have a very good reason NOT to build software in this way.

- Ross Hale, CEO at Artium