The 5 major drawbacks of increasing the speed in software development

Build fast, build right, build for the future

 

 

This was the key message delivered by Paulo Rosado, OutSystems CEO, at his keynote speech during the 2020 OutSystems NextStep event. With it, Paulo signals that we are entering a new stage in the life of low-code development and that OutSystems wants to pioneer the change. But before going into detail, let us take a step back and consider how important those big words are.

 

 

 

We, humans, are used to think that every time we try to do something fast, we are going to get lousy results. And even in technology, where a lot of the work is automated, we still believe this standard. Several major reasons make it hard for us to grasp that a software solution developed in record time will not have a compromised quality or simply not be secure and scalable:

 

1. Poor Grooming

 

The easiest step to reduce development time is cutting on the amount of manual work, especially the part of it that does not involve creating the solution itself. Documentation is usually considered a dreadful, lengthy task that involves a whole lot of human interaction, and not a lot of coding. So, it comes as no surprise that developers simply cannot bare spending any time on it. As pressure rises and deadlines get tighter, the amount of time the software development team will spend on actually understanding the challenge, defining the solution, and the criteria for success will be heavily cut and replaced by sets of quick, less informative sessions followed by an immediate jump to coding.

 

 

2. Quick short-term (sighted) wins

 

When time is short, there is an overwhelming feeling of helplessness and that everything will fall apart. To control that stress factor, people usually search for refuge and comfort in the sense of getting the job done, i.e., choosing the easiest possible task to be done first to feel the sweet taste of victory. This overall will lead to a procrastinating team that will change from task to task, manipulate planning and even swings between different solutions as an excuse to be always achieving great results without achieving no result at all.

 

3. Testing is a waste of time

 

The target is and always will be to have a solution in production that can start being used within the agreed timeline. The purpose of testing is to guarantee that the solution works and does not have bugs that could greatly impair its usefulness. However, testing suffers from a curse caused by its own results. If testing is successful, it was pointless. If testing is not successful, some patch can always be implemented, and the application is ready to be rolled to production. With a 50/50 chance of actually finding something, important testing does not seem to be a valuable way to spend time.

 

4. Execution vs Experience

 

Another easy way to deliver fast is to focus only on the execution of the application. When it is critical to deliver something, the focus becomes the core result that can determine if the solution really performs its job. Thus, when time is short, there is no reason to spend time trying to make the application useful, intuitive, and with an engaging UI. The application achieves two amazingly paradoxical results simultaneously. It will be able to solve the problem. However, no one will use it, thus leaving the problem unattended.

 

5. Solve a problem instead of developing a solution

 

Quite related to incomplete grooming and inexistent documentation, when time is short, and the focus becomes on a small set of key features or the points that were raised first, it becomes straightforward to miss the forest for the three. In other words, it is far from unusual having development teams and business users entering in lengthy discussions on single small issues or requests just because that was the first point on the list. Thus it comes as no surprise that many applications end up being developed to solve a small part of the problem, maybe the first raised issue, instead of developing a solution that can avoid such issues or challenges to existing in the first place.

 

Once decisions are taken to increase speed and compromise on one or several of the previous points, it becomes far too often that solutions suffer from severe limitations in their usefulness, security, and scalability. Thus, rendering them useless for Enterprise-Grade Companies.

Stay tuned for the next blog post where we will discuss the approached usually used for these problems and how low-code deals with them.