Insights
Publications from the Jaewa team: articles on uncertainty, collaboration models, ethics and transparency, technical insights, and case studies.
Measuring progress instead of activity
Several years ago, TDD arrived: Test Driven Development. The underlying idea was simple: the number of errors that a compiler, even the best one, can find in software is tiny compared to the problems that emerge at runtime, when the system is actually being used.
The proposal behind TDD was apparently trivial: in addition to application code, write test code as well, meaning software that automatically runs other software to verify that it behaves as expected, and to catch bugs before they reach real users.
Author: Valeriano Sandrucci
In software, collaboration is an engineering necessity as well as an ethical value
At Jaewa, we have spent years working on system integration, legacy software reengineering, distributed architectures, and the development of tailored solutions. We work with structured companies, SMEs, internal products, critical operational platforms, and ecosystems in which various systems have accumulated over time: a variety of contexts that makes it necessary to compare similar problems seen from different angles.
From the experience gained across this variety, a recurring fact emerges: software problems rarely originate in the code itself, but much more often in unspoken ambiguities, incompatible expectations between parties, unclear responsibilities, and, above all, in a poor relationship with uncertainty.
Author: Valeriano Sandrucci
The problem is not the contract model, but the uncertainty we pretend not to see
In the world of custom software, many discussions always begin and end in the same way: “Is a fixed-price project better, or Time & Material?”
It is an understandable question. But it is also, almost always, the wrong question.
The point is not really the contract model itself. The real issue is who takes on the risk of uncertainty, and whether that distribution of risk is coherent with the reality of the project. When this coherence is missing, the project begins to struggle before the first line of code is even written.
Author: Valeriano Sandrucci
An analysis project is not meant to understand everything
The word analysis has an ambiguous reputation in software development. It evokes long documents, waterfall approaches, weeks of work without code, and the widespread feeling of paying for something that produces no immediate value.
Clients often perceive it as an unproductive cost: they pay for working software, not for reading diagrams. Even among developers, analysis is sometimes seen as an obstacle. Code appears to be the only activity that truly matters, while everything else feels like an intermediate step of questionable usefulness.
Author: Valeriano Sandrucci
Why a prototype is not necessarily a reduced version of the final product
“Let’s build a prototype” is one of the most common phrases in software projects. The problem is that it often means different things to different people.
For some, it means building a smaller version of the product: fewer features, less refinement, but already intended to evolve into production. For others, it represents a space for experimentation: testing a technology, writing code quickly, and observing what happens.
These two interpretations imply very different goals, timelines, and success criteria. When they are confused, the result is often the same: wasted time, diverging expectations, and more uncertainty instead of less.
Author: Valeriano Sandrucci
In critical systems, flexibility is a requirement
In dynamic systems theory, effective control is not based on perfect prediction, but on feedback. You observe the system’s behavior, measure the deviation from the objective, and introduce progressive corrections. The goal is not to anticipate every possible disturbance, but to build the ability to react.
Software development in critical environments follows a similar logic.
Author: Valeriano Sandrucci
Saying no is part of our job
In software, saying no is not an act of resistance. It is an act of responsibility.
We would always like to say yes. It is natural: projects are the engine of our business, and accepting them is almost always the easiest path, sometimes also the most profitable in the short term. But it is not always the right thing to do.
In technical consulting there is a widespread temptation: accommodating everything. You can accommodate a fragile idea, a roadmap built on unverified assumptions, a technical conviction that does not withstand deeper analysis, or the request to add a temporary workaround to a system that actually needs to be reconsidered.
Accepting under these conditions requires little effort. Refusing or reframing requires competence, method, and a precise idea of what engineering should mean.
Author: Valeriano Sandrucci
Let us start from a simple diagram. On the horizontal axis (X) we represent the complexity of the software problem to solve. On the vertical axis (Y) we represent cost, meaning the effort required to build a software solution.
The scientific community agrees on one point: as problem complexity increases, the effort required to solve it also increases. This growth is not linear. In many cases it is more than proportional, and in some situations it can even become exponential.
Author: Valeriano Sandrucci
Artificial intelligence and uncertainty in software projects
In recent years, artificial intelligence has become one of the most discussed technological topics. It is not difficult to understand why: it has the potential to profoundly change the way we live, work, and develop software.
At the same time, the spread of AI has generated a recurring phenomenon: the illusion of certainty. Many organizations look for definitive answers on how to adopt it, as if there were already stable and universally applicable models.
Author: Valeriano Sandrucci