Sunday, May 24, 2015

Has the Time Come for Software Cooperative CUs?

As we were departing php[Tek] 2015 last week, I asked my fellow attendees where they were heading. "London," replied Derick Rethans cheerfully, to which I replied with mock seriousness "Ah... that's a long drive." The look of confusion on his face told me that a crucial element was missing from the conversation - he didn't know me well enough to tell that I was joking. Open source is a lot like that. It can be difficult for small businesses in particular, to distinguish between technologies - and technologists - that presented a lasting opportunity, and those that had the potential to fall flat and kill a business model in the process. At php[Tek], as with most of the grass-roots conferences I've attended over the past decade, I recognized an emerging phenomena. It may not be so much a trend as a series of pieces falling into place in the economy and the community at large. Similar to what must have preceded the establishment of Credit Unions in the 1850's, there is an increasingly undercapitalized population relying ever more on applied software technologies. Open Source was a major component falling into place, not merely because it made certain software technologies cheap, but because it democratized access and learning about managing the technologies. Much in the same way, Credit Unions made it possible for individuals and small businesses in impoverished communities not just to self-finance but to learn to oversee and manage their own growth. Regardless of how accountants see software, creating and curating it is a primary factor in the success or failure of modern business operations. Yet even for those that are technologically skilled, the tangible and intangible capital costs can overwhelm the ability of any one business to maintain. Again, Open Source helps by lowering costs and making acquisition of skill levels feasible. Yet even Open Source can present too high a cost of adaptation and configuration management over time. What Open Source does not yet do, and seems to be about to do, is provide a way for neighbors in the technology community - providers and consumers - to secure the future of a software technology together. That is, I think formal cooperatives, or "Software Credit Unions," are about to emerge from the economic primordial soup we call the Market. Many if not most of the core technologies already have found homes in foundations, consortiums, non-profit charities, and public corporations. That's not what I'm pointing out. The applications of these technologies, which provide real value to business process stakeholders, are assets that are frequently constructed with non-trivial personal or business funding. A cooperative form of business would provide pooling of the capital investments, sharing of risks, and amortizing of maintenance costs and risks for members, as well as avoidance of "razing" of small intellectual properties when such small businesses close. If such organizations were formed under the same kinds of fiduciary ethics and practices as a credit union, it would be a boon to the future of technological small business clients and open source contributors alike. It would help define financial and legal standing for popular projects, help quantify the value of contributions, and support necessary but otherwise marginal projects for their members. A cooperative form can also help ensure that peer-review processes (already a part of open source culture) are enforced to members' quality standards and not to requirements of some ill-conceived third party. Software has already irreversibly infiltrated our lives. I don't think it is even possible that cooperatives akin to software credit unions can be avoided. It is happening now. The question is not "if" organizations that hold our software assets will exist. They do now. The question is whether any such organizations will hold a fiduciary role for consumers and producers alike as a membership organization in a credit union model, or leverage us all at a disadvantage like a bank.

Monday, May 4, 2015

Dangerous Domain Vocabularies

A very smart young colleague at work has been introducing us to concepts of CQRS, Event Sourcing, and Domain Driven Design (DDD). One of the more prominent values held by DDD is the pervasive vocabulary used by Domain Experts - ubiquitous language is considered to trump any other technical constructions.

As well it should, at least in established disciplines and where the business actually has resident expertise available. Even where inexperience is greater than the expertise, one still wants the professionals who are tasked with the responsibilities for the business outcomes to have a sense of ownership of the language.

But there are fallacies of belief that can be assumed as well:

  • Belief that a comprehensive domain language exists when it is not even a well formed vocabulary.
  • Belief that the semantics behind nascent language idioms are grounded, when they are cliches or abstractions derived from historical accidents (that is, legacy systems and environmental conditions that no longer exist). 
  • Belief that concepts of a domain model are part of some sort of mathematical reality that objectively exists above our own, unchanging and merely in need of discovery.
  • Belief that the ephemeral quality of language is not a significant factor when individuals move in and out of the domain.
  • Belief that the terrain of the problem space is substantially stable over the expected useful lifetime of the model.
  • Belief that domain experts' language never involves idiosyncratic forms that are self-inconsistent within a single bounded context.
It is the last bullet item that got me to thinking on this topic. A laboratory technician was describing to me a small dispute over a protocol in her lab one day. Two technicians were following two different procedures for diluting liquid samples. The terminology they had adopted was, for instance, to say that they were preparing a "one to three dilution".

It is more commonly expressed as a "dilution ratio of 1:3", and therein lies the problem. One tech said that means mixing one part of a solute to three parts of a solvent, and the other claimed (apparently consistent with the procedures used in the profession) that it means mixing one part solute to two parts solving and giving three parts of an admixture. The vocabulary, having been neglected and forgotten by many of the practitioners, is no longer clear.

Mathematically, the ratio "1:3" is like a fraction 1/3 and most people would think of "one part of something to three parts of something else" at the same moment in time. The lab professionals, meanwhile, have adopted an idiosyncratic interpretation, assigning "1" to the "something" and "3" to "one something plus two something elses" - that is, they compare a variable in a one step to a dependant value resulting from a subsequent step. 

Consider this:
Step 1: take 1 part salt
Step 2: take 2 parts pepper
Step 3: mix salt and pepper

The result of Step 3 is a salt-pepper admixture of roughly three volumes, or a 1:3 dilution of salt in pepper. But mathematically the 1 and the 3 are different units, 1 being a unit of salt and 3 being a unit of (1 salt + 3 pepper). The reality of the process is, further, that the entity described by the 3 doesn't exist until the entity described by the 1 and a derived value for an entity which is not made explicit are combined. That's like telling a cook how to bake a pie with an ingredients list that omits the filling and includes the whole finished pie itself. 

And don't think this is a trivial thing. People have no doubt died over the misunderstanding and confusion brought on by this one shitty little idiosyncrasy.