Comment by mbesto
17 hours ago
> but it took me 18 years to grow the user base , figure out entreprise sales strategy and exit.
The audience here has never wanted to admit that the codebase doesn't really matter. Now that codebases can be created in a weekend, people are opening their eyes to this sentiment - the hard part is the sales, the code is easy.
Great code is still not easy. Choosing the right stack/libraries/billing and getting everything to work together (for cheap) is still something barely 10% of devs can actually realistically do.
Sales is hard, yeah, but look at everyone claiming to be building something amazing and it ends up 9 months behind schedule or just being an buggy, untested version of something that already exists in the market.
Great code has never been the requirement of success.
Throughout my career no software that hits $100m annual revenue was born from great code. That’s 2 fortune 100 hi-tech companies with other medium sized companies with revenue close to $1B.
There was one company that had better codebase than the others, unfortunately that company struggles to hit $2M MRR…
Looking back, it was painful to admit that code quality was not how the company succeed: it was overall strategy and luck.
Most of them can't. It's just a few products like speed testers and social media that are at least surface level easy. You can't vibe code up a triple A quality game in a weekend.
To be fair, triple A gaming lately has been something of a letdown. That does not invalidate your point exactly, but it does mean that the tastes of the gaming audience might be changing ( we kinda were in similar spots before ).
> the codebase doesn't really matter
Sigh.
I’m sure the viewpoint from being in mergers and acquisitions is quite different (and to me, often comes across as quite callow). I’ve been a software developer for 35 years (closer to 45 if you include my pre-professional life, aka adolescence) and have deliberately stayed “on the tools” in my career with working in codebases and product development as I’ve found that is where I am happiest and can make the best contribution, rather than move up the managerial ladder to my level of incompetence, to quote Peter.
To create a successful product in IT, or any industry really, it takes a lot of different skills, facets and (often competing) priorities. And those priorities do change over time. I’m sure by the time a product or service crosses your desk, the codebase quality is not as big of a priority. Earlier in the life cycle a shit codebase makes for a shit product that is a lot harder to grow and maintain — so much so that most of them have probably folded before they reached the stage of looking to be merged or acquired. I’ve dabbled in sound mixing for live performance and when training others I’ve mentioned the fact that it very hard to make a bad singer or musician sound good, but very easy to make a good singer or musician sound bad. Same goes for trying to make what would otherwise have been a good product or service with a bad codebase. That’s really hard and creates a hell of a lot more work for every part of the business.
I’ve had sales people tell me to my face that they are the most important part of the business and the actual product or services is not that important. And in my more callow stages of life experience I’m pretty sure I’ve reciprocated with words like useless and parasitic, and that I could replace them with a small bash script. But in reality what we all do is important to the complex endeavour of developing and maintaining a successful product or service. The existential threat of AI is moving up the ladder of incompetence and changing the face of what we do. It may even jump a few rungs in the process. But it’s not there just yet. Keep making good sales, keep making good mergers, good products, good acquisitions, good services, and good codebases.
— No tokens were harmed in the production of this comment. —
I think this perspective benefits from experience, the ability to step outside one’s self, see that the world is complicated, then focus on the thing you enjoy.
As much as I agree with you now, I also accept that younger me wouldn’t have!
Very well said.
Your argument is sound. It certainly takes a good deal of skill to create good code. And yes, good code makes it easier to create a better product.
And yes it's easier to build a better company on a better product.
But history is littered with "worse products" that won in the marketplace.
It turns out that all the attributes you name are helpful but not necessary. Good marketing trumps good product. We see this over and over again.
The best combination is good marketing and good product. If I can only get 1 of those then I'll take hood marketing. Equally if you have a good product but bad marketing you don't get many (if any) users. The "ask" section on this site is littered with that.
So, assuming we can all make "good enough" code, the code doesn't matter. It's all good enough. The distinguishing feature is the marketing, because that leads to market share, and that's all any company is really selling (once it sells for a lot).
I'm upvoting you because your comment is well made, and certainly common, even if it is incorrect:)
Having been involved in multiple different acquisitions, on both sides of the table, I can anecdote that the code quality had no impact on any part of the acquisitions. The players are not buying or selling the code.
> So, assuming we can all make "good enough" code
Your entire argument hinges on "good enough". Problem is: you can never know if something is "good enough", except in hindsight for those products that succeeded.
I'm upvoting you because your comment is well made, and certainly common, even if it is nothing more than a tautology :)
1 reply →
Marketing without a product is called a scam. Marketing with a "good enough" product to sell it is the same.
I've been in an acquisition where code quality was important. But it was probably an edge case since the buyer just wanted to turn the company into a feature, and ease of integration into the buyer was important.
Sigh.
Bless your heart.
I'm not sure anyone was operating under the idea that a speed test website's code was the hard part.
[flagged]
> The audience here has never wanted to admit that the codebase doesn't really matter.
Are we talking about speed testing websites or the code that controls space vehicles? Perhaps extreme generalities do not provide useful insights.
> Now that codebases can be created in a weekend
Now that corporations are whitewashing copyright off of code so you can steal it without conscience.
> people are opening their eyes to this sentiment
Code is the product. Engineering is the discipline. That you can achieve high sales without good engineering is not a new idea. That it only provides short term benefits and leaves you irrelevant in the long term is the actual sentiment.
> the code is easy.
Coding has been easy since Perl was released. Knowing _what_ to code is the problem.
> Engineering is the discipline.
And even that is very rare in the field of software development.