For third-party technology auditors

Speaking from Kittler’s point[0], “information hiding” has become a principle of Good Language design; i.e. “encapsulation”, surviving the criticism railed against object-oriented languages (polymorphism and classical inheritance, too, are terrible ideas; but whatever, if an organization or client wants, then the customer gets). So this mentality is the basis from which I make these suggestions. “Hiding” things has become the rule of the day, and I don’t like that; if anything, I want to expose more of the “bare metal” of the underlying systems in the OSI model’s base layer, the Physical layer, to the developers as much as the users, but obviously in a way that is intuitive, meaningful, etc. toward better shared understanding of these systems. So it is with this point that I recommend that ideally software technology auditors:

* MUST[1] look for explicit forms of documentation which identify gaps in comprehensibility; e.g., lack of explicit /typing/ either in documentation around the code or as part of the language itself (so, a function may expect parameters and somewhere those parameters should be explicitly stated to have a type and a purpose of such-and-such a sort)
* SHOULD look for static code analysis, which would supply a grounding for using the concept of “maintainability” (in what sense can the developers, analysts and testers meaningfully evaluate that the code itself has such-and-such a code quality as it relates to their agility? it is widely known that static code analysis improves agility[2] and helps restrain code complexity)
* SHOULD look for automation workflows that ease the pain of developer experience to test, automate and drive the application in the development of more complex features; e.g., a login (user) workflow should be available to onboarding developers, and ideally all workflows should be developed by developers for developers
* SHOULD look for accessibility tools as well as basic accessibility constraints (regardless of whether the application is intended for the Web context)
* SHOULD look for API maturity in terms of whether both front end and backend systems are striving to achieve the Richardson Maturity model[3] (hypermedia-orientation may not be a demand given the closed-nature of various existing systems today, but democratization should always be a concern for the health-care industry[4]; elsewhere I have read Corissa Bowman has written about interoperability, and existing systems would benefit from thinking in terms of the Robustness principle as well; an example of a robust API, such that the client is not constantly taking on debt to adapt to its lack of robustness, would be where the API accepts negative values for a field which is semantically inappropriate so then the front end has to restrict this through “automagically” implementing code to compensate for the APIs counter-intuitiveness. It goes without saying that the problem is a form of tech debt of some sort and is a product of legacy, but that doesn’t change the fact that it should, for all intents and purposes, be fixed; or the API should be versioned in such a way to allow new front ends and clients not to have to make such leaps and bounds to contort their way around this limitation)

[0]: “*When meanings come* down to sentences, sentences to words, and words to letters, there is no software at all. Rather, there would be no software if computer systems were not surrounded any longer by an environment of everyday languages.” [CTHEORY: There is No Software](
[1]: [RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels](
[2]: STATIC CODE ANALYSIS IN AN AGILE WORLD: Establishing a repeatable process to achieve working software with each iteration.
[3]: [Richardson Maturity Model](
[4]: [Data democratization in healthcare — the API Way — MedCity News](

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store