Reality Always Gets a Vote
Why the biggest engineering challenges are often the ones nobody discussed in the concept meeting
Most technology-development plans begin with a reassuring assumption: that development is primarily a process of solving technical problems.
A concept is created. Simulations are completed. Testing validates the design. Detailed engineering follows. Hardware is manufactured, deployed and ultimately operated. The process appears logical, controlled and predictable, providing a useful framework for project planning and helping teams explain where they are, what comes next and how they expect progress to unfold.
The difficulty is that technologies rarely succeed or fail because of a single technical problem. More often, success depends on a growing network of assumptions relating to manufacturing, deployment, access, maintenance, logistics and operation, many of which remain largely invisible during the early stages of development.
What appears straightforward in a concept presentation can become significantly more complicated once a technology begins interacting with the practical realities of fabrication, installation and operation. The challenge is not that engineers overlook these realities entirely, but that they often emerge later, and with greater influence, than anyone expected.
One of the themes explored by Blackfish
Operations Director Tim Warren during ICOE-OEE 2026 was the difference between how technology development is often presented and how it actually unfolds in practice. While development plans naturally focus on the major technical milestones, the reality is usually far more complicated. Progress rarely follows a neat sequence from concept to deployment. Instead, it emerges through a continual process of
learning, adaptation, compromise and, occasionally, the discovery that the most
important challenge was not the one anybody thought they were trying to solve.
Engineering is often described as a process of finding solutions. In reality, it is just as often a process of discovering which assumptions survive contact with the real world.
How confident are you in the assumptions underpinning your design?
Learn how Blackfish supports technology developers through analysis, verification and validation.
The Comfort of Straight Lines
There is a good reason development plans are usually presented as linear processes.
Linear plans are easy to understand as they help secure buy-in from stakeholders and provide confidence that progress is being made. They also allow projects to be broken into manageable stages, each with its own objectives, milestones and deliverables and they give the impression that engineering is simply a matter of working through a sequence of activities until the final answer emerges.
Most experienced engineers know that reality rarely cooperates.
A simulation may challenge the original concept. Test results may force a rethink of the simulation. Manufacturing realities may prompt changes to the detailed design, while operational requirements may expose assumptions that nobody considered during the concept phase. Every stage generates information that influences decisions made elsewhere.
Rather than progressing cleanly from one stage to the next, development often resembles a network of feedback loops. Information travels backwards as often as it moves forwards. Questions that appeared settled return for further discussion. Designs evolve as understanding improves.
"Nothing is agreed until everything is agreed."
At first glance this sounds like a comment about process, but in reality, it is a comment about complexity.
Engineering decisions do not exist in isolation. They interact with manufacturing, operations, logistics, maintenance, deployment and commercial realities. A decision that appears sensible when considered alone may become problematic when viewed as part of the wider system.
The further a project progresses, the more visible these interactions become.
The Challenge Nobody Put in the Concept Drawing
One of the more interesting observations from Tim's presentation was that engineering projects rarely encounter difficulty because people have overlooked the thing everyone was actively discussing.
More often, trouble emerges from something sitting quietly in the background.
A structure may meet every design requirement or a control system may perform exactly as expected, hydrodynamic performance may even align beautifully with the original modelling, and yet the project can still encounter significant challenges.
The reason is that technologies do not exist in simulations, technical reports or concept renderings. They exist in the real world, where they must be manufactured, transported, assembled, installed, inspected, maintained, recovered and eventually replaced.
Those activities introduce constraints that are often less visible during the concept phase but no less important.
One example Tim shared was deceptively simple.
Can the quayside actually withstand the loading imposed by the device?
"Nobody develops a new technology because they're excited about quayside load calculations."
It sounds almost trivial until you realise what the question represents. Yet questions like this have a habit of influencing programmes in ways that nobody anticipated during concept development. The further technologies move towards deployment, the more frequently practical realities begin shaping decisions that were originally driven by engineering.
It is not the sort of question that tends to dominate the early stages of design. It is unlikely to appear in the first concept sketch. It rarely forms the centrepiece of a funding proposal. Yet questions exactly like this have a habit of becoming extraordinarily important later in development.
What makes questions like this so interesting is that they often have very little to do with the technology itself. The structure may be sound, the engineering may be correct and the innovation may be performing exactly as intended, yet the project can still encounter significant difficulties because the challenge exists somewhere else entirely.
It may emerge through a transport restriction that limits how the device can be moved. It may emerge through infrastructure that was never designed for the loading involved. It may emerge through maintenance requirements that appear entirely manageable during design but become much more demanding during operation. In each case, the technology has not necessarily failed. Rather, the wider system surrounding it has begun revealing assumptions that nobody realised they were making.
This is one of the reasons engineering development can be so difficult to predict. Projects are rarely constrained by a single issue. They are constrained by the interaction between many issues, some of which only become visible once development has progressed far enough for reality to expose them.
Hidden assumptions rarely announce themselves early. More often they wait until significant decisions have already been made, budgets have been allocated and programmes have gathered momentum. By that stage, the challenge is no longer simply understanding the issue but understanding how much it will cost to respond to it.
That is one of the realities of technology development. Success is not determined solely by whether a piece of engineering works. It is determined by how that engineering interacts with a much larger system of practical constraints.
Identifying hidden constraints early is often far less expensive than discovering them during deployment.
Why Iteration Is Not Failure
The word iteration sometimes carries an unfair reputation.
Projects are often praised for avoiding redesign and criticised when earlier decisions have to be revisited. Development plans are written to minimise rework and maintain momentum. Iteration can therefore feel like evidence that something went wrong.
In reality, iteration is usually evidence that learning is taking place.
Every significant technology programme begins with imperfect information. If engineers already knew everything they needed to know, there would be little point in conducting simulations, building prototypes or running test campaigns. The purpose of development is to improve understanding.
As understanding improves, decisions change. That is not usually a sign of failure; more often it is a sign of progress. The challenge is not to eliminate iteration entirely. The challenge is to ensure that important lessons are being learned while change remains affordable. A concept sketch can be revised relatively easily, but detailed engineering takes longer, and manufactured hardware is harder still. The further a programme progresses, the greater the consequences of discovering something that should have been understood earlier.
The most successful development programmes are rarely the ones that avoid iteration entirely. More often, they are the programmes that discover important lessons while they still have the freedom to respond. The challenge is not avoiding change. It is ensuring that reality begins influencing decisions before those decisions become expensive to revisit.
The earlier teams can validate assumptions, the less expensive change becomes. Our recent article on the validation gap explores this challenge in more detail.
Death, Taxes, Rust and Slime
The second half of Tim's presentation shifted towards a topic that every marine engineer eventually encounters.
Corrosion and biofouling...
Most people know the saying that the only certainties in life are death and taxes.
Tim suggested that marine engineers should probably add rust and slime to the list.
The humour landed because it contains a truth that every experienced marine engineer eventually encounters. Corrosion is not a possibility that may or may not occur. Marine growth is not a risk that can simply be ignored. Given enough time, both become inevitable consequences of placing equipment in the marine environment.
The marine environment does not care how elegant a design looks in CAD or how promising a simulation result appears in a report. It introduces its own requirements, constraints and behaviours, regardless of whether they featured prominently in earlier discussions.
What makes this particularly interesting is how rarely these realities dominate concept-stage conversations.
Very few concept-stage discussions revolve around coating systems, drying times, access constraints or the realities of maintaining large structures in harsh marine environments. Understandably, attention is usually focused on innovation, performance and proving that a technology can work. Yet many of the practical challenges that ultimately influence reliability, maintenance requirements and operating costs originate in these less glamorous realities. As Tim remarked during the session, "Nobody had this in mind during the concept stage." The observation was made in the context of corrosion and biofouling, but it could just as easily be applied to countless other issues that only become visible once a technology begins interacting with the real world.
The challenge is not that engineers are unaware of corrosion and marine growth. During concept development, attention is naturally focused on innovation, performance and proving a technology can work. As projects move closer to deployment, these practical realities become impossible to ignore, often exerting a far greater influence on reliability, maintenance requirements and operating costs than many teams initially anticipated.
Looking at Real Deployments
One of the simplest recommendations from the presentation was also one of the most valuable: spend time looking at real deployments.
Not just the concept renderings, animations and idealised design studies that exist during development, but the hardware that has actually been deployed, operated and maintained in the field. Those assets tell a story that design reviews and simulations often cannot.
There is a tendency in engineering to spend significant amounts of time discussing how systems are expected to behave and comparatively little time studying how deployed systems actually do behave.
Real deployments provide an important corrective. They reveal maintenance challenges that were not obvious during design. They expose practical constraints that did not appear in modelling. They demonstrate how equipment ages, how marine growth accumulates and how operations unfold in practice rather than theory.
Looking at real deployments is therefore less about finding mistakes and more about improving understanding. It helps bridge the gap between engineering intention and operational reality.
Real-world observations often challenge the assumptions built into engineering models. Understanding that relationship between prediction and reality is a recurring theme throughout technology development.
Every Industry Has Its Own Version of Rust and Slime
Although Tim's examples came from offshore renewables, the underlying lesson extends well beyond ocean energy.
Every industry has its own equivalent of rust and slime. For some organisations, it is a manufacturing constraint that only becomes apparent during production. For others, it is a maintenance challenge discovered during operation, a certification requirement that reshapes a design, or an infrastructure limitation that nobody considered during concept development.
The specific details vary enormously, but the pattern remains remarkably consistent. The factors that ultimately determine success are not always the factors attracting the most attention at the beginning of a project. Reality has a habit of changing those priorities. The challenge is not that corrosion, biofouling and maintenance requirements exist. The challenge is that they often arrive later than teams expect and with far more influence than anyone anticipated during concept development.
Reality Always Gets a Vote
Perhaps the most important lesson Tim discussed is that technology development is not really a process of taking an idea and turning it into reality. It is a process of allowing reality to improve the idea.
Every technology begins as a collection of assumptions.
Some are explicit. Performance targets, operating conditions and design criteria are usually documented, discussed and reviewed throughout development. Others are far less visible. Assumptions about maintenance, logistics, deployment, infrastructure and operation often remain implicit until reality forces them into the conversation.
The objective of technology development is not to eliminate uncertainty altogether. That is rarely possible. Instead, the aim is to expose assumptions early enough that they can still influence the design and improve the outcome.
This is why Tim's observation feels relevant far beyond the examples discussed during the presentation:
"Nothing is agreed until everything is agreed."
Not because engineers are indecisive, but because technologies do not operate in isolation. They exist within a wider system of practical constraints, environmental realities and operational considerations that must eventually be confronted.
The most successful projects are not necessarily those that avoid surprises altogether. More often, they are the projects that encounter important surprises while they still have the opportunity to respond.
Because no matter how elegant the concept, how sophisticated the simulation or how carefully planned the programme, reality eventually provides feedback.
The challenge for engineering teams is ensuring that reality's feedback arrives early enough to influence the design rather than after it has already become expensive.
After all, reality always gets the final vote.
Download the Presentation
Tim's ICOE/OEE 2026 presentation, "Lessons Learnt from Design", explored the realities of technology development beyond the neat process diagrams we often use to describe it.
Through practical examples from marine energy projects, the presentation examines why engineering is rarely a linear journey, how hidden constraints emerge throughout development, and why factors such as manufacturing, deployment, maintenance, corrosion and biofouling can have a far greater influence on project outcomes than many teams anticipate during concept design.
Download the presentation to explore Tim's original insights into design iteration, real-world deployment challenges and the principle that:
"Nothing is agreed until everything is agreed."
At Blackfish, much of our work centres on helping clients identify and challenge critical assumptions before they become expensive project risks. Through analysis, verification, validation, testing and independent technical review, we help organisations build confidence in the decisions that ultimately shape project success.
If you're developing a new technology, planning a test programme, or trying to understand how real-world constraints might influence your design, we'd be happy to discuss the challenge.
Comments