Pragmatism doesn't mean reckless trial-and-error

When I finished my studies at university, I was eager to apply my technical knowledge in a real life context. And I confess that the very first contact with the crazy pace of job market was a bit shocking. At the time, as a purist, I incorrectly thought that using a pragmatic approach to solve a problem was akin to being reckless or irresponsible, which could only result in providing a sub-optimal solution. Later with experience it was eventually discovered that by wisely discarding parts of my theoretical knowledge it was possible to arrive more quickly at simpler solutions, without necessarily losing robustness.

According to Oxford dictionary, a purist is “a person who insists on absolute adherence to traditional rules or structures”. Also, it defines pragmatist as “a person who is guided more by practical considerations than by ideals”. This text intends to show that a purist approach can be relaxed and “more practically guided” still delivering successful solutions. This will be illustrated by a few examples in software and engineering contexts, but the technical details will be presented as lightly as possible so the reader from other fields can apply the examples to their own situations.

Would Physics equations from 1687 to 1905 be wrong?

In 1905, Albert Einstein proposed the ideas of his Special Theory of Relativity by the paper “On the Electrodynamics of Moving Bodies”, which pointed out some inconsistencies in Newtonian mechanics (1687) when speed approaches a significant fraction of the speed of light. Again, when the speed of the moving body is a significant fraction of the speed of light. Aircraft, for example, were (and still are) built using pure Newtonian physics with a successful history that speaks by itself. And how come, if these equations are not with the best precision? Well, Special Theory of Relativity adds a precision that is not required whatsoever by the models used for flying machines design. To give us an idea, the fastest speed ever attained by humans (11,1 km/s by Apollo 10 astronauts) will make Newtonian equations differ from Einstein equations by a factor of 0.9999999993 (being 1.0 corresponding to an identical result from both theories).

This bit of history helps us to illustrate how science works or more specifically how the scientific method works. When observing the problem we are interested to solve, we develop mathematical models, which are approximations of the natural phenomenon we are studying. The quality of a model in guiding us towards a solution will be determined by the degree of precision required in our solution. In other words, if our moving body speed is an insignificant fraction of the speed of light, we don’t need the degree of correctness provided by the Special Relativity Theory.

On the other hand our well-known Global Positioning System (also known as GPS) makes an elegant and crucial use of relativity theories to guarantee its very accurate precision, showing that each context dictates the required level of detail in the theoretical model.

What if aircraft were designed by the best purists in each discipline?

The concept and development of these amazing machines, weighing sometimes hundreds of tons, flying away from the ground and crossing oceans in a few hours, is the result of the hard work of thousands of people in several different disciplines. To enumerate just a part of them: aerodynamics, structures, flight controls, propulsion, electrical systems, hydraulic systems, etc.
If each of these disciplines worked strictly to attain their own requirements, we would have aircraft like the ones shown in the picture below, and none of them would fulfil all the requirements of the product at the same time.

As you can imagine, aircraft design is a huge effort of tuning the needs of all the disciplines together in one single product. And this has been working successfully for more than a century now.



Source: The Aerospace Design Process. A note from a reviewer friend: "I would prefer to see the glider associated with the aerodynamics and a parachute associated with noise" (Cap. Kev)

A bright tool called Object Oriented Programming (OOP)

The Object Oriented Programming (or shortly OOP), roughly speaking, is a way of programming such that the world is modelled by the concept of “objects”. An object encapsulates data (through the “attributes” concept) and the operations allowed over this data (through the “methods” concept). This paradigm, among many other features, allows the program to evolve and to be maintained more smoothly, using concepts like data encapsulation and code re-use, for example.

As far as I know, there is no hard, formal, mathematical definition for OOP (or any other programming paradigm), such that we say a programming language has more or less OOP features. Once I heard from a co-worker “if there is no explicit private/public keywords in Python, then it is not an object-oriented language”. By then, I started to think how an extreme purist view can make one blind. What are the questions we are really interested in answering? (1) Do we need an object-oriented language? or (2) do we need a software easy to be maintained and to evolve? I can assure you that is perfectly acceptable to use a multi-paradigm language that is not fully object-oriented but fulfil nicely your requirements. On the contrary, doing so, means studying carefully all the extent of your problem and then proposing a solution and not the other way round, i.e., picking up one solution and trying to make it fit to your problem.

For instance, if you have assessed all the main risks of your project, all the main test case scenarios (including the very critical ones) and mapped them in your development process, it really doesn’t matter what language or paradigm you are supposed to use. Unless your customer has a weird requirement that says you have to use a language with an explicit private/public keyword, you can use whatever your team is comfortable with. I would not be impressed with a very well written pure C code, implementing objects (yes, try to use function pointers into your structs and have fun).

The emerging agile philosophy all around

In this very well-written comparison between purists and pragmatist approaches, the BreakingSmart makes an enlightening statement about the agile philosophy: “today, the then-minority tradition of pragmatic hacking has matured into agile development, the dominant modern approach for making software. But the significance of this bit of history goes beyond the Internet. Increasingly, the pragmatic, agile approach to building things has spread to other kinds of engineering and beyond, to business and politics” (learn more).

Once the trial-and-error approach got the cost of a click on a computer, followed by results a few seconds later on the screen, hands-on creativity could walk along with productivity. But this triggers the uncle Ben’s warning: “with great power there must also come great responsibility”. It hasn’t been rare to hear that the agile methodologies are these magical tools which will make any development fit on any schedule. This is tricky and may possibly drive to an erratic trial-and-error approach without a minimal of planning or modeling to support it. As the examples above could make clear (hopefully) a successful pragmatic approach comes with sufficient background knowledge to assure which pieces of information can be discarded without compromising the final solution.