Engineering at MercadonaTech

Engineering is a very old discipline in the history of humankind. Thus it may come as surprising that still so many public works projects are fraught with problems¹, take much longer than anticipated or even end up in disaster. Even when building your own home, you should expect cost overruns.

Engineering is the use of scientific principles to design and build machines, structures, and other things, including bridges, roads, vehicles, and buildings.

Software Engineering is a much younger branch of engineering, and still considered more of an art than a science by many. Initially Software projects were approached in the same way as classic engineering, with lengthy planning and design phases, before it was handed over to Engineering to implement. Hence the term Waterfall Development. Nowadays most companies will claim to apply some kind of Agile methodology, and yet the failure and delay rates of technological projects are still staggering². Why is that so?

When writing software, a developer is metaphorically (and literally when starting a project from scratch) presented with a blank canvas. Writing software is a very creative process, and there are infinite ways of implementing a feature or building a project. Another way to put it is that the amount of damage that bad engineering can do is infinite too.

Even when designing a massively complex building or machine, more often than not you have guidelines and, even more importantly, you’ll have checks that will prevent a bad design from being accepted. The soundness of the structural design will be analysed, the assembly of the individual machine pieces will be simulated… Not so with software, where you test and integrate the software as you build it (unless you want to go back to the dark ages of Waterfall, that is).

Finding Our Way

At MercadonaTech, we strive to develop our product iteratively and continuously while paying attention to market, user and development feedback loops. To achieve this, our Product and Design teams use a mix of Lean, Agile and Design Thinking methodologies.

How does Engineering fit into these product development frameworks?

The three big ideas that underpin our Engineering team’s quest for excellence are the disciplines of Extreme Programming, Product Engineering and the Open Source code ownership model.

Extreme Programming

Most discussions on good practices tend to revolve around agile development, but, already 20 years old, the discipline of Extreme Programming has arguably contributed more to sane practices (and work life!) for developers than any single one before of after it. Every great company in the world doing software follows many of the concepts defined two decades ago, like Test Driven Development or Continuous Integration. That said, not many practice all of them.

XP solves for us multiple problems that plague the industry:

• Fast iterations and small releases allow us to learn as fast as possible about the problem we are trying to solve, which avoids writing unnecessary code. It also prevents integration problems as found in the dreaded Big Bang releases
• Pair Programming helps spread knowledge, have better designs and in general achieve collective ownership of the code
• The “simple is best” approach to software design avoids ending up with a complex system nobody can change or maintain, because nobody understands it all

There are many other values, principles and practices to this discipline but by far what makes it so powerful is that most of them don’t even need organizational buy-in or big company-wide transformations. Many can be practiced in any company of any size and still bring tangible benefits.

We are Product Engineers

The concept of Product Engineer, is relatively recent, and it means so much more than “Getting Things Done”. A Product Engineer:

• Cares about the product and has empathy for how the users actually use it
• Can work with a designer or a product manager to design a great solution
• Knows when to invest in a solid abstraction and when not to, because she knows whether it would provide value to the product

Hiring, thinking as, and striving to be Product Engineers avoids the pitfall of developers worrying about and putting energy into solving the wrong type of problems.

Open Source Ownership Model

When having multiple teams working on different systems or services, communication problems and dependencies that block progress will inevitably arise. And Blockades are The Enemy. There is nothing worse for productivity than having a team leave work unfinished while they wait for another team to complete a feature they need. Because the priorities of each team may be completely different at that moment in time.

The Open Source world already shows a way to solve this. A given service and its codebase will always belong to a team. When another team needs a feature (say, a new field in an API response) on another project, instead of waiting until its code owners find the time to implement it, they can just go and do it. They can create a pull request, which the “maintainers” of the project can accept if it follows the team’s coding standards and fits into the system’s scope and goals. It’s just like contributing to Open Source projects.

Similarly, while as an Engineering organisation we’ll want to standardise tools and libraries to be reasonably efficient, we don’t need to agree immediately on everything when it comes to introducing new tools or techniques, which frees up creative energy that may otherwise need to wait for consensus.

Towards a reproducible model for success

While not as mature as the classic Engineering disciplines, I believe nowadays software developers already have the tools that, if not guarantee, at least make success much more predictable and likely than it used to be.

This is part of the way we strive to work like at MercadonaTech, and while we recognise that nobody can live by it perfectly every single day, all of the time, we are very happy how this path is working for us.

[1] List of structural failures and collapses 2000–2009. Source: Wikipedia

[2] The Standish Group Chaos Report (2015) found that only 29% of IT project implementations are successful, and 19 percent are considered utter failures