Throughout my software development journey, I had a lot of different adventures. In fact, I started my custom software development company at the age of 19, with a friend, while attending university. During the last 10 years, I have seen a lot of projects, from customers’, to personal, passing by a spin off startup that we created inside our company. One motto we’ve used a lot is: Better be wrong than late.
What does this mean? Let’s start with an example. We had an early client who wanted to create a small project. I was 20 years old at the time and had almost no managing experience. He is the kind of old wolf with a lot of experience, but a shy person. His budget was $10k, which is small, but it is big for someone starting from the dining room of his apartment (Where we had the meetings).
The good thing is that he knew exactly what he wanted; a small application to survey anonymously with short quiz a fair amount of people in each department of companies of 1000+ employees, mostly when there is some good or bad major internal events. He is an independent consultant in human resources and he wanted to use this tool in his existing customers’ companies.
It was easy for us for a first contract of this size, even if we ended up being paid approximately 5 dimes per hour. At least, the customer was comprehensive and he wanted this project on a short budget and in short delays.
He did not seem to lack money though, which raised me some questions; why being so low budget on that kind of project if you’ve been in business for the past 40 years and you come to me “office” with a brand new Mercedes-Benz. Easy question, hard answer. But I had my luck understanding what happened in his mind and it helped my company and our customers for the next 9 years.
His last tech project went bankruptcy. They invested 2 million dollars of private money on a project that they rewrote twice and that did not even get to market. When they tried to onboard early adopters, they had so much request they did not think of and they had so much work to do that the investors decided to stop providing. They were already late, and they were also wrong.
When starting a project, you need to target your MVP (Minimum viable product) and it should be very minimal. Why? Because when you design this product, you do it with what you know and the vision of you and your team. When you onboard customers, they will for sure bring you comments, ideas, needs and much more that you did not think of at the beginning. More than that, they will tell you totally different needs than what you planned. And now you are stuck with 1 year of coding and you are not even ready to introduce new configurations to your project, but you want the early money so you do it anyway.
Here comes in the beginning of the technical debt. To make it short, a technical debt is when you take the decision to do your coding fast instead of good and later you are stuck with a huge pile of code that nobody totally understand. Most big projects has it. Some projects even closed for this reason.
You have to consider something: What you need is not always what people needs. The worst thing to do is spending so much time and money on something for later to find out that this something is nothing. This is why you are better to fail early. As Will Smith said: "Fail early, fail often, fail forward". This way, you can adjust faster.
A lot of tech projects are the fruits of early failures, a melting of luck and determination and sometimes a naive approach. For example:
Twitter; Jack was creating a geolocation app for courrier when he joined the company Odeo. He was inspired by fast and concise communication sent to a group of people like an sms but more open to the world. They brainstormed, created a simple version of Twitter and it was adopted early, even if there was close to no functions except broadcasting a 140 characters message.
Slack; Daniel Stewart Butterfield ran many software companies, mostly in game development, but also including Flickr, the image hosting service. In fact, none of his games were a success, but some companies were interested to use his internal messaging app used for communication between teams member, but also to receive external messages from build servers, error logging and much more. Here is born Slack, out of an internal simple tool.
If you have a project, bring it fast to market, even if you think that the functionalities are not worth being a product, and then add no features from the comments you get. Even if it starts with very few users. You will be rewarded way more than if you build everything, wanting to make a perfect launch, and then you enter the infernal loop of coding unexpected addons.
What you really need is simple:
- A good software development team, or at least you being fully in control of the technology you use.
- A good organisation: Development environment, staging environment, good testing and a stable production environment with a lot of monitoring.
- Good DevOps; I read an article about how Etsy went from little massive deployment to deploying many times everyday and being reactive to bugs.
- A niche that needs improvement.
- Patience and motivation.
Just get started, you will see, it is fun.
Top comments (2)
"Code is like sex, one mistake then you have to support it for the rest of your life."
It's a tradeoff, if you can support it for the rest of your life, then better be wrong than be late.
But if you can't, do not.
Ok, 3 years later, that comment made me laugh.