I really like chocolate muffins, and I bet you do too. There are hardly any other things in this world as affordable as muffins that can give you as much joy, right?
Now imagine your baker having to make those muffin aluminum or rubber molds for every single batch they put into the oven. Each batch would take days to make, and each muffin would cost a small fortune.
There is not much difference in what most software engineers go through with each new engagement they start. And if those engineers work for a company that prefers a “product development as a service” engagement model, then there is a good chance they get involved in starting a new project on a very regular basis.
There s only so many login and signup forms one can build from scratch before starting to contemplate drug abuse as a coping mechanism.
All bad jokes aside, it s not possible to not notice that each web solution shares some common traits with almost every other web solution. Same can be said for mobile apps, same for testing frameworks. And we re not only talking about visible, client-facing, system components. They often share
- the way error handling is set up
- how the solution interacts with the DB
- how it interacts with third party services and APIs
- how it authorizes requests
- how it validates input parameters on both ends
- how the state is being handled
- how authentication is implemented
- how logging is set up
Setting up these components from scratch takes no small amount of time, and it usually takes a very experienced engineer to do it right.
Let s be honest, that sucks.
We recently decided to try and make this process much more cost-efficient. Basically, the idea was to set up some sort of “skeleton” for all common types of projects and technology stacks we engage in as a collective.
We started with full-stack, microservice-based, distributed web solutions. This resulted in two separate project skeletons, one for back end services, and one for the front end applications. One might say that this sounds like a boilerplate and that we re trying to reinvent the wheel, but it s not like that. On top of what a simple boilerplate usually offers, we went another step forward and provided our teams with seamless integration with different cloud services (currently we support AWS as well as Azure), identity providers, DBs, etc.
Another difference in comparison to a simple boilerplate code is that we plan on supporting multiple technology stacks for each project type. With this, and ideally a simple, interactive configurator that we may build on top of this, we re no longer talking about boilerplate. We re talking about something that s on a much higher level of abstraction and gives much more to the team. We think of it as Higher Order Framework (HOC)
As you may guess, developing something like this requires a lot of time and effort, and may not be something that very small collectives can afford to focus on, but if they can, boy does it pay dividends.
Quicker Project Bootstrapping
This is the most obvious one. Spending less time on setting up project scaffolding, integration with all external resources we know will be used, setting up logging, error handling, authentication, authorization, validation, etc, can literally save days off of our projected timeline.
This gives us the flexibility to either offer our clients more competitive estimates, or to have more time for the team to handle potential issues.
More Reliable Code Base
We build the code accelerator one bit at a time. We re not trying to rush it so we can afford to have our best people slowly bring it to life. Considering both those facts, we can safely assume that the quality of the job done will be at a level higher than what most other engineers could achieve, especially when constricted by tight deadlines.
Of course, things can still go sideways after the initial setup, and quality issues can occur in the business logic code that the team builds afterwards, for any reason. However, our total code quality issue or technical debt is still going to be significantly lower than if we had problems with the project foundation.
More Flexibility With Team Selection
Have you ever been in a situation where you contemplate passing on a really great prospect, that would be really fun for the team, would look great in your company s portfolio, and have 10 of your staff engaged in it, just because you did not feel comfortable having the people you have available take on such a huge responsibility of setting up the foundation for the project?
And don t get me wrong, these people are perfectly capable of producing high quality code and product once they ve been put on the straight path, it s just that their lack of experience makes you uneasy allowing them to set that path on their own.
With Code Accelerator, we no longer have those kinds of issues. It s become much easier to pick the team members amongst those who are not considered our strongest seniors, because a good deal of their job is already done, and they can focus on tasks that are fit for their level of expertise.
Easier Maintenance Across All Projects
To be completely honest, this is one of the benefits we could not enjoy from the moment we had our first modules for the Code Accelerator in place, since none of the ongoing projects at that time used the foundation provided by the Code Accelerator. However, as we re amping up its usage with new projects, it s becoming more and more obvious how much easier maintenance is across projects that use the Code Accelerator.
A single set of conventions, very similar folder structures, very familiar integrations with external APIs, etc make all the engineers feel comfortable in their environment. A bulk of serious issues have been sorted out for them upfront by teams building the Accelerator. As for the ones that have not, it s still easier for the developers to fix them because they re now always operating in a familiar environment.
Easier Team Member Migrations
The sense of familiarity and a flattened learning curve in projects bootstrapped with the Code Accelerator enables the management to move and relocate people around different projects more easily.
Onboarding times are much shorter, and new members are much more effective from the get go, which provides us with much more flexibility, and allows us to bring much more value to our clients.
In part 2, read about how we overcame some logistical challenges in maintaining the code accelerator and what our plans are for the future.
The idea for Maestral Code Accelerator was born out of a conversation between members of our Tech Engagement Enablement (EE) * team. Seemingly an “aha moment”, this sudden strike of inspiration was actually far from it. Rather, it was a culmination of years of working together, many products under the belt, and a reflex-like need to look for points of improvement in the software development process.
The group eagerly began working hard to bring this idea to life. Today, the code accelerator is greatly appreciated by Maestral clients as a unique concept in the Product-Development-as-a-Service domain.
* Engagement Enablement is a group of seasoned Maestral professionals in software architecture, development, and product management in charge of Discover, project intake, and continuous support to product teams during the development process.
One Response to “Save Time Without Sacrificing Quality in Software Development: The Story of Maestral Code Accelerator – Part 1”
[…] is part 2 of the story of Maestral Code Accelerator. In part 1, we discussed why they re such a good thing to have. In this installment, read about how we […]