[size=150]How much does it cost?[/size]
There’s a question I’ve been carrying with me since I started writing code on IBM mainframes back in the late 1970s: how much does a program really cost? Not how much you sell it for, not how much you quote hoping you got it right — but how much the work inside it is worth, and how you measure that in a way that makes sense both to the person who writes it and to the person who pays for it.
Anyone who’s been in this trade long enough has seen at least three eras of answers to this question. And none of them, in my opinion, has ever really worked.
[size=125]The eras of “how we count”[/size]
First era: the line of code. Years ago you were paid by the line. Every program had a price based on the number of instructions — and here’s the first crack already — with a different value for a line of code versus a line of comment. The paradox is obvious to anyone who has really programmed: counting lines rewards verbosity and punishes elegance. The good programmer, the one who solves the same problem with half the code, earned less. You were measuring the weight of the product, not its value.
Second era: time. Then we moved to time: so many hours, so much cost. More honest in principle, but the calculation is still hard. How long it takes me, with forty-five years of experience and a framework I know by heart, is not how long it takes someone else — and it’s not fair that the client should pay for my slowness, nor that I should be penalised for my speed. Time measures the operator, not the work.
Third era: estimation. And here the problem gets even thornier, no matter how deep your analysis goes. Estimating software means putting a price on something that, by definition, doesn’t exist yet. Anyone who works with Agile knows this well: the total “how much to finish everything” estimate is essentially impossible without frozen requirements, and requirements never freeze. So you swing between the padded estimate (out of caution) and the optimistic one that then destroys your margins.
[size=125]The insight: software is made of bricks[/size]
I’ve always been convinced of one thing: a program, a script, is nothing more than a collection of many micro-components suitably connected together. Lots of little Lego bricks that fit into one another.
A data-entry form is not a monolithic block. It’s a base structure — the standard fields — to which you add, one by one, components each with a clearly identifiable weight and value: advanced validation of the entered data, consistency checks between related fields, real-time verification against an external database, autocomplete suggestions while typing, temporary auto-save, duplicate control, document upload with preview and format validation.
Each of these is a brick. Each reflects a specific competence — not a number of hours, nor a number of lines. And so the question becomes: why not build a kind of macro price-list made up of micro-elements?
[size=125]Options: the same brick, many variants[/size]
There’s a second level, and it’s what makes the method really interesting. A brick is never just one thing: it has its options, exactly like a car has the same chassis but different trim levels.
Take the most trivial brick imaginable: a field on a form. In its bare version it’s almost free. But that field can carry a contextual help element (a tooltip, inline help), a visual behaviour that reflects the state of the content (the field turning red when out of range, green when validated), a validation that can in turn be light (format, length) or heavy (cross-check against a database, a call to an external service).
So the same “field” brick doesn’t have a price: it has a base price plus a series of options that add up. This is where the price-list stops being a flat list and becomes a true configurator, where value grows with the competence built in, not with the lines written.
[size=125]The framework paradox[/size]
There’s a reflection I can’t leave out, and it touches anyone who works with a framework — Scriptcase included. The adoption of frameworks has had a double effect, and both sides of the coin have to be looked at together.
On one side they standardised and dramatically sped up development: what once took days of hand-written code today gets generated in a few hours, with uniform quality and fewer errors. An undeniable step forward.
On the other side, though, they lowered and homogenised the perceived economic value, flattening precisely those differences that we were trying to capture with the options. If the framework gives you validation, visual highlighting, contextual help “for free” — if those options are now a checkbox in the tool rather than the visible fruit of a competence — then the client struggles to perceive that they’re worth anything. The brick with all its options fitted seems to cost the same as the bare brick, because producing it costs almost the same.
And this is exactly where the configurator becomes not just an estimating tool, but an act of reclaiming value. It doesn’t matter that the framework made the option easy to fit: what matters is that the option does something more, protects one more piece of data, prevents one more error. The configurator serves to make visible again — and therefore billable — a difference that development speed had made invisible. The framework lowers the cost of production; the configurator defends the value in use.
[size=125]A sample price-list[/size]
The key is to keep the base price of the brick — paid once — separate from the price of each option, which is the pure increment that addition brings. The total for a component is therefore the base plus the sum of the chosen options. The figures below are purely illustrative: they show the mechanism, they’re not a rate card.
BRICK BASE OPTION INCREMENT
--------------------------------------------------------------------------------------
Data field 50 — input only, no control (included)
+ contextual help support 50
+ visual highlighting of content state 100
+ light validation (format, length) 150
+ heavy validation (DB / external cross-check) 550
--------------------------------------------------------------------------------------
Form 1500 — layout, save, navigation (included)
+ automatic temporary save 800
+ duplicate-record control 1200
+ document upload with preview and validation 2000
--------------------------------------------------------------------------------------
Grid 1800 — listing, sorting, pagination (included)
+ advanced multi-field filters 1500
+ export (PDF / Excel / CSV) 1000
+ drill-down to related detail 2200
--------------------------------------------------------------------------------------
Report 2500 — base structure + one grouping (included)
+ each additional grouping / subtotal 800
--------------------------------------------------------------------------------------A worked example: a field with contextual help and light validation costs 50 (base) + 50 + 150 = 250. The same field with heavy validation instead of light comes to 50 + 50 + 550 = 650. The client sees exactly how much each choice weighs, and can reason: “do I really need heavy validation on this field, or is light enough?”. The quote becomes a conversation, not a shot in the dark.
(Figures shown are in generic units — pick whatever currency fits your market.)
[size=125]At estimating time: it already works[/size]
Building a method like this is entirely feasible at estimating time. It’s essentially what we do instinctively when we think about a product: we mentally break it into its pieces. Formalising that process turns an intuition into a price-list. The benefits are concrete: transparency (the client understands what they’re buying), personalisation (they pick only what they need), value recognition (the price reflects what the component does, not the hours I put in), client education (they understand why quality has a cost).
[size=125]The real obstacle: reconciliation[/size]
But here comes the intellectual honesty. At estimating time the brick method is elegant. At reconciliation time? How do I make transparent the real list of the bricks actually assembled, with their variants, and how do I generate a kind of bill of materials for the software — a real BOM, the way it’s done in industrial production?
This is the rock the good intentions crash against. Normal development environments do not help with this at all. They’re born to automate the writing of code, not to account for the work. They give you the what you produced, not the what it’s made of in economically readable terms. And the more advanced environments, the ones that might help you, are often closed: they won’t let you query their internals.
So the estimate remains a promise that the reconciliation can never precisely confirm or deny. And without reliable reconciliation, the brick price-list risks staying a nice theoretical exercise.
[size=125]An environment that describes what it produces[/size]
In my experience, a development environment born to standardise work — where every application is described, catalogued, made uniform — opens up an extra possibility. If applications are described in a structured way, that structure is queryable: it becomes possible, at least in principle, to work back from the artefacts to the bill of bricks that make them up.
I say this with the caution of someone still working on it, not someone with the solution in his pocket. But the direction feels right to me: using the standardisation the environment imposes not only to produce faster, but to make finally measurable what has been produced. The repository that serves to develop uniformly is the same one that can serve to reconcile transparently.
This is precisely where Scriptcase gets interesting — not for marketing reasons, but structurally. Its internal repository, born to make development uniform, is by its very nature a structured, interrogable description of what you’ve built.
[size=125]Not an abstraction[/size]
I’m not speaking in theory. Over the years I’ve built a system of more than 1,200 interdependent applications, and when the time came to put a value on it, I found myself facing every question in this article. How much is it worth? By the line? By time? By estimate?
The sensible answer was none of the three in their pure form. It was to reason by components and by replacement value: not what it cost to write, but what it would cost to rebuild from scratch. A system made of many specialised bricks shows its value precisely when you break it down and realise how many distinct pieces, each the fruit of a specific competence, are inside it. The software bill of materials isn’t just a pricing tool: it’s a tool of awareness, for you before the client.
[size=125]In short[/size]
The problem of how to measure the cost of software isn’t solved — and probably never will be definitively, because software isn’t a physical artefact and every industrial analogy has its limit. But the brick approach seems to me the least bad of those tried so far: it beats the line of code, which rewards verbosity; it beats pure time, which measures the operator and not the work; it makes the estimate a transparent list instead of an opaque total; and — this is the bet — it opens the possibility, where the environment allows it, of genuinely reconciling.
I’m not just theorising it: I’m building a system to manage this problem — one that starts from the brick-and-option price-list for the estimate and tries to close the loop on reconciliation too. It’s a work in progress, with all the limits and doubts that entails, but I’m convinced the road is walkable.
So the question I’ll throw back at you is twofold. Has anyone already tried to build a component price-list — with options, maybe without calling it that — for their own work? And above all: has anyone managed to close the loop on the reconciliation side, generating a real bill of materials for the software produced? The brick estimate, one way or another, most of us do. It’s transparent reconciliation that’s the real unexplored ground — and that’s where I’d love to compare notes with whoever has already got their hands dirty.
[hr][/hr]
Salvatore Roberto Lo Turco — Studio Lo Turco (Italy)