Introducing Expansiva Engineering
Expansiva Engineering is a consultancy company based in Barcelona, Spain.
They’re working on an internet of things project that has many different applications.
As an example, they aim to drastically reduce electricity power bills in companies using big machinery.
We’re talking industrial machines that have more than 200A or 400A and that waste a lot of power, and Expansiva Engineering aims at lowering power bills by controlling and monitoring everything around those machines: power, temperature, humidity, pressure or even lights.
But the platform doesn’t stop there; it can also monitor things such as refrigerators in a supermarket, issuing alerts before the equipment actually malfunctions and, in this case, preventing that the food (which translates to money) within it is lost.
Though the team is growing, they don’t have a very large team yet (they were founded just a year ago), but they’re working hard and put a lot of thought and effort into setting their workflow.
We spoke with CTO, Xavier Fernández Salas.
Expansiva started their framework with Scala not because it was a functional language, but rather because they knew that further down the line they would be using Spark, and they figured that by doing so they’d be acquainted with the language once they got there.
Just one month after they went into business, while setting up their environment and configuring tools such as Jenkins, JIRA and Confluence, they noticed a project mentioning Codacy. They had a static analysis tool in their pipeline to install but decided to give this other tool a try first.
On Codacy’s first run the platform raised a lot of issues that they hadn’t seen anywhere else, so they looked into them and it started changing the way they were coding.
Xavier tells us that not only did they learn Scala with Codacy, but they also learned how to program functionally, and they’re still learning new things every now and then (it makes sense, as we keep adding patterns and improving the platform).
When it comes to their workflow, they use SCRUM and work on a test-driven development methodology; when something gets committed that means it has 100% test coverage and 0 Codacy issues.
When a developer is done with the stories from the sprint they fix the remaining Codacy issues or improve code that Codacy marks has having low quality (for instance: high cyclomatic complexity).
It’s also great to onboard unseasoned developers:
“When an intern or a software engineer with no previous knowledge of Scala arrives the first task is to look at Codacy’s best practices. It’s really useful.”
In the beginning, they only had one web developer, and Codacy was pointing out issues without anyone else in the company needing to know the programming language.
“It helps a lot because it reduces a lot of the time of code reviews while increasing the time we spend coding.
The code reviews are now about code structure and its internal logic, and not about code conventions, making the reviews less repetitive and more interesting.”
Xavier estimates that Codacy is saving them at least 60% of the time they would be spending on Code Reviews otherwise.
And what is the best thing about Codacy for them?
“Time saving and learning!
When Codacy marks an error, if you don’t understand it you can follow the documentation; Codacy gives you a link, for instance, from Effective Scala; you follow the link, go to a web page that explains very well what is wrong and why, and you won’t be making the same mistake again.
It’s not just time saving, it also makes you learn a lot from your errors.”