What C++ can teach quantity surveyors about building an international standard

Watching a documentary about the history of C++ recently, I expected it to bring back an old interest in programming. It did, although not simply as nostalgia. Code has quietly returned to my daily working life through Codex and other AI tools. I now use them often enough that questions about how instructions are written, interpreted and checked sit much closer to quantity surveying than I would once have expected.

My interest in programming started at around ten years old, when I somehow managed to get hold of a home computer and began working out what it could do. I later found a small Grand Theft Auto multiplayer modding community, long before the current GTA Online, where people created their own game modes, custom maps and missions. Taking part meant learning an obscure coding language through forum posts, copied scripts and a great deal of trial and error. I would change a few lines, try to compile the script, see what failed and then work backwards until I understood enough to make it run.

That experience made game development seem like the obvious path after school. I managed to enter a university course in the subject, but the reality was nothing like I had imagined. The course felt disordered, the curriculum appeared to be changing while my year was moving through it, and some of the teaching was frankly poor. The route into the games industry also seemed narrow from the outside, particularly for someone without an existing connection to one of the small number of established studios. After the first year, I left and made the rather more sensible move into quantity surveying.

What I had not recognised at the time was that the part I enjoyed was not game development alone. I liked taking a large system apart, learning the rules that governed it and then using those rules to produce a result. Quantity surveying required much of the same thinking, although it applied it to drawings, specifications, quantities, cost and contracts rather than virtual worlds.

Contract review later made the connection clearer. Code and contracts both depend on defined terms, sequence, cross-references, conditions and exceptions. A statement can be correct in form yet still produce an outcome that was not intended. One word can alter how the rest of a clause or function is read. Writing either code or contract wording therefore requires more than knowing the vocabulary. It requires you to think about how another person, or another system, will interpret what has been written.

The C++ documentary added a further question. Quantity surveying already has recognised methods of measurement, professional guidance and a growing range of digital tools. What it does not yet have is a single international standards process for detailed measurement and bill data that works in the way C++ moved from working practice to a maintained ISO standard.

The growing use of AI makes that question more urgent. If measurement practice remains divided between company templates, local customs, private data structures and software-specific rules, AI will not resolve those differences by itself. It may simply reproduce them more quickly and at a far greater scale.

The rules behind the code

When I first learnt to write simple scripts, I treated the language as though its rules had always existed. I did not ask who had chosen the words, brackets or punctuation, why one instruction was valid and another was not, or how different software tools could agree on the meaning of the same text.

A programming language is a formal agreement. Its syntax sets the forms that may be written, while its semantics sets what those forms mean. A compiler reads the source code, checks it against many of those rules and converts it into something that a machine can execute. Different organisations can produce different compilers, but a common standard gives them a shared target. The ISO standard for C++ states requirements for language implementations and, through those requirements, defines the language itself.

The standard does not need to prescribe every internal step taken by each compiler. It sets the behaviour that users should be able to rely upon. Software firms remain free to compete over performance, tools, interfaces and ease of use, while the meaning of valid C++ remains broadly dependable across their products.

AI does not remove the need for this agreement. Tools such as Codex can read and edit files, run commands and tests, and present the results for human review, but they still work within the rules of the programming languages, repositories and test systems they are given. Their ability to produce code rests partly on the existence of formal languages and repeatable tests against which their work can be checked.

This has a direct bearing on quantity surveying. AI may be able to read drawings, identify objects, suggest classifications, write bill descriptions or produce first-pass quantities. The harder question is what counts as a correct result. Without a shared measurement specification, the answer may become whatever each company has placed in its prompts, templates, internal guidance or software configuration.

The distinction between the rule and the tool therefore matters. A take-off platform is not the method of measurement, just as a compiler is not the programming language. An AI system is not the commercial standard merely because it can produce a bill. Each is a means of applying instructions that must first be stated and agreed.

From working practice to a living international standard

C++ did not begin as a finished international specification. It grew from practical use, gained users, attracted different implementations and then required a formal means of reaching agreement. ISO/IEC JTC 1/SC 22/WG 21 became the international working group responsible for C++, and the first edition of ISO/IEC 14882 was published in 1998. Later editions followed as the language changed, faults were corrected and new work became ready. WG21 continues to publish working papers and drafts, while ISO published the seventh edition of the standard in 2024 and is already working on its replacement.

The importance of this history is not that ISO invented the language. C++ already existed and was widely used. The standards process gave its users, language designers and compiler writers a recognised way to propose changes, debate wording, test ideas and decide what should form part of the next published edition.

The documentary’s discussion of the convener was especially relevant. A convener is not expected to design every feature personally. ISO working groups operate through experts and report to their parent committee through a convener, whose work includes seeking consensus, keeping the programme within scope and progressing work against agreed target dates.

This role matters because standards can stall even when good technical ideas exist. People disagree over scope, wording, compatibility and timing. Someone must keep the process moving without turning the standard into a personal product.

The train model provided the second important lesson. Rather than holding an entire edition until every proposed item was ready, the committee worked towards a known release. Work that had reached the required standard could board the train. Work that remained uncertain stayed off and continued towards a later release. WG21 papers still use this train model when planning standards work.

The principle is simple. A standard can be incomplete and still be useful. In fact, it may remain useful because it is published and reviewed regularly rather than delayed in search of a final, perfect answer. Mature work enters the next edition, unsettled work remains open, and users know that another release is planned.

Alexander Stepanov’s work offers a related lesson. His approach to generic programming focused on writing reusable algorithms around the operations they truly required, rather than tying each algorithm to one particular arrangement of data. The Standard Template Library brought reusable algorithms and data structures into the draft C++ standard.

For quantity measurement, the comparison is useful. A rule for measuring finishes, concrete, formwork or excavation should not depend on one software product or one consultancy spreadsheet. It should state the information it needs, the operations to be carried out and the result that must be produced. Any suitable tool should then be able to apply the rule and demonstrate that it has done so correctly.

Quantity surveying has rules, but not one international specification for detailed measurement

Quantity surveyors are not starting from nothing. RICS describes NRM as a standard set of measurement rules and guidance for construction cost management, with NRM 2 dealing with detailed measurement for building works. CESMM sets out how civil engineering bills of quantities should be prepared, priced and measured.

ICMS addresses a different level of information. It provides a high-level structure for classifying, defining, measuring, recording and presenting life-cycle costs and carbon data. Its own published guidance makes clear that it does not replace detailed local methods of measurement.

These standards solve valuable but different problems. Detailed methods state how particular work should be measured. International cost standards support comparison and reporting at a higher level. Classification systems organise information. BIM standards help data pass between systems. What remains missing is an international specification for the detailed commercial meaning of a quantity and for the evidence that should accompany it.

The present ISO committee structure shows part of the gap. ISO/TC 59/SC 13 deals with the organisation and digitisation of built-environment information, including the exchange of structured and object-related data. ISO/TC 59/SC 18 covers construction procurement, but its stated scope expressly excludes methods of measurement associated with bills of quantities. Detailed measurement therefore sits close to several existing areas of standards work without being clearly covered by one of them.

There are already useful examples of how an open technical standard can work in construction. Industry Foundation Classes provide an open, international and vendor-neutral description of the built environment. The Information Delivery Specification allows information requirements to be written in a form that people can read and software can check automatically.

These examples do not solve detailed measurement, but they show that construction can create open specifications that are shared across software platforms. Quantity surveying should follow a similar path rather than allowing each take-off provider or consultancy to create its own closed interpretation of measurement data.

An international measurement standard should not discard NRM, CESMM or other recognised methods. Those documents contain many years of professional knowledge and are linked to local market and contract practice. The aim should be to create a common base beneath them, allowing each method to retain its rules while expressing quantities, sources, classifications and rule references through shared fields and published mappings.

The result would not be one identical bill for every country. It would be a common way of stating what a quantity means, how it was formed and which rule governed it.

Why AI makes the question urgent

Using Codex and other AI tools in my daily work has changed the way I think about this issue. AI can make technical work more accessible to people who are not full-time software developers. It can help translate an idea into code, inspect an unfamiliar set of files, test a change and explain why something failed. That brings back part of the early appeal I found in programming, but with a far lower entry barrier.

It also makes the quality of the rules more important. An AI system can work quickly with a clear specification, but speed is not the same as agreement. If two firms define the same measurement term differently, AI can produce two conflicting outputs much faster than people could produce them manually.

RICS research published in 2025 found that 67 per cent of quantity surveying and construction respondents believed AI would help surveyors provide greater value. The same research identified poor data quality and difficulties between systems as major barriers to wider use, while only a very small share of organisations had applied AI across their projects at scale.

RICS has since brought a professional standard for responsible AI use into effect, with requirements covering governance, professional judgement, oversight, transparency and client communication. These are necessary controls, but they do not answer the measurement question by themselves. Responsible AI use still requires a dependable professional rule set against which an output can be reviewed.

My concern is that the industry may respond to AI by increasing fragmentation. Each major contractor, consultancy and software supplier may create its own measurement schema, naming rules, prompt library, object mapping and checking process. Those systems may work well within the organisation that created them, but the market could end up with dozens of private commercial dialects that cannot be compared without another layer of translation.

AI could then make the walls between firms higher rather than lower. A quantity prepared by one system may not carry the same meaning when it enters another. Clients may receive apparently precise outputs that depend on hidden instructions. Smaller firms may be forced to follow the private structure of whichever platform or consultant controls the data.

This is why companies and consultancies need to work together in good faith more than ever. Not every commercial method or internal dataset must be public. Firms will rightly protect their rates, productivity records, risk models and commercial knowledge. However, the meaning of a measurement rule, a source reference, a deduction, a quantity state or a bill item should not be treated as private intellectual territory.

Software suppliers should compete over the quality of their products, the speed of their tools and the service they provide. Consultancies should compete over judgement, advice and the quality of their people. Neither group benefits in the long term from a market where the same construction quantity carries a different hidden meaning in every system.

What an international measurement standard should define

The proposed standard should not be another book of item descriptions alone. It should define a common commercial data model that can be read by quantity surveyors and applied by software.

A quantity record should identify what was measured, where it was measured, the source drawing or model, the relevant revision, the unit, the classification, the measurement rule and the edition of that rule. It should record whether the quantity is gross or net, measured or provisional, system-produced or manually adjusted. Where deductions, waste, laps, openings or rounding apply, those decisions should be visible rather than buried inside a spreadsheet formula.

Measurement operations should be stated without tying them to one product. A wall finish rule, for example, could define the required surface, boundaries, opening treatment, unit, rounding method and classification. Different software tools could present those inputs in different ways, but a compliant tool should be able to show that it used the declared rule.

The standard should include a machine-readable form as well as written professional guidance. Rules, terms and data fields should have stable identifiers, allowing systems to exchange their meaning without depending on identical display wording. Existing methods could then map their requirements to the common structure while retaining any national or sector-specific differences.

Reference cases would be just as important as the written text. A set of sample drawings, models and measurement questions could be issued with expected outputs and stated tolerances. Software suppliers, consultancies, contractors and universities could run the same cases. A claim that a product or process follows the standard would then be supported by published tests.

This is where the comparison with programming languages becomes practical. Code is tested against expected behaviour. A measurement system should also be tested against known cases, including awkward examples where deductions, mixed descriptions, revisions or incomplete source information are involved.

AI-produced quantities should meet the same test. The fact that a result was generated by an AI agent should not reduce the evidence required. If anything, the source trail should be stronger. The record should show what information the system used, which rule it applied, what assumptions were introduced and where a quantity surveyor reviewed or changed the result.

A system that cannot state which measurement rule it followed should not be described as compliant simply because its final bill looks familiar.

Versioning would also be essential. Each project should record the standard edition and rule version used. When a rule changes, the change log should state what changed and why. Historic quantities should remain capable of being read and checked against the edition that applied when they were prepared.

A standards process, not a commercial product

Creating the standard would require more than technical writing. It would require a recognised international programme, a defined scope, open working papers, published consultations, reference cases and a route for national bodies to comment and vote.

There is already evidence that international co-operation of this kind is possible in commercial management. The ICMS Coalition brings together organisations from around the world around one shared international cost standard, while its third edition was prepared by an independent committee of experts from several countries. ICMS is not the detailed measurement standard proposed here, but its governance offers a useful precedent.

Quantity surveying institutions, contractors, consultancies, clients, software firms, universities and public bodies would all need to take part. No single consultancy, professional institution or technology supplier should own the meaning of the standard. Private interests will always exist, but the process should require participants to separate what genuinely needs to remain commercial from what must be shared for the market to function.

The first edition should be deliberately limited. It might cover terminology, units, quantity states, source references, rule identifiers, a common data structure and a small set of test cases. It would not need to settle every trade, every local custom or every procurement route before publication.

The train model would suit this work. A fixed release pattern, perhaps every two or three years, would allow mature proposals to enter the next edition while disputed or untested work remained open. The standard would stay useful because work would continue rather than because one edition claimed to be final.

The convener would also be important. The role should be to protect the agreed scope, keep the timetable moving, ensure competing views are heard and record how decisions were reached. The convener should not own the content or act as the representative of one company’s preferred system.

Good faith would be tested most when a shared rule conflicts with a firm’s present commercial advantage. Some organisations will have spent years building private templates and software. Joining an open standards process may appear to give away part of that work. Yet a common base does not end competition. It allows firms to compete above the level of basic meaning rather than wasting time translating between incompatible structures.

The alternative is a market in which each company builds its own AI system around its own commercial language. That may appear attractive in the near term, but it risks locking clients and projects into closed systems while making industry-wide comparison, assurance and learning more difficult.

Another way back to programming

I did not become a game developer, and for a long time I thought programming belonged to an earlier part of my life. In hindsight, it may have prepared me to notice a problem in quantity surveying from a different angle.

Learning code through forums taught me that written instructions only work when their form and meaning are accepted by the system reading them. Contract review later showed me how much can turn on definitions, order, exceptions and cross-references. Using Codex and AI today has brought those two experiences together, because I can now see both the power of formal rules and the speed with which machines can apply them.

The history of C++ adds the institutional lesson. A technical language does not become dependable merely because it is useful. It needs a published specification, a recognised group to maintain it, a convener who keeps the process moving, open debate, reference tests and a release model that accepts progress without waiting for perfection.

Quantity surveying has already completed much of the difficult professional work through its established methods of measurement. The next step is to place that knowledge within an international structure suited to digital take-off, bill production and AI-assisted commercial work.

The profession now faces a choice. AI can be built on shared terms, open rules and testable outputs, or it can be built on a growing collection of private company dialects. The first path would allow different tools and firms to work from the same declared meaning. The second would deepen the fragmentation that already exists.

The useful lesson from C++ is not that quantity surveying needs more rules for their own sake. It is that rules become dependable when they are maintained through a trusted process, expressed in a form that both people and machines can use, and supported by another train already scheduled.

The next train should carry an international standard for detailed measurement and bill data. Quantity surveyors should help decide what boards it.