It might seem strange, but how would you react if they told you that knowing algorithms, programming languages, design patterns, and best practices for managing and releasing software projects might not be enough to make an efficient and successful product?
If you have been in the IT world for a long time, you have learned at your expense that even starting with the best intentions and the best skills, the harsh reality is always lurking ready to surprise you. Lots of difficulties can be found in turning a Proof of Concept into a product: brownfield projects based on classes of 2,000 and more lines that are impossible to refactor, with the wreck of good intentions to write tests before the code for time and, more general, with all the requests coming from the team that defines the product.
These are common stories, experienced at first hand by almost all the developers who have dealt with those that are often classified as “product needs” and that end up to relegating to a marginal role all the good intentions and values of the software engineer.
In short, paraphrasing a bestseller of some time ago, we all know that “product managers come from Mars, developers from Venus“.
Need for Balance
Codemotion Rome 2019, Netta Doron, Backend Team Leader at Wix, shared her personal and professional path with the audience in the intricacies of project management and shared 3 magic pills which, in her opinion, can help software engineers to achieve a fast and uncompromising project delivery process.
It is therefore important to know how to reach the right balance between PMs and Devs and this is why developers must also be able to have in their tool-belt the necessary tools to manage all those aspects of the lifecycle of a product which are not strictly related to the writing of software.
The Magic Pills
According to Netta, there are 3 magic pills that software engineer can do just to achieve what Netta herself calls “fast, uncompromising delivery”.
The first is to learn to relate as effectively as possible with the PMs. Instead of being two alien and distant races, it is more fitting to see these two team souls as the oriental dualist concept of Yin and Yang. Quoting Wikipedia “seemingly opposite or contrary forces may be complementary, interconnected, and interdependent in the natural world, and how they may give rise to each other as they interrelate to one another.”
The second pill revolves around the emotional investment of the software engineers in the product or project that is being realized. Rather than receiving unnecessary information on the “what” or “how” it should be done, it is more effective to understand the “why” and feel involved in it.
From the practical point of view, the understanding of the “why” of a project, especially if starting from scratch, is fundamental to define the limits of the relative MVP. The MVP must indeed be an answer to this “why”. In this way it is possible to focus on everything that is really important, postponing the secondary aspects and functions to a later time.
It is here that the third Netta’s pill comes into play, which wants to be a tool to be able to decide and balance the development times and prices versus the code’s reliability, efficiency, and quality.
This tool is the “3x model” – Explore, Expand, Extract – outlined by Kent Beck. At the base of this model is the realization that not all ideas, not all projects can actually be successful. The 3x model offers a way to understand if an idea is following a winning path and allows to modulate how much to invest in the idea based on risk and return.
In this way, it is possible to create a path in which, in the face of an initial MVP made fast with only the really important features, it is possible to make the project grow in a virtuous and coherent way both from a more commercial point of view and from that of technical view. Any technical debt created during the exploration phase can gradually be eliminated during the expansion phase.
The real case proposed by Netta during the talk, the logo creator project for Wix to be launched in a month, is the example of a project that managed to move along this path, proving to be a challenging but successful project both for the PMs, both for engineers and end users.