A Strange Question

I was going to write about the next stage of using Excel for modeling events as well as states during requirements.

I wrote the Excel, Python, and such already, before I discovered that the lamp I bought didn’t obey any of my expectations (see Easy and Simple Isn’t if you haven’t already). Modifying what I did already as my understanding of the problem improved isn’t a challenge, but I started to ponder my premises.

1. is an executable requirement a PoC?
2. is a PoC a tool?

What is a tool?

I checked the dictionary … Merriam Webster defines “tool” (in Entry 1, part 2a) as “something (such as an instrument or apparatus) used in performing an operation or necessary in the practice of a vocation or profession.”

For the development of software, common tools are:

1. editors (and no, I’m not so foolish as to promote one)
2. compilers
3. interpreters
4. version control systems

Those aren’t our only tools, though. What good is an interpreter or compiler without a programming language? I have asserted before that programming languages are tools. They are necessary in the practice of our vocation.

Is Stack Overflow a tool? If references about materials are tools for engineers, than references about programming would be tools for developers. So, yes, Stack Overflow is a tool.

However, things start to get blurry when you delve deeper. Is a library a tool? It may very well be needed for the practice of our vocation. At the same time, it’s part of the resulting work — libraries are present inside the developed software when it’s deployed.

To the person writing the library, it’s not a tool. It’s a deliverable — it is released to someone for use. This is also true for the person writing a compiler or an editor.

Our industry is strange: our tools and our deliverables are the same “stuff.”

The PoC and the Minimum Viable Product (MVP)

And that comes back to the PoC — and the MVP.

A PoC is clearly an executable result of software development. It’s a program to its author. To the consumer of the PoC, though, it’s one of their many resources to build their system.

But how does that differ from an MVP? Oddly, the distinction is critically important, so much so that I use an evil trick:

NEVER write a PoC in a language that can be deployed by the product team that uses it.

The purpose for a PoC is to be referenced, not to be shipped.

If the intent is to build something small and add to it until it’s sufficient, that’s building an MVP. There’s nothing wrong with building an MVP. On the contrary, making a larger working system from a smaller working system is smart.

But the PoC can’t be an effective PoC if it addresses production needs. And an MVP that doesn’t address production will fail to deliver in production.

I used Python for PoCs in Java projects. The Python PoCs had no error detection and recovery, couldn’t be scaled, had no integrated test suite, and weren’t code reviewed. The PoCs allowed input to generate output — all command-line (no web-pages, no API, etc.).

For example, I built a POC to show a bitemporal attribute storage engine running on top of key/value pairs (using a Python in-memory dictionary with no IO). It allowed the validation of the bitemporality of the data, the performance characteristics (not by measuring time, but by measuring access counts), and showed that algorithmically it was possible.

It also indicated a serious weakness: it’s not efficient to search bitemporal data stored in a key/value store by value. We suspected it, but this PoC made it very clear — it was inefficient to the point of absurdity to scan the values to achieve SQL like general query. It was limited in functionality to “given an object’s unique key and optional set of bitemporal constraints return the object and it’s changes over that time.” That was it: pure primary-key access only.

It was decided by the team’s leadership that the only need was in support of primary key access and they chose to use Apache Ignite backed by MariaDB to provide persistence. And it worked — for primary key query given bitemporal constraints.

The very first change request was for full support of generic query. Unfortunately, As the PoC had shown, this couldn’t be done in a performant way.

A brilliant engineer spent many hours with SQL tricks on the underlying database trying to achieve it, but adding in all the logic to store “enough data” for the optimizer to work killed the primary key writing performance.

It was the wrong solution for the problem — and with much howling it was scrapped. And it was right to have been scrapped.

Had the PoC not been done, but Apache Ignite simply baked into the MVP under construction, it’s unlikely that Ignite would have been “hidden” behind an abstraction. After all, it would now have been part of the toolkit. That would have made scrapping the implementation of that abstraction difficult. This is the downside of an MVP: it accumulates many warts in the rush to market. And it will have to be maintained, and evolved.

The PoC is built, used to achieve some specific purpose, and then it’s done. It’s not maintained over time. Any work based on the lessons learned will be what goes forward. Often, the lesson learned is “Do not do this.” That’s a good lesson to accept.

The MVP is an integral part of the code base going forward. Mistakes made are lived with, possibly for years, possibly forever.

Questions Answered

The PoC seems to be a tool. Whether it’s part of the requirements (such as my Excel examples) or part of the engineering simulation/evaluation process it’s used by the team to make decisions that will affect the product.

If a requirement is executable, it would have all the characteristics of a PoC: it would convert inputs into outputs and it would be referenced and not shipped.

It is not necessary for a client to be able to write an executable requirement — but they must be able to freely run it and alter the data fed to it. It’s not necessary for a client to write prose requirements either, so this isn’t a weakness.

A PoC doesn’t have to be part of a requirement, but an executable requirement is absolutely a PoC. And a very powerful tool for the team when it’s available.

Keep the Light,
Otter
Brian