As part of my series of interviews with software engineering experts including tool vendors, service providers, consulting companies,… (yes, I know, I stopped a long time ago but apart from this one I have two more scheduled already so let me know if you are happy with this “resurrection”!), I had a chat with Antoni Aloy and Bernardo Cabezas, co-founders of APSL a SME specialized in the development of web / mobile applications.  

I think you’ll enjoy the following excerpts of our interview (emphasis is mine!):

 

• Why the focus on Python & Django?

Not only Python, we also work with JavaScript, and even Go! We always look for the best tool for the project at hand. Best mainly regarding the time to market and the maintenance effort after the release. Python satisfies both conditions.

 

• Sure, but do you really evaluate all languages in the world for every project or you basically resort to Python as default solution?

The profile of the client itself already limits the search. Most of our clients are enterprises for which security is important, therefore, you can forget about PHP to avoid headaches. Rails is also discarded because it’s not always backwards compatible and clients won’t want to pay for code updates required for new Rails versions. Java has a bad time to market when compared with Python. In our experience, Java rates are three times slower than Python projects (and we are former Java developers!).

 

 

• How would you define your development method?

The minimal ceremony as possible and as much automation as we can. We do a lot of SCRUM with daily meetings. On the technical side, version control, as many tests as possible, continuous deployment …  everything as automated as possible, including the deployment on the production environment. In less than 2h we have all the tools and systems in place to automate an end-to-end process (from code to production deployment) for new applications. Once this is setup, software updates can be released in five minutes (and this could even include some database migrations in Django and hot deployments).

 

• Any modeling at all?

We use UML to start the analysis phase. Mainly class diagrams, also a few sequence diagrams and use cases. But for us, it’s just a way to paint, to discuss. There are tools to go from UML to Django but for us it’s just faster to open the editor and write the code ourselves, UML is good to discuss using a common (graphical) language.

The sequence diagrams are mainly used to show orchestrations between different (web) services.

Use cases are mainly employed to calculate the size (and therefore the budget) of the project. Our “formula” takes into account the number of use cases (and their internal complexity according to our own scale), factors in the target language and the team that will be developing it and produces a very accurate estimation of the project cost. We have used them in several projects and the deviation of the budget is minimal.

Again, all these diagrams are for the initial analysis, they are not maintained. All the knowledge resides in the code.

 

• Then, what about new members that were not involved in the project and need to get a hold of it?

Our applications are well componentized. And Django helps a lot on this as well. So you point them to the right component to look at. And you also have the debugging tools that help you to follow and explore the code.

 

• Do you use the information in the version control system to evaluate how individual team members are performing?

It’s useful to evaluate the quality of the code but specially with the goal to see how we can help. Now that we are growing we want to formalize much more our internal code inspections. We assign tutors to junior members and try to enforce common style guidelines.

 

• What about the non-functional requirements?

We consider them as a very important part of the application and therefore they are taken into account from the very beginning, at the same level of other design aspects of the software. Then, we monitor them at runtime. For instance, from time to time (depending on the criticality of the application) we record the requests that the application receives and store the time it takes to process it (including its location).

Since in our projects we take care of everything (writing the code, deploying it, monitoring it…) we also choose the kind of server depending on the needs. Typically, we go dedicated servers, but we also work with  DigitalOcean or Amazon and configure them accordingly.

Controlling everything is the best way to ensure the quality of our work but this “forces” us to invest plenty of time in learning and testing new technologies (but we love it!).

 

• Are you missing something? Any tool / service that would make your life easier?

A PaaS (in the sense of Heroku or Google AppEngine) very easy to configure, multi-platform, open (but also offered as SaaS if you wanted),… So basically the perfect PaaS.

 

Thanks Antoni and Bernardo for your time and best of luck with your future projects at APSL!