Codes vs Best Pratice: The Grad Match

It’s a sentiment I’ve heard a lot: “Engineers should lose the codes and rely on best practice”. It’s an opinion I’ve only heard advanced by older, potentially wiser, and definitely more experienced engineers. As a graduate I can see the romance in it; harking back to the days of Brunel, where engineers came together, discussed best practice and constructed new towers of research and innovation from humble first principles.

[aside]It would seem that it’s time to rip up the codes and move to the ‘Best Practice’ standard. Arguably, however, the Eurocodes are a little bit of both.[/aside]

Intrigued, I’ve made a note, throughout this week, of design situations I’ve ended up in, and whether a profession of Codes or Best Practice would have served me better.

The ‘New Experience’

When it comes to designing something for the first time, Codes are an indefatigable comfort. Their prescriptive nature essentially, for a given level of ignorance, allows anyone to design something with a degree of accuracy and precision that won’t obviously betray their lack of expertise. And although not strictly true, there is a feeling of security that, after successfully navigating your way through the code, you’ve considered everything you need to consider. This approach especially complements computer based design.

‘Best Practice’ on the other-hand is not a clearly defined quantity. Without access to experience in the field, it would be difficult to know even where to find Best Practice; and the likely fragmentation of documentation would not inspire confidence in the beginner that they have, truly, done the right thing.

[keypoint]For A New Experience: Codes[/keypoint]

The ‘Vigorous Design’

Codes tend to offer two options: The quick method (normally born of experience), where you check what you know will be critical; or the vigorous method where every clause is desperately inspected for leeway and opportunities therein. The focus, however, is always on the ‘What’ and not the ‘Why’; which encourages ‘following’ over ‘thinking’.

Best Practice needs understanding. In my experience documents focused on exchanging practice and knowledge, rather than codification, present research, justification and evaluation. This in turn requires a larger investment in time, but normally yields a better return for the design. For example, the reason I’ve managed to write two (and soon three,) articles on TSI is not because I’ve dug away at the code, but because I’ve needed to read and understand the research behind it and the papers published within the field.

[keypoint]For Vigorous Design: Best Practice[/keypoint]

The ‘Innovative Solution’

Committees write codes, and, as the saying goes: “If you want nothing done, give it to a committee.” This means that design codes are often slow to adapt. You just need to read what is being said about the Eurocode for Geotechnics, to see how easily codes can fall out of sync with the industry, and how hard it is to get them (back) on track.

Best Practice, however, has always been used to plug the gap; be it new technologies, design approaches or construction techniques. Best Practice is also the mechanism that research institutions are able to inject their findings directly into the industry. A shift away from codes entirely, I expect, may well promote research, but how much of that would be shared, and how much would be kept to provide a competitive edge- it’s hard to say, after all; a desperation to share best practice between engineers was what started the ICE.

[keypoint]For an Innovative Solution: Best Practice[/keypoint]

The ‘Design Check’

The unified acceptance, and agreement, of the codes means that anything (theoretically) designed perfectly to a code cannot be significantly disputed by another designer. This is because both parties will be using the same fundamental approach, factors, and criterion. The bodies who author codes also carry significant authority, and the onus is to justify a departure, rather than the use of the code itself.

Best Practice, however, needs both parties to agree that something is Best Practice. This means, that unless both the designer and the checker are fully aware of industry Best Practice within the field, there will likely be some contention, and unlike codes, the authority of the source could even be disputed.

[keypoint]For a Design Check: Codes[/keypoint]

The ‘Value Engineering Exercise’

Codes have to provide general solutions, which by default render them susceptible to conservatism. Typically value engineering is provided in-spite of the code, rather than because of it. Arguably this is because everyone is using the codes, and so more in-depth knowledge or advanced interpretation is needed to design (on a fundamental, rather than scheme, level) anything that provides better value than another engineer.

Best Practice has the potential to provide more specific information, based on focused research and industry experience. As well as providing more current in-sights, it would allow engineers to pick-and-mix information and levels of detail to meet the value/risk relationship that the client is willing to provide; leading to more efficient designs, but requiring more client eduction.

[keypoint]For Value Engineering: Best Practice[/keypoint]

Just scratching the surface, it would seem that it’s time to rip up the codes and move to the ‘Best Practice’ standard. Arguably, however, the Eurocodes are a little bit of both; with a mixture of ‘should’ and ‘must’ and a number of mechanisms for altering the fundamental behaviour of the design.

It is this duality may well explain why neither the inexperienced graduates; who crave prescription, or the seasoned engineers; who want freedom, are all that happy to embrace them. As a graduate, already struggling to get to grips with the extensive body of work that is the Eurocodes, therefore, I’m not quite ready to give up the (somewhat) clear and concise instructions that codification brings just yet.

Perhaps you think differently?