Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.
Learn from our mistakes so you don't have to make them
As a developer, you stand on the front lines every day, developing and maintaining digital products. In that pioneering work, many difficult decisions arise, but Axxes consultant Hannes Lowette ensures that you make fewer mistakes by sharing what he has learned in recent years.
Hannes Lowette, Head of Learning & Development at Axxes, has been active as a developer for over 15 years and has navigated through many challenges. "Continuously learning new frameworks, tools, or programming languages is exciting, but it can also lead to frustrations when things don't work as they should. You become a developer because you enjoy the pace and constantly reinventing yourself, but sooner or later you hit walls," Hannes said at the Build Stuff conference. To prevent other developers from making the same mistakes, Hannes shared his tips and tricks on stage in Lithuania.
Look at the technical fit
To avoid this, it's important to continually ask yourself these questions:
Does my solution help us with this problem?
What are the differences compared to the alternatives?
Is there a better solution?
Is this the simplest solution?
What about the cost?
What are the maintenance and licensing costs?
Pay attention to the red flags
Even if there is a technical fit, things can still go wrong. Hannes and his colleagues experienced this in 2014 during a project where the code was heavily intertwined. Both the presentation logic, business logic, and data access were all in the same file. Due to improper use of certain features, the application ran slower than it should have. To untangle this spaghetti code, the team relied on Agatha, a framework that was technically ideal for the job.
However, something went wrong: Davy Brion, the man who created and maintained Agatha, disappeared from the scene. In fact, if the team had delved into the documentation, they would have seen that this had happened a year ago. Thus, the solution quickly became outdated and became a weak link in the project.
In this case, the team could have opted for MediatR, an open-source alternative with similar features that is maintained by an active community. To avoid such problems, it is important to focus on questions like:
- Who maintains the library? Is this their full-time job?
- Are those people still actively working on it?
- Is the source code publicly available?
- What licensing model is used?
- Have they been acquired by another company? What are the plans?
Is everyone on the team on board?
A few years ago, Hannes worked with a few colleagues on a long-running project where all the data was stored in SQL Server. They needed to maintain an audit log of what had happened to the data displayed on the dashboards—a task that could be accomplished using EventStore.
Although the technical fit was there and there were no major risks, things still went wrong. The majority of the team was too inexperienced when it came to EventStore, making them too dependent on the people who did have the knowledge. If you're looking for a scalable solution to a problem, it's important to consider the skills of your team by asking yourself these questions:
- Do we have the knowledge?
- If not, is it available somewhere?
- Can we train the team?
- Is everyone able to work with it?
- What documentation is needed?
By ensuring appropriate training, occasionally coding together, and documenting everything well, you can make significant progress.
Learn how something works.
Technology may seem magical, but it's important for developers to demystify that magic and understand what they're working with or on. Hannes experienced this when a colleague complained to him about how "slow" Entity Framework was. The issue didn't lie with Entity Framework itself - it was doing exactly what it was supposed to do - but rather with how the colleague was using the framework. For example, there was a missing index, too many fields were being retrieved, and debug behavior was mistaken for production performance. The colleague simply didn't understand how Entity Framework worked concretely and how to utilize it optimally. If something seems like magic, it's often doomed to fail because you're likely applying it in the wrong way. Therefore, it's important for developers to always look under the hood of frameworks or tools and consider the following:
- How does it work?
- How is it built?
- What tools or concepts were applied?
- Could we theoretically build it ourselves? For example, create a prototype or look into the source code if it's open-source software.
- Do we understand the effects of how we're applying it?
Keep your tech stack tidy.
Sooner or later, as a developer, you'll find yourself working on a project with a very old codebase. Colleagues come and go, but the codebase remains. Just as you can determine the age of a tree by its rings, in such a case, you can often trace when your predecessors implemented something based on the technology used: database engines, frameworks, libraries, and practices. This results in an application with a multitude of technical components.
The application will undoubtedly keep running, but onboarding new colleagues takes months. The solution? Trim your stack! When adding new technology, consider what old components you want to remove. Replacing old pieces of software or code often takes time, but if you can't justify that time, it might not be a wise decision to add the new technology. Always ask yourself:
- What problem are we solving by adding this new technology?
- Do we really need it?
- What old, equivalent alternative do we have?
- Can that be replaced by the new one?
- How much effort would that take?
- What is the cost of maintaining both, in terms of maintenance and onboarding?
Dose innovative solutions
The opposite of such a legacy project is a greenfield project where you can start completely from scratch. Hannes and his colleagues have also experienced this scenario many times. A nice situation, were it not for the fact that they fell into a trap several times by trying to introduce too many trendy frameworks and tools all at once.
This can go wrong, as the team needs to invest a lot of time in learning the new tools and will likely need to debug more frequently. Even the simplest business applications can experience significant delays at such times. Hannes' lesson? Budget extra time when working with new technology, and introduce only one innovation at a time. Also, always explain the risks and benefits to your client.
Always let your architecture follow your problems, and not the other way around. If you are a small team working on a simple application, your architecture does not need to be unnecessarily complex. Start with the simplest solution to your problem and publish your application. After that, you will quickly see how users interact with it, so you can discover new needs and problems. Iterating is important.
It's tempting to look at big players like Netflix and choose microservices like them, but as a developer, you usually don't build applications of that caliber. Microservices solve a problem that you encounter when you reach a certain scale, but that is often not the case for a simple application. Here are cases where microservices are useful:
- When you want to be able to scale pieces independently of each other, so you can balance costs and speed.
- When you want to roll out different features for different customers.
- When you have multiple technology stacks that build separate parts of your application.
- When you have conflicting dependencies.
The essence
After more than fifteen years in the field, Hannes has learned many lessons by making mistakes. Want to avoid those? Follow his advice: first, consider the technical fit of the solution for the problem you want to solve. Identify red flags and ensure everyone on your team is on board. Demystify technology and understand how it works. Trim your stack and eliminate unnecessary elements. And above all: ensure that your architecture follows your problems, not causes them.
Every month our Insights in your mailbox? Sign up now!
Hannes Lowette
