Lies, damn lies and statistics

PoC, PoC, PoC, Production

The hint is in the name people. Proof of Concept. Why is this so difficult to understand? The point of a PoC is to show that a thing can be done, not how a thing can be done. I.e. we don't know something but we have an idea - awesome, I'm here to help. Where I seem to part ways is when the PoC plans to deliver best practice architecture, continuous delivery and push the code & pipelines into production.

Unless the PoCs purpose is those pipelines or new architecture - because we want to prove some new idea about them, then we're doing a disservice to both our PoC and everyone else's. Our PoC because we're not getting to the proof we need cheaply and quickly and everyone else's because we have taught the business, security & compliance what we see a PoC is so other PoCs will have a much higher and unnecessary bar to meet.

Just because we don't understand part of a solution doesn't make the whole solution and it's delivery pipeline a new idea which needs to be proved. Keep a PoC tight (hours and days) and don't conflate it with things that aren't knowable with a little research. A Proof of Concept is a small exercise to test a design idea or validate an assumption.

Actually, I'm well aware that the problem is not one of comprehension. The problem is gaming the system - mind you, there's actually a deeper problem which I'll get to but this one makes me seem like a roadblock rather than part of the solution so ranter gonna rant.

Running an initiative as a PoC gets you past some of the bureaucracy and oversight that would be attracted if running an initiative to production. And, not being a fan of bureaucracy I understand this. However, even though our way of delivering may be flawed, we actually make things worse by getting around some of the early guardrails and trying to use the initiatives momentum to force a consensus on some of the later ones.

"Delivering customer value!" they cry. Bollocks. We deliver true customer value by thinking a little deeper than that. If a bloated PoC was to make things better for a small proportion of our customers by sacrificing quality for the rest, or slows down our cadence of change then it's not customer value. But Semprini you magnificent visionary of technology, how do we know we're scratching an immediate itch but making things worse? Well, this is the whole point of intentional architecture. We keep a PoC limited to validating assumptions & ideas which we then use to inform our solution. Our solution should balance all stakeholders needs, the overall health of our IT & our data plus our next horizon roadmaps - sympathetic treatment of people, process and technology.

Underlying all this is the question: why do people feel the need to do this disingenuous PoC pretense? Or perhaps: How can the organisation change so we don't need to justify this behaviour?

Buggered if I know.

I'm sure you expected me to spout some cliches about collaboration, intentional architecture, rigor and journeys. And so did I, but now I realise that I've tried this from C-level to coal face and it's always the gravity of the technology hype train, the vendor sales machine and Conway's law which is in control of IT. Steering this ship against those currents seems like a Sisyphean task sometimes.

blog comments powered by Disqus