Usability
They tried to say "U, SIR, are cray in the bay." But hey, Test-Driven DevOps Design recognizes that Service-orientation is inevitable when Technology is applied. That's why I, @AsherBond created a domain specific programming language aimed at the USIR. Usability means that if there's no one-size-fits-all approach, then all the approaches should be consumable quickly and easily. Usability befriends the newcomer, since Test-Driven-DevOps design recognizes that the newcomer can be converted to a come-backer. Usability doesn't simply mean ease-of-use because for a platform or domain specific language to be usable it also must cater to the senior developer and his or her native language, so as to roll forward at all times leveraging prior expertise. I expect more people to be building something more cool than they are willing to admit. If a developer is a product developer learning programming they may tell you to get off the discovery path and that what they are working on isn't that cool. Yeah I (don't really) bet. Some are shy about learning how to develop software and some want to build something without climbing a steep technical incline in the design phase. Others just don't like competitors on a common discovery path. Maybe they are really product developers creeping into software development. Either way, GitStrapped is a domain-specific programming language for you if you are USIR friendly. These days every software vendor with a domain wants a domain-specific programming language. If they want to copy me, I'm out here pushing @ServiceTemplates for those who love to copy. My question to the USIR is, with all these domain-specific programming languages out there on every software vendor's PaaS.. DOES THEIR DSL SPEAK YOUR LANGUAGE!?!?
Scalability
In the old days, either it was easy to use or it was scalable. Now there's a domain-specific programming language not just aimed at ease-of-use (a facet of usability) and not just aimed at scalability, but both. What do I mean by scalability? I mean that if there was a spike of unpredictable demand for a given application, then that application would be able to serve as many users as demanded service from that application. Scalability generally implies automation and orchestration, but it also implies multi-tenancy.. meaning that many users can access it with some degree of user isolation, giving each user the experience of their own dedicated environment. In production, scalability implies security and of course system-quality. In Test-Driven DevOps new features pass through tested quality-assurance prior to reaching any production environment, so this is where system quality attributes are first tested. Continuous quality assurance is also part of ongoing (sustainable) operations in DevOps, which is iterative. Sustainability is a required system-quality attribute in scalable systems. These are the implied "ilities" which fall under scalability, from a USIR-friendly Test-driven DevOps design perspective.
Interoperability
Interoperability is a specific subset of Usability by which tools can be used together without much friction or modification if any. In a Test-Driven-DevOps-Design approach, tools will actually be the output of each iteration. This means that newly developed tools and old tools which already exist need to be tested against each other within a framework of interoperability constraints.
Repeatability
DevOps was born out of the desire to achieve rapid deployment of applications. Now DevOps offers a lot more than velocity, but at this time it still appears to be the number one attracter of DevOps adopters to DevOps culture. I have seen many startup companies which hire Rubyists or other bright developers and put them in a product development role. Some day perhaps they will realize they have embraced or at least discovered a DevOps-Design approach. The next step will hopefully be that they will discover Test-Driven-DevOps-Design. When Test-Driven-DevOps-Design methodologists or other DevOps culturists discuss Repeatability, we are generally speaking about the value of repeating success after a test and minimizing the repetition of failure. It is much more sustainable to repeat success than failure. A Template-driven, Test-driven-DevOps-Design approach encourages experimentation because it costs less to fail earlier and talk about what works and what doesn't sooner. If you have written the test into the template, this should generally happen automatically. Faster failure with a reaction which does not continue to fail reduces cost right away and in the long term. If that's not worth the culture shift then perhaps the ease of repeating success from a tested template might be more convincing. Idempotency is a subset of repeatability which guarantees the same result after repetition. For the USIR, Idempotency is part of the Test-Driven-DevOps-Design approach.
Readability?
I shouldn't even need to put this here, because it's implied in Usability, Scalability, and Repeatability. Since we're on the topic of development, developers should be able to read existing code if they are to improve upon it. If the code is undreadable, then it's not fully usable. If a system can't be understood, then it's not scalable and necessary ongoing change isn't repeatable. An obfuscated or blindly-abstracted application may be consumable by someone who isn't a developer.. but I would argue that a system like this is a legacy system designed for obsolescence. If that's what you're into, it's not Test-Driven-DevOps Design and it's probably not even DevOps, since it can't be developed in a sustainable manner. I think it's useful to be able to compile something into a binary, but there should be source that a developer who is expected to be developing can read. If an operator can't read it, then understanding how the system works is more difficult.