Why Today’s IT Solution Becomes Tomorrow’s Problem?
Short story
Once upon the time our development team decided to create a chatbot. The aim? Make customer support as seamless as possible. After analyzing target audience, the team found that a significant chunk of their users spoke English. So, they coded the chatbot to respond only in English and integrated it with industry-specific jargon that their primary user base would understand.
Fast forward six months, we started to gain international traction. I think you understand what happened next. The support team was inundated with complaints about the chatbot either misinterpreting or not understanding user requests in other languages. Of course, we could force our users to text only in English, but it would be awfully uncomfortable for users and would make less outcome in business terms.
The problem
Had the team paused for a moment during the development process to ask, “What if we expand into different markets?”, they would’ve approached the design and coding of their chatbot differently. They might have chosen a multi-language support framework or at least structured the system in a way that additional languages could be integrated more seamlessly.
This tale serves as a cautionary reminder for all developers: The here and now is important, but software development isn’t just about today. It’s about anticipating change, evolution, and adaptation. The question, “What if…?” is a powerful tool in a developer’s arsenal, serving as a reminder to look beyond the horizon and build for a future full of unknowns.
After 7 years of working in different companies I can say with confidence — this is one of the biggest problem that software engineers face in the carrier. And we need a way to handle this problem efficiently.
But you may ask “I just need a simple app, why I should spend extra time on this?” Well, at the very beginning it may seem like spending a time on unnecessary, but believe me, you will save a ton of time and overcome a giant stress in the future. Even though your application won’t gain a huge popularity or it’s lifetime is very limited, implementing a flexible and scalable architecture for your app is a nice practice for your professional growth.
In nowadays, it doesn’t matter that you can write a code. What’s matter the most is writing sustainable and scalable code that developers will be able to maintain and improve seamlessly.
How to deal with it?
Okay, let’s think of app like a car. A lot of separate parts works independently from each other, serving their own purpose. If the headlight is broken, we can simply replace this part. Moreover, while its broken it doesn’t affect any other part of the car. Can you relate this to software development? Well, not always.
Imagine we have simple e-commerce React app with a product list page. Ussually, we plan to sell only sunglasses, so our API responds like this:
{
"products": [
{
"name": "Gucci sunglasses",
"sizes": [4.5, 5.25, 5.75, 6.25],
"price": 99.90
},
...
]
}So, seems good, huh? Customer can choose different size of glasses. But we also want to add different frame color. Now the response look like this:
{
"products": [
{
"name": "Gucci sunglasses",
"sizes": [4.5, 5.25, 5.75, 6.25],
"frameColor": ["red", "green", "blue"],
"price": 99.90
},
...
]
}Nice. But what if we decide to sell clothes? For example, there is no frame color on boots. Of course we can leave it empty, but after a while the API response will become a huge list of messy items. So, lets implement this in a little different way:
{
"products": [
{
"name": "Gucci sunglasses",
"attributes": [
{
"id": 163431,
"name": "Frame color",
"values": [
{
"id": 7143,
"attributeId": 163431,
"value": "red"
},
{
"id": 7144,
"attributeId": 163431,
"value": "green"
},
]
},
{
"id": 146143,
"name": "Frame size",
"values": [
{
"id": 7145,
"attributeId": 146143,
"value": 4.25
},
{
"id": 7146,
"attributeId": 146143,
"value": 5.25
},
]
}
],
"price": 99.90
},
...
]
}Pay attention, Attribute and AttributeValue are separate modules with their own purpose. In this context, Attribute serves like a category for AttributeValue.
Now it looks more generic and independent. We can put any item in the list and extend our market as wide as we want. Also, we can implement complex and flexible filter system for the app.
But wait, what if we want to change price only for red color? And how manager understand what attributes customer wants to be included in the product? We can’t do this now without any workarounds, because we have only one general price for item. So let’s change something:
{
"products": [
{
"name": "Gucci sunglasses",
"items": [
{
"id": 163431,
"name": "Gucci sunglasses Red, 4.5 size",
"price": 199.90,
"attributeValues": [
{
"id": 7143,
"value": "red",
"attribute": {
"id": 163431,
"name": "Frame color",
}
},
{
"id": 7145,
"value": 4.5,
"attribute": {
"id": 146143,
"name": "Frame size",
}
}
]
},
{
"id": 163432,
"name": "Gucci sunglasses Blue, 4.5 size",
"price": 149.90,
"attributeValues": [
{
"id": 7144,
"value": "blue",
"attribute": {
"id": 163431,
"name": "Frame color",
}
},
{
"id": 7145,
"value": 4.5,
"attribute": {
"id": 146143,
"name": "Frame size",
}
}
]
},
],
}
]
}Now we have Product and ProductItem. Each item belongs to one specific product, but at the same time they are different and have a unique ID.
We can go even further (like make product bundles, discount, etc.), but I think you got the meaning of the whole idea.
In the dynamic world of tech, where the only constant is change, forward-thinking can be the thin line between a system that gracefully evolves and one that becomes a convoluted mess of patches and workarounds. So, the next time you’re coding, take a pause, gaze into the future, and don’t forget to ask, “What if…?”.
Thank you for reading! Have a wonderful time :)