Magically deploy a new project in 1 month

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.

Telling the background of her professional experience, in which many developers can surely recognize themselves, Netta recalled how over time she has experienced the enthusiasm of her first post-graduation work. She also recalled the discouragement of situations in which her values ​​are important — test! quality! design principles! — they were put into the background. And even the joy of finding situations in which the balance of power between the product managers and the engineers was not so unbalanced as to leave the former with the faculty to decide on what competes with the latter.

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.”

If engineer and PMs find the right way to connect, a different and more virtuous distribution of responsibilities can follow. For example, the infamous deadlines can be managed more independently by the developers, without therefore receiving unjustified impositions that are impossible to satisfy, thus managing to define realistic deadlines, without being always and constantly pushed to your own limits.

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.

Obviously, this does not mean that, from the point of view of the developers, there are tasks that must be overlooked. More simply, it is necessary to find the right modality and the right time to be able to balance the speed required by the PM with the quality necessary for each product software.

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.

Or, more simply, one can discover that it was not worth investing in the project and abandoning it without too many regrets.

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.