Time-Sinks for Tech Startups to Avoid
--
For a sizeable subset of the developers out there, working at the cutting edge is much for attractive than doing things the traditional way. This kind of tech workers, who have a passion for the work they do, have a mutualistic relationship with the startups. They thrive in the turbulent and dynamic atmosphere of a new business, as they are usually home to many exciting decisions and opportunities. And if you are an entrepreneur who is currently gathering up a crew for your bright idea, you’re going to need people like them who share your level of enthusiasm.
This article is not about merits of such minds, as I don’t think this is news for anyone out there. I will assume you already have a decent gang who wants to create cool things . It will be about one of the possible tendencies of such ambitious craftsmen, something that could pose a risk to the success of your venture that you should be wary about. Simply, over-engineering.
Roman Aqueduct Argument
The concept of over-engineering, building things in an unnecessarily complicated manner that will give you no benefit regarding reaching your targets; or ignoring YAGNI principle, spending time to add features you ain’t gonna need are traps to be avoided in every case of development. But for startups on a tight schedule that needs to act fast on present opportunities, these mistakes could be the difference between life-death depending on costs.
Let’s go a step further. Think about the roman aqueducts. Pinnacles of construction, aren’t they? They’ve been standing for thousands of years, while their contemporaries are lost in time. But is it a good idea to build something that you won’t be able benefit from for the overwhelming majority of its lifespan? Dare I say it, is this a case of bad engineering? I don’t know if that would be fair, but Romans had the luxury to build those just to say fuck you to other civilisations throughout history. As a startup, you probably don’t. So let alone unnecessary complications or unneeded features, sometimes even building things to last, when they don’t suppose to, might be a bad idea.
How Can I Tell Something is Unnecessary?
Well, you can’t sadly. Best you could do is challenging your developers for explanations of decisions with an apparent significant cost. Little pieces of complexities that no one can see without looking at the code should be manageable and trusting your teammates should be your first instinct either way. If you don’t have confidence in them to make the right decisions after a meaningful conversation, you’re either approaching things the wrong way or have the wrong teammates. What I’m going to do in this article is to help you out by listing few of the costly attractive concepts that should raise your eyebrow and trigger some of those conversations.
These are Bad Ideas (Except When They’re Not)
1. You don’t need MICROSERVICES
This is the big one. Oh yes, you definitely don’t need micro-services. Whatever the reason, you just don’t need it. But, but, to be scalabl- NO! It’s simply impossible for a startup to have micro services as a viable architecture initially. The operational complexity that comes with it, handling of transactions, and all other hardships that are a part of distributed computing are in no way a meaningful tradeoff for their benefits to any company trying to get its bearings. Especially without having a robust dev-ops infrastructure with good monitoring capabilities, you’re guaranteed to suffer for choosing micro services.
Encourage your developers who are very adamant about using micro-services to create stateless, loosely coupled systems. When done right, they could be broken apart into their components in necessity.
What is microservices to begin with?
**In another forum I shared this content, the question of what is microservices came up. So I thought I should update this article to provide a little bit more context to people who are not that involved with the tech side of things.**
Microservices is an architecture where you approach the backend side of your product by creating lots of little applications that communicate with each other, rather than having one big application that handles everything. Although there is no agreed definition and we can’t determine line of code limits for some application to be considered one, superficially we can say any back-end layer application split into several deployables with ergonomic reasons could be considered as having a microservice architecture.
While there are big benefits of doing this in regards to being able to scale, maintain and have much-needed agility at a certain point, that point is too far off in the future for most of the new businesses.
In practice working with microservices, especially without a crew with the necessary know-how, or ability to handle, monitor and manage complicated architectures means; complicated initial infrastructure, harder development, harder debugging, harder testing, harder exception handling, more regressions, complicated data consistency handling. Yes, your solutions to these problems, although hard and time-consuming, will stay with you. And if your project lives on long enough and gets bigger and bigger, you could start to see the benefits of your initial investment. But that does not mean making this bet is a sensible one. Because it doesn’t benefit you compared to alternatives even if it’s a one you win.
If you indeed succeed, it will be much easier to go down that road with the rich resources that you have at that point anyway. You’ll probably do a much better job with the experience you get along the way, and you’ll know your product better. That’s the reason curbing your enthusiasm and waiting for the right moment for architectures as such is almost always a better idea.
2. You don’t need BIG DATA
Another still popular buzz-word that peaked around 2015 is big data. It’s a vague concept in the way that it could mean a variety of things but doesn’t matter. First of all, ask yourself this: do you have any data at all right now, let alone big data? Yes, you have big ambitions. Yes, your venture will one day rule the world, and ruling the world comes with worlds of data. But until you do, you probably won’t need any tools and tech that provide solutions comes under the umbrella of big data.
An average new business with a reliable financial forecast usually breaks even around three years. So, common sense says, even in the very rare case of everything going just the way you expect them to, you’re going to have some time until you have some users who will cause some big discussions regarding data access.
3. You don’t need DATA MINING
This one is a little bit different, in that it’s not just a technique but more of a feature. So this could be thought also as a business decision rather than a strictly technical one. There two things to consider about data mining before going down this road. First, just like in the case of big data, you’re going to need some data to mine. Second, standard features that are enabled through data mining are usually complementary features that feed into your core business. So until you are sure that your core features are working as expected, and there is enough people using them, delay spending some time and money on data mining.
Well, of course, there are obvious exceptions. Your business could be making use of already available data. Or analysing other people’s data could be the central part of your value proposition. In those cases just pretend I didn’t say anything.
What Do You Need, Then?
You could encourage your IT team to spend some time on a CI platform, shortening your feedback loop from the very start. This should be easy enough, and should make things comfortable for pivoting. Or make sure everything is stateless and loosely coupled, as it will make it easier to build on your foundations when things start to get complicated. Of course, there will be a time and place for the concepts in this article to make sense for you. You’ll just need to make sure your crew contains their excitement and waits for the right time.
Once again, thanks for reading. If you liked this one, I suggest checking out the previous articles on how to price your new products and services, or the one about underappreciated worth of marketing ideas. If you think I got something wrong, please don’t hesitate to respond. And if you got anything on your mind you want to talk about, you could always ping us at contact@refineri.co.uk. Cheers!
A. Berat Daglar
REFINERI Consultant
https://refineri.co.uk
