I cannot describe how important these things are. A startup's only advantage is speed, and once you do not have these principles in place, your ability to grow quickly is impaired. Unfortunately, you need either a genius or a smart adult in the room early on to achieve them. If not, the technical debts pile up so fast that Nigerian debt pales in comparison.
Love these points! I’ve shared the same advice with early-stage teams, and they sometimes dismiss it as “over-engineering” because they’re still small. But if you aren’t architecting for rapid growth after finding a problem-solution fit, are you building a startup or just a small business that hopes growth won’t break it later?
So yeah when I got to the end, a little voice in my head said people will say over-engineering and I said to myself it is not over-engineering. If you know what these principles are, have them at your finger tips it becomes natural to just build with them. There is no extra-work compared to not doing it this way and ending up with brittle systems.
Thank you so much for this, I have tried implementing this, but always will business needs go over technical/ engineering needs and that's where the issue lies
Essentially, true scalability is achieved by designing architectures that evolve with business strategies, eliminating the drag of inflexible code and enabling swift pivots or seamless integrations. Thanks for this write-up.
Asides from the fact that this a brilliant article, I love that a veteran is writing about these issues so the take can’t be easily dismissed since it’s based on experience.
Technical debt will slow you down more than your village people and I need more Devs to understand that we are all on the same team which is to move the business forward.
Also why is no one taking about the audio version 👀
I have a somewhat personal question that you might find a bit awkward, but I have a frame of reference for where I need the answer. For an enterprise-level business like Nigeria's largest telco, MTN, based on your experience, how does flexibility/adaptability manifest in their work processes?
considering they are already at scale based on market leadership.
Like most large companies, it can be a struggle. This is part of what the term ‘legacy’ refers to. But it’s understandable since one cannot see the future, unless you build like this (and some companies have) then you’re actually the one shaping the future.
lol. I honestly can’t tell if you agree with me or not. I too came from a ‘trench’ at some point. And engineering one at that. Let’s use experience to prevent avoidable and costly mistakes.
Anyone large or small can write code that limits their growth. And no, it’s not that different. These principles should be applied so that everyone’s ambitions - grand or not - can be met without the self-limiting thinking of coding for just today’s needs.
I cannot describe how important these things are. A startup's only advantage is speed, and once you do not have these principles in place, your ability to grow quickly is impaired. Unfortunately, you need either a genius or a smart adult in the room early on to achieve them. If not, the technical debts pile up so fast that Nigerian debt pales in comparison.
Hee hee. Truer words were never said. Thanks for reading
Love these points! I’ve shared the same advice with early-stage teams, and they sometimes dismiss it as “over-engineering” because they’re still small. But if you aren’t architecting for rapid growth after finding a problem-solution fit, are you building a startup or just a small business that hopes growth won’t break it later?
Hope this helps you keep pushing. Thanks for reading!
So yeah when I got to the end, a little voice in my head said people will say over-engineering and I said to myself it is not over-engineering. If you know what these principles are, have them at your finger tips it becomes natural to just build with them. There is no extra-work compared to not doing it this way and ending up with brittle systems.
Don’t mind them. Do what you should do! When you reap the benefits they will understand
This is so important and so often overlooked. And it can also apply to big (and non-agile) organizations. Great insights!
Thank you so much for this, I have tried implementing this, but always will business needs go over technical/ engineering needs and that's where the issue lies
hee hee.....use this to explain to them. I hope it helps!
Essentially, true scalability is achieved by designing architectures that evolve with business strategies, eliminating the drag of inflexible code and enabling swift pivots or seamless integrations. Thanks for this write-up.
Asides from the fact that this a brilliant article, I love that a veteran is writing about these issues so the take can’t be easily dismissed since it’s based on experience.
Technical debt will slow you down more than your village people and I need more Devs to understand that we are all on the same team which is to move the business forward.
Also why is no one taking about the audio version 👀
Top stuff 💯
I have a somewhat personal question that you might find a bit awkward, but I have a frame of reference for where I need the answer. For an enterprise-level business like Nigeria's largest telco, MTN, based on your experience, how does flexibility/adaptability manifest in their work processes?
considering they are already at scale based on market leadership.
Like most large companies, it can be a struggle. This is part of what the term ‘legacy’ refers to. But it’s understandable since one cannot see the future, unless you build like this (and some companies have) then you’re actually the one shaping the future.
Great question!
very insightful
This is so insightful! Build great small teams that'll turn into a big business tomorrow
Awesome! I really enjoyed reading this 🥳
Thanks,liked your view
This was so insightful to read and well-covered from different angles
In the trenches we know where the bullets are whizzing by. Experience ensures that mistakes are not repeated.
lol. I honestly can’t tell if you agree with me or not. I too came from a ‘trench’ at some point. And engineering one at that. Let’s use experience to prevent avoidable and costly mistakes.
Coding for small is totally different to Coding for Large. The latter requires disciplined engineering methodologies that have been tried and tested.
Anyone large or small can write code that limits their growth. And no, it’s not that different. These principles should be applied so that everyone’s ambitions - grand or not - can be met without the self-limiting thinking of coding for just today’s needs.