Most people think quality is a property you just add to products by investing time and money. Like you could buy a very poorly done omelette and improve it by just cooking it more, that’s clearly not true and I wouldn’t recommend such practice, unless you like eating ashes. Quality is embedded in the process, right from the very beginning you need to have the proper tools, good material and the skills to mix it together.
The comparison with the omelette is an example I like to use in software engineering, not only to explain to our customers how software development works, but also to remind myself and my peers that we need to think about quality, not in the product but in the process itself, from the very first code change until the very last one.
Note that the same people who believe that quality is a property you add to the product, also believe quality is expensive, because in the end it is something “extra” you have to pay for. That’s also not completely true, of course to bring quality the developers will have to spend some more time setting up the tools and practices that deliver quality, but this is still much cheaper than cooking the omelette again!
In this blog post, I would like to explain what are the tools and practices we use at Elements to cook our omelettes, it is a very satisfactory experience for us, and a very pleasant one for our customers!
First of all, we like you to see the kitchen, there is not better proof of quality than actually having the client involved in the process. Usually, the customer acts as Product Owner in the Agile methodology, defining what he or she wants and doesn’t want in the final product. It may seem like a daunting task to define all the application requirements, especially if it is a large application with lots of functionalities. That’s why the process is divided into what’s called “sprints”, which usually last two weeks. At the beginning of each sprint together with the Product Owner we specify the work to be done during those two weeks, and at the end of it we perform a demo of the work done so the customer can provide more feedback if necessary. Not even in the best restaurants you have that amount of control!
Now, from the developer’s point of view, we want to deliver the best code with the least amount of effort. Legend says the ultimate developer used his keyboard only once, just to automate his job. Jokes aside, what we really like is to code once and never touch it again, because if you have to touch your code again the only reason why you would do that is because it was wrong in the first place. So what we do is also write tests for every piece of code we write, making sure everything works as we intended to. Then, every time we submit new code we run these tests automatically, if a single of those tests fails we don’t allow the new changes to be applied to the final product!
Some tools allow us to find security vulnerabilities before releasing to production
This is closely related to the Continuous Integration and Delivery pipelines. These are automated processes we set up to run on every code change. They are not limited to running the unit tests, but we also include tools to automatically check code formatting and security vulnerabilities. These CI/CD pipelines also take care of deploying the code (releasing a new mobile application, API, web frontend…). We rarely deploy new code from a fancy beach somewhere in Barcelona, this only happens in movies. A machine does it for us, no mistakes, better, safer and faster! One nice thing about this process is that the customer doesn’t need to wait for months to see the brand new cool feature of his app, he can see them as they happen and either congratulate us or blame us because the omelette lacks salt, so that we can correct it.
It is probably fair to say now, that we don’t release those changes directly to the final production server, we usually use two intermediate servers. First we deploy to our internal server, which is mostly used by our internal QA team for testing and security audits, they are very privileged because they are the first to taste the omelette! If they say it is good we deploy to what we call acceptance, which is in control of our customer. He makes sure all the features he wants are there and correctly implemented, once we get his approval we finally release them to production.
An example of live application health monitoring
Last but not least, we take care of monitoring the digestion of the omelette too! We don’t consider the project done until the very end, you know, until the omelette is… well, expelled. An omelette may be delicious, but if you don’t get the nutrients properly it is not worth it. We make sure we include logging and reporting code and tools which alert us immediately with a full error trace and useful information if the users may experience any issue, then we are able to fix it very quickly.
As you can see we make quality emerge from the process, both from the tools we use and from our internal organization. Trying to fix things at the end by investing more time and money is just sub-optimal and would be unfair both for the developers and our customers. Now you know the secret, whenever someone talks to you about software, you think about omelettes!
.gif)
This is the end of the blog post so I appreciate you got so far and I hope you learnt something from it! If you are interested in knowing more about the tools we use here at Elements, find below a more or less complete list, at least for our backend tech stack. And of course, if you have any questions about the process of making a high quality application/omelette, let us know!
This blog was written by
Aitor Ruano
on
Dec 1, 2020
Wij
bouwen
jouw app.
Voor mobiel en web
