Contents

7 mistakes made when building an IT project

Michał Matłoka

19 Jan 2022.5 minutes read

7 mistakes made when building an IT project webp image

Albert Einstein said “The person who never made a mistake never tried anything new”. People make mistakes, projects fail, those things just happen. During the meetings of our Software Architecture Discussion Group, we have recently discussed mistakes we’ve seen during our careers. Today let’s look at a few categories of things that may go wrong.

Using languages for things not intended to

Nowadays, there are many general purpose languages on the market. CRUDs can be written in almost every single one of them. However, there are edge cases where not all of them fit.

One such edge case is data processing that requires parallelism. There are languages that do not support multi-threading, only a multi-process approach. We have seen projects in which data intensive parts were written in e.g. PHP or PowerShell. They worked, however, the solutions weren’t really efficient. Rewriting to more suitable languages brought huge speed-ups.

On the other hand, when you need a simple website without too much traffic, it may not be worth spawning a Kubernetes cluster with JVM pods.

Using technology for things it’s not intended/designed for

With great power comes great responsibility. There are technologies that allow for unthinkable things. It is possible to animate website URLs but you rather don’t see that on daily basis.

As an example, over the years during our work, we have encountered a few cases of Akka Cluster being used as a means of communication between different microservices. Is that possible? Yes. Does it bring any problems? A lot! If you’d like to learn more about that, read my other blog post 6 reasons why not to use Akka Cluster for interservice communication in a microservice architecture.

How to avoid such cases in the future? Read technology documentation, look for use cases, patterns & antipatterns. Do some research - if you google a technology name with your use case and it appears that nobody has done it yet, think twice, there may be some really good reason for it. If it is still unclear, just ask the authors.

You might also be interested in:

Not estimating cloud costs before implementation

Cloud is great, but its usage may be tricky. It is worth checking pricing models of various leveraged products. Sometimes operations that are generally cheap, suddenly make your bills skyrocket due to e.g. huge numbers of executions. In other cases, big data computations may be pricey and creation of UI that spawns a re-compute on every refresh may be quite painful. Lambdas? Sure, but make sure they won’t be running constantly and for a long time, e.g. 24/7. Otherwise, definitely, they won’t be the most cost-effective solution.

Multi-write shared database

In the era of microservices, we’re dealing with a lot of topics related to domain separation. Who should store which part of data, who may have a copy, what are the APIs and methods of communication?

Unfortunately, some people still choose shortcuts and create a single big database schema, later leveraged by multiple services. What consequences does it have in the long run? Database schema changes are becoming quite complicated, since there is no single “owning” service, but multiple ones. During incompatible schema migration, probably all of them will need to be shut down, bringing down the entire system. What is more, if one of the services is causing a big load, then it influences the remaining ones. Such a huge coupling should be avoided if possible. Unfortunately, slicing existing big, common schema later may be very challenging and time-consuming.

You might also be interesed in:

Decisions based on politics

This could be a whole separate article. Probably everyone has been in a situation where “business” or higher-ups heavily influence the decision making process and insist on using a given technology/tool. Unfortunately, there are cases when the decision is not fully correct from the point of view of feature of the system being worked on. You may have heard sentences similiar to the following ones:

  • We pay for X, let’s use it for all our projects.
  • We need geo-replication, let’s use database Y for everything.
  • Technology Z worked for this big, well-known company, so it will work for us for sure.

Some decisions should be actually evaluated per project and use case at hand, not per the whole company. The usage of a specific database for a microservice should be a result of solid research and requirements validation, not a result of company politics. Of course, projects can be built using such technology, but oftentimes, this will turn out to be just more expensive, complicated and may increase the development time a lot.

Over-engineering

Who has never seen over-engineering in practice? Let’s build a website on Kubernetes, auto-scalable to handle thousands of simultaneous users, but.. actually the load would be close to nothing. But who knows, maybe in the future, it’ll pick up the steam and then we’ll be ready for it! That’s what happens to some failing startups where instead of building an MVP to just get to the market, an over-engineered version is being produced and never reaches the daylight.

Building a non-extensible system

We have talked about over-engineering, but the truth is you need to find balance to avoid building things that can’t be extended later. Such issues can also stem from some technological choices.

I’ll give you one example from one of our past projects. We took over a JavaScript project with frontend based on Ember. Complementary backend part written in Node.js was doing data-intensive operations, the project was struggling with both performance and stability issues (also due to poor code quality). Our conclusion was that it may be worth it to rewrite the backend (communicated over REST) to JVM. Should be simple, right? After further investigation, we gave up. The REST API provided by backend was written using JSON:API and was highly coupled to the front implementation. JSON responses included, apart from the actual data, e.g. other related entities and links to them. Due to that, the single API endpoint was returning 20 MB JSONs. Unfortunately, at that time, it appeared that JSON:API support in other languages was very poor.

More content from the SoftwareMill team:

Conclusions

Mistakes happen in various stages of IT project development. Everything depends on our actions, the quality of our work, and the research we have done. Additionally, when you see something wrong happening in your organization, don’t be afraid to speak up, it may save you from a lot of future problems.

If you like topic of mistakes, read my other articles:

Share your mistakes with us!

Blog Comments powered by Disqus.