Software development pop vernacular probably doesn't need another "ility" word. We've got a good collection of the them already: scalability, extensibility, availability, recoverability, among others. Nonetheless...
Mature production industries already recognize a design quality called "workability". Workability is at the heart of a number of software design qualities that individually often deliver a fractured message about what makes good software practices good. Approaching software design and implementation from the perspective of workability helps me stay focused on the higher order objective while simultaneously not loosing track of the principles and practices that permit workability in software development. That higher order objective is producing. Or said differently, it’s production. Or better yet: productivity.
In The Toyota Product Development System, the authors talk about Toyota's concern with workability during digital assembly, a form of virtual reality simulation geared partially to proving that a product's build workflow is practicable:
Use workability DA [Digital Assembly] to study in detail the effects that design changes will have on ergonomic issues involved in assembling a vehicle. By utilizing DA in conjunction with the assembly plant pilot team (hourly workers assigned for two years to work on preparing a new vehicle launch) during the Kentou [prototyping, modeling] period, they can address both current as well as anticipated human factor issues and identify the ergonomically safest and most efficient way to assemble the vehicle.
Workability is the design quality that simply permits a job to be finished some day. Workable software allows us to keep working on a software product without being obstructed by the software that we’ve already added to the product. Without considering workability in design, workers end up painting themselves into corners that they can’t get out of.
We see this all the all the time in software projects whether we recognize it or not. When productivity degrades sharply after the initial parts of a software product are built and assembled, it’s the absence of workability that is at the root of this all-too-common situation.
Workability is a higher order concept that accounts for a myriad of principles, properties, tactics, and counter measures that are constantly in-play when high-functioning teams are at work. In software, workability is the testability, the readability, the maintainability, the SOLID principles, and a host of concerns that are continually being balanced, evaluated, and enacted during design and implementation in the name of defending a software effort from stasis. In fact, those principles are so essential to productivity that they are far from unique to software. They permeate all kinds of production across many industries.
There are a lot of elaborate and expensive tools and ideas in the software industry, but the vast majority of them simply don’t serve workability, and many of them actually obstruct higher orders of productivity. If productivity can’t be sustained over an entire software effort, then that initial productivity really isn’t much in terms of productivity, is it? In fact, productivity that can’t be sustained is arguably not productivity at all, and tools that deliver an initial, rapid productivity spike at the beginning of an effort are likely also contributing to it’s decline.
Sustainable productivity isn’t the result of tools, it’s the result of the collection of design qualities and practices that in aggregate can be thought of as workability. Tools serve workability, but they can’t cause it – people cause it. As long as people are involved in making things, workability is simply how good things get made.
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
