The open-source software community is a beautiful thing. As a kid, I was amazed by the universe of software available to play with and learn from. In the early 2000s, I read an online article about Unix. I bought my first FreeBSD CD and installed it that day. I was blown away. So much documentation existed. People from across the world built every piece of the system. The code was there to study and improve. Thanks to the internet, version control systems like CVS, SVN, and SourceForge.
Engineers built the web we know through their passion and by sharing developments. Big companies only joined open-source later, supporting projects, for better or worse.
Today, most developers use Git — a version control system tracking file changes, enabling collaboration. Linus Torvalds, creator of Linux, an operating system powering most of the internet, developed Git in just 10 days, nearly 20 years ago. It revolutionized how engineers work. We rely on its efficiency.
Isn’t it amazing that something created so rapidly 20 years ago is used by almost every developer today?
The Myth of Overnight Success
This is exactly what I want to talk about today. I had a debate with a friend about this recently, and there’s a big problem with bold statements about famous software products built rapidly. They create unrealistic expectations. “Git was created in 10 days” — well, a very rough and basic prototype was, just around a thousand lines of code. It was so basic that it barely had any business logic.
My friend recently finished a startup bootcamp and decided to switch to tech, as many do nowadays, to become an “intrapreneur” and drive internal startups at the company she joined. She’s reading all these stories about how X was built in Y days and gets the impression most engineers are frauds who waste time and money, while a select few can rapidly develop like this and should be sought after.
I want to reiterate these are false narratives. Sure, PageRank algorithm might have been coded quickly, but that was after years of research and work developing BackRub, Google’s early search project. Building the product and company we know today took so much more time and effort. It is unfair to say Git was created by Linus Torvalds in 10 days — it leveraged approaches used by other tools like Bitkeeper, and thousands of hours of work by other engineers who improved the product to become widely used.
There are more examples — Twitter was built in two weeks, Trello in five days, and Apple in a garage in a month. Dig deeper, and you find it’s all myth.
Here’s the truth: version one is the quick and easy part. The real work comes after finding product-market fit and iterating. While v1 and fit are the goals for early startups, inexperienced managers need to know there’s more beyond that.
The real work often involves completely rebuilding the minimum viable product. I did that a lot for startup clients back in the day — scrap v1 and rebuild with learnings.
As one entrepreneur told me, “Getting version one out was a sprint, but building the company has been a marathon.”
Great Engineers Are Not Just Fast Coders
Quick wins can be misleading. Great developers don’t just write code fast. They find solutions no one else can. They understand the impact of those solutions and take responsibility.
The most valuable engineer may write no code. They coach teammates on the product. They help managers and engineers work better together. Or they slowly rewrite core systems. This lays the foundation for future features.
Managers often expect engineers to quickly build great products. But custom software takes massive time and money.
Our team spent over a year rebuilding the backend once. It was slow and expensive. But afterward we could scale to a million users with no problem. Our patience and focus paid off.
On the other hand, it’s true that engineers sometimes focus too much on best practices over business needs. They may complain management won’t let them follow the process they want for the sake of building things faster. But for the business, speed of delivery is one of the priorities, and it can’t be ignored.
The key is finding a balance, as it often is. Striking this balance between quick solutions and perfect solutions takes experience. Experience in both engineering and managing projects.
What happens if you lean too far in one direction? Going too far toward quick and dirty solutions will leave you with products that feel like prototypes. They likely won’t last long. But going too far towards best practices and perfection causes insane delivery times.
How do successful managers find the right balance? They likely ask themselves questions like:
“What is our minimum viable implementation?”
“What are the core pieces of functionality that will delight users?”
Rather than trying to solve every problem and add every bell and whistle, focus on the essentials. This leads to quicker time to deliver without compromising quality.
For example, you could focus each release on just 3 key features. This allows you to release faster. Customers will love it and be eager for more features in future releases.
Striking the right balance takes experience and judgment. The goal is to avoid both the pitfalls of a quick and dirty approach and the endless delays of perfectionism. Keeping the user experience and expectations at the forefront can guide you.
Originally published on Medium.com