Approaching the System Design Correctly!
Let’s talk what are the approches we take to design a system from scratch!
What are the ways?
When we are designing a system, we go by; that there are two ways of doing it, either you have the perfect design in place, which is scalable, reliable, efficient, cost optimised and covers all the edge cases even the one which have a chance of occurring one in million and also consider the future use cases that may come. Or you may design something that works for the current use case, is scalable, efficient, reliable and cost optimised keeping the current conditions in mind and covers only the edge cases as per the current use case.
Now this former approach take a lot of time, multiple discussion with product, you should be aligned with the team vision and should be able to think what can come next. But the later one will take less time as you will get the specific requirements clearly stated at first.
We are all happy!
Most of the people will be happy with the later approach, as you will have timely deliverables, consume less bandwidth and require less brainstorming. And with the fast growing competition and technology, it do make sense. You can improve as you go with the feedbacks provided to you. So in case to cover this specific use case and deliver in time, we might intend to create some backlog, to improve it further if the need comes.
So whats the problem?
But, the real problem comes when, when some of the requirements were not clearly stated or clearly understood or some of the edge cases were never thought, now you will add all this fixes or improvements in you back log too. And the twist here is, you have the new set of requirements and timelines coming your way. So, now you may not be able take on the tech dedt along with the new sets of requirements to deliver and still match the timelines. So either we ask for more time to clear the tech debt as well as deliver the new requests or we implement just something minimal that fixes the issues in system and deliver the new features in time. Thus at the end adding more to you back log, along with the bugs this new deliverables will add. And this goes no, in this fast going deliveries you end up having a bad system and increased tech debt. And forget about pivoting from your whole design or technologies you used now, you don’t have time or resources for that.
What to do then?
The conclusion here is, you can’t work like develop minimal and improve over time, coz you are delivering in less time, nor you can take more and more time to design a perfect system, as that much time we usually don’t have and the we don’t have all the requirements clear from the start. So, you have be in the grey area and think to get something minimal but also keeping in mind what next will be coming, what’s the vision of this product and what all can go wrong, try to cover as much as edge cases as possible, even if require slightly more time, than provided. Do you agree?
One thing we have to keep in mind is NO system design is PERFECT and every system is prone to errors.
Let me know if you agree and also share your feedback, so as I can use that to improve in the next iteration :) . Thank you all, keep developing and designing.
