We have been in contact with information technologies for 4 decades and through these forty years we have advanced “a lot”, we are creating more and more complex software designs, thousands and thousands of lines of code, hundreds of hands coding, hundreds of eyes wearing and unveiling, everything so we can upload that picture of dinner with our friends to Facebook.
And in 40 years we have moved from accounting systems in command lines to cell phone apps that allows us to apply a filter to photos, from simple calculators to a set of applications that can keep our emails, photos, files, calendar, among other things, just one touch on our cell phones.
It is because of this complication of systems that it becomes a necessity to have a discipline at the time of developing them. Today we have multiple tools that facilitate the rapid development of complex systems, yet despite this our systems still have a number of bugs, a feature that is not at all exclusive in custom systems, but is in the entire industry due to the exponential complexity of software design.
Let’s see for example the Windows calculator, if you open it at this moment and type 4 followed by the square root button, it should give you a 2, is not it? So if we subtract 2 from our result, how much is the total? This is done to exemplify and because Windows is such a complex system, this small bug has not been a priority for Microsoft (or for some other reason it has not been removed).
Now, one way in which we can reduce (but not eradicate), our bugs sent to the QA department is through a previous design of our elements, then I present a small analogy to explain the latter.
Suppose we have 5 masons who will help us build a house, they know that the house will have 2 bathrooms, 3 bedrooms, kitchen, dining room and living room, however we do not give them any plans or a guide to build the house, the result may not be what we want, depending on the skill of the masons.
The same is with the systems: if we do not generate a plan of our elements to be built, how can we know what we are going to build? Just graduates are used to design at the time of coding, working in this way the only thing we achieve is a little modular code and with some bugs that are not logic but rather architecture, due to the fact that we do not design a modular architecture correctly. Give us a small, reusable and easy to maintain element.
An easy practice, which can take us a few hours, very few compared to the time we spend solving bugs not to take them, is to perform the specifications of Operation and Functionality of the element to be developed, for example:
By means of this previous design we already have a plan of what we are going to build, of course this is a very crude example, you may prefer to save the user and password in a separate Model class, you may want to simplify the class, but the point will always be the same, from this moment you are already thinking about what you need to build, without having written a line of code, and when you have in front of you your open development environment you already have an idea of what you are going to do, you will no longer be coding to trial and error.
This is a step that can help reduce the defects that you send QA and will serve you and your team a lot. There are more practices, such as code reviews both yours and those that your team can perform, maintain a standard code in all developments of your company, develop test cases before coding, and even write pseudo code in the stage of software design before entering programming, but each of these topics are very extensive and should be treated in a more profound way, this being the preamble.
