feaured img

How can indecision be the best decision in software development?

ReactiveConf Special Edition TechTalk

There are plenty of ways to get information on and access to the latest trends and technologies, but going to conferences is sure one with great benefits. You can not only get top experts giving you hints and tools to improve your workflow, but you can further build your network and get hands-on experience on the spot. Fortunately, there are numerous quality events within and beyond our borders and ReactiveConf is most certainly one of them. It takes place in the beautiful city of Prague and is the ultimate spot for the European tech community to get the latest global insights in web and mobile development through meaningful connections and shared experiences. We were among last year’s attendees and we even went backstage to interview dome of the speakers, so that we could share all the great information on their hands with you too. 

In this article we give you an insight into how indecision in the software development process can actually be the best decision, through the words of Boris Litvinsky, Tech Lead at Wix.  

As a child, Boris was a real gamer, he was obsessed with games and that obsession stayed with him throughout his teenage years too, when he wanted to build a news website about and for the gaming world. He did not have the knowledge to do it on his own and thus, he asked for the help of others but at some point he got tired of that, bought a book on PHP and started coding at age 16, out of necessity. It did not take him much to fall in love with it all and to realise that is what he really wants to do. Ever since then, he has had the chance to work with companies of all sizes – from a garage-stage startup to a colossal corporate environment. He has an immense passion for well-written, easily maintainable, well-tested code, which comes from his belief that “a product’s internal code quality has a direct impact on its external quality – the business value the product gives to the management and to the product owner” he summarises. 

Boris is currently working as a Tech Lead at Wix, with the responsibilities of overseeing the day-to-day development processes of certain products and driving the technical approach of his team. Basically, his job is to make others more productive and that is how he has come to the realisation that there is not only a right or a wrong decision to be made when it comes to software development, but also a third option of indecision or deferring a decision as sometimes that could result in an even better codebase. He tells us that the main opportunity that arises when postponing a technical decision, is to discover and gather more information about the matter at hand and to become more well-informed about the problem, according to which the decision eventually has to be made. “In the frontend market, especially, many decisions are being driven by hype, ego and biases” he says. Clearly, that needs to change, people need to get more informed to lay down the tooling, to understand what they are actually building and to understand the business domain and then do whatever they need to do. This basically improves the chances of making a better decision, a well-informed decision.
In terms of the issues that might arise, according to Boris, the biggest one is the fact that if you are developing something that is being used not only by you or your team but by others too, your decision can of course have a long-lasting, even crippling effect on teams that you are unaware of, and even on the application itself. The other issue you need to be aware of is, if you are postponing too much, some options may eventually become unavailable to you. 

You might be wondering how to identify the right moment to make a decision. Well, Boris says that the first question you should ask yourself is “whether right now is the right moment”, but if the decision actually has a small impact and is reversible, then there is just no point in deferring it – you should just decide and then change it later. Other than that, you need to either set a date for yourself or you need to identify a missing piece of information that you need to make the decision. 

If a decision is overdue, it is still possible to keep up the productivity. “Some people reel in options, which basically means that they create options for postponing their decisions within their codes” Boris tells us. What he means is that, if you are not sure what library you will be using to perform some tests, you can create an abstraction over that library and have most of your code use that. That will allow you to swap one library with another, without your application knowing about it. Creating options, therefore means creating the opportunity for yourself to decide at a later date, while you keep the costs low. According to Boris, one of the biggest things that many applications are missing is the correct bundle – defining drawn circles around different parts of the app, declaring a corner for each and deciding how they interact with one another. “We are always in a rush to create those boundaries, just because we are afraid that it would be too late” he says, and yet one of the tools that are currently hyped is micro frontends, which is great, Boris and his team at Wix are using it, as it is a great tool for a particular job. However, if you are not sure that your boundaries are correct, then you should not go for something this hard. There are other solutions, like modular monolith, which basically tells you that you should have those boundaries but you can keep everything in the same code project and then enforce those boundaries using tools and folder structures et cetera. 

 

Overall, a deferred decision gives you an option to evolve your code easily in the long run, like the abstractions we mentioned earlier. Things change: you can start a project with a team of 5, building a small application and then your team can grow into more than 30 developers and your app can become huge or you can have multiple apps on multiple platforms. Thus, “having those options allows you to adapt to a reality and not get to a point where you basically have no choice but to be right at all things because the velocity increases and then you are just battling the code” as Boris puts it. In the long run, it all creates a business value – as long as the code is changeable, the implementation, wherever you need to implement it, is cheap. 

 

If you are interested in other topics as well, you should keep following our BLOG where we are coming with new TechTalk stories every Monday

 

Are you looking for tech or business experts to hire? 

As professional headhunters, we are here to help you with all your IT and Business recruitment needs. Give us a shout!