8 ms·

Every software project is a startup that will probably fail

130 points by pimterry 3y ago

itissid 3y ago
Oh yes. If you look at the number of software products that have failed at Meta you will cry in joy or intrigue(or both). Possibly why "Move fast and break things"(or acquire if all else fails) is the only way the money train keeps running and one could argue is the only time tested mantra for everyone in product space who, even for a moment, thinks about "sailing into the sun" with the ultimate and final app.
mikhailfranco 3y ago
Wow, honest experience and good advice. Aligns with my extensive experience with startups, later stage venture-backed sw companies, mature public ISVs, and well-established multi-national margin-optimizing system integrators (SIs). Most of them act (pretend) as if they are in one of the other categories, so they never have the self-knowledge required to apply the right rules to achieve success.
code_duck 3y ago
Sure, one could say the same about artists, restaurants, musical projects, or tech blogs. A high level of success is only achieved by a small fraction of projects, which is somewhat mandatory as there is not room for every endeavor to be a smash hit.
- hgsgm 3y ago
  Even a gym subscription is a startup that will probably fail. Almost everything new is hard.
- mikepurvis 3y ago
  And lots of things deliver value and bless people along the way. Even a restaurant that eventually "fails" still employs staff, feeds patrons, purchases food from suppliers, and all the rest of it. A thing doesn't have to achieve a shoot-the-moon ending in order to be a non-failure.
  - code_duck 3y ago
    Indeed, that’s what I think about ideas like “Twitter wasn’t profitable” or “the post office loses money”.
    - mikepurvis 3y ago
      The post office losing money is especially ludicrous because the post office is not a business— it's a public service. It should be obvious to anyone who thinks about it for two seconds that the post office is financed from the general tax base, same as libraries, highways, parks, defense, airline bailouts, and all the rest of it. All of these are run at a loss because it's worthwhile living in a society that enjoys the benefits they provide. (And in the particular case of the USPS, it's literally enshrined in the constitution because it was seen as a pillar of democracy to be able to securely communicate with others over long distances.)
      - drdec 3y ago
        > It should be obvious to anyone who thinks about it for two seconds that the post office is financed from the general tax base This is not true in the US, the post office budget is separate and not subsidized by taxes.
- danjac 3y ago
  Moreover success depends on factors that may be tangential to the quality of the project. I have had more Github stars from low-quality "throw over the wall" projects that just happened to use whatever framework/language was cool at the time, as opposed to projects that I have put more effort into but used more "boring" technologies. As with a startup, if you catch the wave at the right time, you can succeed with a relatively low quality/effort project. But that depends on what counts as "success". If you are looking at just money or Github stars (or whatever the equivalent is in art or music) then that's one measure, but success could mean learning, personal satisfaction, something that helped or inspired someone else, the praise of a few people you look up to, or a job opportunity.
black_13 3y ago
[dead]
RajT88 3y ago
To look at this through the lens of an entrepreneur, "failure" is a relative term. If you learned something which contributes to your future success, it's hardly a failure. I have lots of defunct personal software projects that "failed", but all of those failures make me pretty good at my day job.
- mwbajor 3y ago
  Why do you need to finish a project? Is not finishing a project considered "a failure"? I have 100's of projects too I never finished but they typically morph into something else or I realize it was a bad idea. I think not having that would mean failure and it seems these true failures are rare.
  - compiler-guy 3y ago
    Or I started on them, learned what I needed to learn or what they had to teach me, and then I moved on before finishing all the mundane parts. Still learned a bunch and figured some fun stuff out. That's not failure.
JohnMakin 3y ago
It's not a 1:1 comparison for software vs startups. The major difference being that the startup model is -> get a ton of investment based on a prototype, THEN try to figure out how to mature it and monetize it. Whereas lots of software projects have a direct path to revenue already.
zzbn00 3y ago
Developers are gonna develop... I agree if you give them a "new" software project risks are high and chance of success surprisingly low. Making do with existing software often better choice.
GMoromisato 3y ago
“All software development is R&D. As soon as it’s no longer research, it can be automated and the human work goes away.” To me, this is the First Rule of software engineering. We take it for granted, but seeing things through this lens explains so much, including (e.g.) the potential benefits of LLMs.
- chinchilla2020 3y ago
  In practice, the maintenance side eats up far more man-hours than the R&D side. Every software project has a shelf life except for a handful of very low-level ones that have survived the ages. All projects need maintenance until they reach their deprecation date.
  - danielvaughn 3y ago
    I like saying the following: the difference between writing software and maintaining it, is the difference between raising your hands in the air and keeping them raised indefinitely.
    - pschuegr 3y ago
      i like that - great way of thinking about it.
    - paulryanrogers 3y ago
      Maybe more like raising a box onto a shelf in an earthquake zone. Then keep it on the shelf despite ground moving underneath every so often.
  - fuzzfactor 3y ago
    The thing about R & D is that most of the time what's needed is overcoming difficult but important milestones if not accomplishing actual major breakthroughs. Failure on the preliminary R & D can be a complete show-stopper before you even get started. OTOH with such limited, poor & incorrect documentation pertaining to the hardware & software, especially in combination with each other, a strong background in the Experimentation & Discovery aspect of R & D is often the only way to achieve your objective when the intended initial logical approach fails to perform as it is supposed to do. This need can penetrate beyond maintenance all the way to end-of-life. One reason maintenance can chew up so many man-hours.
lakomen 3y ago
All the positivity. If I listened to the naysayers, I'd be nowhere. I won't even read the article. Motivation is a key requirement. If you don't believe in yourself and/ or your product, you might as well quit everything. Posts with titles like those are, for me, toxic, and I'll flag it.
- crickey 3y ago
  You sound like someone who hasnt worked very long in the industry. Being realistic anout failure allows one to build better products. Simplicity and maintainability and most important replacability. Allows a software to fail and not the business
  - aeze 3y ago
    Neither of you are wrong, but it depends on where you're at. You need enough motivation to get across the finish line and ship a product. Many, many people fail here. If you're able to ship you need to be realistic about failure so you can iterate your product or move onto the next one with lessons learned.
dvt 3y ago
> If I were an executive sponsor of software initiatives, for example, I’d want to take some of the lessons from the VC world. I’d expect, and plan for, projects to just “not work.” I’d bake that into expectations all the way up. In any decently-run company, this already is the case. Most customer-facing projects are treated as startups that will fail (most do, some don't). I think expectations are well-balanced... but compensation, on the other hand... > And more importantly, I’d want the developers of the project to have skin in the game to compensate for the risk. I’d want them to share in the upside risk, just like early startup employees do with their stock options. Because in the absence of that kind of incentive and risk management structure, what I see is sort of the worst of both worlds (software and corporate politics): new software products usually fail but nobody wants to take the blame, resulting in pervasive fraud and willful ignorance and shame and scapegoating and bitterness. This hits the nail on the head. I remember working on a customer-facing product at X company about a decade ago. Our team was small and scrappy, and we were able to build a product that would eventually bring in $2M/month+. It felt very startuppy: we were regularly staying late at the office, getting takeout in the wee hours of the night, doing swarm sessions, war rooms, etc. I will say: it was engaging and fun. But what was our reward? A few months later, we got some cheap puffy jackets (estimated cost: $100 bucks) and a slap on the back: "good job team." Companies will never let you share in the wealth. Why? There are enough suckers out there that are more than happy with six figures (when they should be making seven). I was already enamored with startups since my late teens, but after that experience, I truly realized corporate upside is basically non-existent unless we're in a market bull run. The year after, I quit and started to solely place my bets on my own startups. In fact, the downside of betting on your own startup is fast converging with the downside of working at a FAANG or BigCo. Job security is shot (layoffs galore), perks are eroding (WFH, etc.), so what's the point? Best of both worlds is probably taking a BigCo salary and attempting your own thing on the side. (Obviously, young kids, spouses, debt, etc. can change the equation substantially.)
- gnarcoregrizz 3y ago
  Yep. An employee won't see any upside of the project they're working on. There are no incentives besides some nebulous promo dangling ("we'll see where you are at the next review cycle...") , and usually no way for employees to capture the upside of their project. I created something valuable for the company I work at, and I was left without upside - just my salary. Meanwhile, the people with stakes in the business say, "well you're making a salary," while they are buying new homes. Engineers - you are capable of creating an extreme amount of value that far exceeds your income. Take care of #1.
dangus 3y ago
The article assumes failure as more likely than not, but that’s not what the numbers say. I took a new ventures college class focusing on high tech startups and the statistics were more like: most startups get acquired, some IPO, and a small percentage fail. Software is one of the most profitable industries out there. Just look up margins compared to other industries. Now, I realize the article is talking about projects and not companies, but what’s the point of that? Example: A typical car company loses 100% of the money it puts into their infotainment system software. But they make a bunch of money when they sell the car.
- bogle 3y ago
  I think your ventures college class wasn't taught by someone with real experience. The rule of thumb is more like a 50% failure rate each year. Software may buck that trend. Here's some data that shows just 1/50th will exit in 5 years [1]. [1] (https://www.beauhurst.com/blog/startup-fail-scale-exit/ https://www.beauhurst.com/blog/startup-fail-scale-exit/)
- fakedang 3y ago
  Lol, more like 90% fail (including acquihired), 9% get acquired, and 1% IPO.
eagrwl 3y ago
I don't know if giving developers more skin in the game is the appropriate response to this. I do think they should have skin in the game for their work but I just think it's unrelated to this thesis. Most developers don't really have a material impact on the success/failure of the project. And that's because my inclination is that most software projects fail not because of some technical reason, but because it couldn't find product market fit. That's not something that's really on the developer. In fact, I'm not sure it's on anyone. There's inherent risk in every project, and the team's job is to maximize the probability of success. At least that's the way a process-first person would probably think about it. Results-first folks might argue that a great team will find a way to succeed. And then definitely, having more skin in the game will help with motivation. But I still think even the best team is just maximizing probability of success, and still they're more likely than not going to fail, because getting PMF is hard.
- shusson 3y ago
  > …it couldn't find product market fit. That's not something that's really on the developer Why is it not on the developer?
  - hobs 3y ago
    Because in the (fairly wrong headed) world of today, the developer is told what to do by product folks and they mostly do it. That alone gets you to situations where the devs can see it obviously won't work, but the incentives and the egos are setup so that your job is just to build it, not critique it.
codingdave 3y ago
> To clarify, by “project,” I’m talking about something that’s large and customer-facing. Not a back-end Unicode migration or new integration test system or a plumbing job to redirect data flows or some incremental new feature on an existing product. Well, sure, if you restrict the definition of "project" to large high-risk software development, it may be true that most may fail. But in addition to the large projects under my belt, I've built literally hundreds of small, safe apps that offered incremental improvements to existing business processes, and they almost universally succeed. So I'd have the opposite conclusion of the article. No, don't learn from VCs. Don't aim high and expect to fail. Don't look for large projects and expect them to transform your business. Do look for the small steps that take you towards your goals, and work the ones that have the highest impact for the lowest risk. And in all honesty, most of the software work in the corporate world fits that mold. It just doesn't get any press because it is boring. Stable, but boring.
- hedgehog0 3y ago
  Do you have any advice or suggestions for college or graduate students who are not in industry, but interested in producing “stable boring” software business? Thank you. Added: With background in math and (theoretical) computer science.
  - pphysch 3y ago
    I was trained as a mathematician but now focus mainly on developing "stable boring" software. Note that "stable boring" software is almost never "correct" from an academic perspective. The software is stable not because it has achieved theoretical perfection, but because it has been hardened through countless cycles of iteration, debugging, and customer feedback. The "boring" parts. My #1 advice would be to get a foothold ASAP. University IT/other IT departments can be a good starting point. Even if you don't start out as a SWE, any sort of systems-facing role will get you valuable domain expertise and you will 100% have opportunities to automate whatever work you are doing and eventually graduate into full-time development positions.
    - 3y ago
LaserToy 3y ago
I love the topic. My view on the companies: they are similar to countries in terms of organizational complexity. And the way companies are run are similar to the way countries are govern. Mostly due to the fact that there are not that many ways to manage groups of people or individuals. So, I’m not surprised the observation about startups also applies
deleted 3y ago
[deleted]
winternett 3y ago
We wonder why modern projects fail and somehow emerge as features incorporated into major products from big companies... It's because we store our ideas in knowledge bases and social platforms with backdoors on them, and we communicate on platforms run by powerful competitors (cough Gmail). We live in the age of silent espionage, where large money hoarding monopolies control information and silently monitor trends. That information is also used to crush competition at the ground level. Even your notepad application talks to the Internet... Your social media posts get consumed by crawlers, that report your ideas back to companies with large teams of devs that could easily spin up a clone of your idea 10 times faster than you could. It's at the point where writing thoughts in a notepad (on paper) will be the only way to keep them somewhat secure... Then of course, you need to be able to fully develop your ideas totally offline, until you're ready to launch... But then even after go live, you'll need to rely on those same systems that work to reverse engineer your best ideas, or to sell them in secret to your competition... We're doomed perhaps... As an independent software maker, you compete instantly with companies that run powerful espionage platforms, and that have money and human resources that can easily crush you, along with legal teams that can ensure you spend the rest of your life in a courthouse battling for ownership of your original brilliant ideas... Maybe it's time to just return to entrepreneurship that doesn't involve software development, or jurnalism, or anything online for that matter... Even our calculator app snitches over the Internet on us now, and it's far too late for an aging and very non-technical Congress to reign this shady brand of innovation espionage back into anything protective of our rights.
- twosdai 3y ago
  I don't really get this idea that companies can be so vastly competitent and incompetent at the same time. People make new products, if they make something that people want, it gets noticed. Eventually those with a lot of money come along and try to figure out how/if they can also make money on the same thing. It's not some vast conspiracy.
  - winternett 3y ago
    You should take some time to look up the current dockets for antitrust cases before making simplistic statements like that. No one said anything about conspiracy... Anti-competitive business behavior though is definitely real, and growing for people that know about it through experience. Your lack of knowledge concerning how business actually works is apparent in your post.
indymike 3y ago
Software decays, some of it faster, some of it slower. Aside decay, we periodically have extinction events, like the switch to the web that killed a lot of thick client software, the shift to mobile, and even the shift to AI. Sometimes it's something mundane like fixing how time is tracked (Y2K) or ASCII->Unicode. To survive, software must have enough developer time to offset the decay and weather the extinction events. Hosted as a Service software has an additional pressure: the cost of hosting and additional maintenance pressure from forced updates. I think a lot of us, and a lot of customers don't really think about decay and extinction events as much as we should.
deleted 3y ago
[deleted]
thoughtsimple 3y ago
Most of the software I’ve written has gone into hardware products. Currently working on an embedded Linux system and writing a UI in ReactJS. We are late but only by a couple of months and I have every expectation that the software will be completed. The product has pre-sold about $1M already. If you want to be working on shipping products, work on embedded stuff. I’ve done customer facing business software too. Still mostly successful but that is where I’ve seen a few failures. One project I did was writing automated functional/integration tests didn’t see release but I take no blame for that one. The tests worked. The product didn’t.
jongjong 3y ago
My strategy around this is to make it so that every project I make builds on top of the previous one. My first project was a WebSocket client/server for developers, second one was a multi-blockchain ecosystem built using the WebSocket server/client, then I made a decentralized exchange to connect the blockchains. My current project is a no-code SaaS platform; it's being built using my WebSocket client/server and blockchain ecosystem as the auth and payment layer. When that fails at monetization, my next project will be to use the SaaS platform I will have made to copy successful existing SaaS platforms in various niches via a cryptocurrency-based subscription model. Then when that fails, my next project will be the lowest risk one, I will use all the stuff I built to offer contract-based development services to individual clients. When that fails, I will try to get into politics or write a book about failure.
- tough 3y ago
  I like the spirit jongjong
tmpX7dMeXU 3y ago
Honestly, from my perspective, and from anyone else not elbow deep in the VC-driven startup hellhole, this post reads absolutely insane. Why is this the only lens that you can look at this through? It feels…unhealthy.
Uptrenda 3y ago
Overly cynical neckbeard post. Didn't read.

130 points by pimterry 3y ago

Oh yes. If you look at the number of software products that have failed at Meta you will cry in joy or intrigue(or both). Possibly why "Move fast and break things"(or acquire if all else fails) is the only way the money train keeps running and one could argue is the only time tested mantra for everyone in product space who, even for a moment, thinks about "sailing into the sun" with the ultimate and final app.

mikhailfranco 3y ago

Wow, honest experience and good advice. Aligns with my extensive experience with startups, later stage venture-backed sw companies, mature public ISVs, and well-established multi-national margin-optimizing system integrators (SIs). Most of them act (pretend) as if they are in one of the other categories, so they never have the self-knowledge required to apply the right rules to achieve success.

code_duck 3y ago

Sure, one could say the same about artists, restaurants, musical projects, or tech blogs. A high level of success is only achieved by a small fraction of projects, which is somewhat mandatory as there is not room for every endeavor to be a smash hit.

hgsgm 3y ago
Even a gym subscription is a startup that will probably fail. Almost everything new is hard.
mikepurvis 3y ago
And lots of things deliver value and bless people along the way. Even a restaurant that eventually "fails" still employs staff, feeds patrons, purchases food from suppliers, and all the rest of it. A thing doesn't have to achieve a shoot-the-moon ending in order to be a non-failure.
- code_duck 3y ago
  Indeed, that’s what I think about ideas like “Twitter wasn’t profitable” or “the post office loses money”.
  - mikepurvis 3y ago
    The post office losing money is especially ludicrous because the post office is not a business— it's a public service. It should be obvious to anyone who thinks about it for two seconds that the post office is financed from the general tax base, same as libraries, highways, parks, defense, airline bailouts, and all the rest of it. All of these are run at a loss because it's worthwhile living in a society that enjoys the benefits they provide. (And in the particular case of the USPS, it's literally enshrined in the constitution because it was seen as a pillar of democracy to be able to securely communicate with others over long distances.)
    - drdec 3y ago
      > It should be obvious to anyone who thinks about it for two seconds that the post office is financed from the general tax base This is not true in the US, the post office budget is separate and not subsidized by taxes.
danjac 3y ago
Moreover success depends on factors that may be tangential to the quality of the project. I have had more Github stars from low-quality "throw over the wall" projects that just happened to use whatever framework/language was cool at the time, as opposed to projects that I have put more effort into but used more "boring" technologies. As with a startup, if you catch the wave at the right time, you can succeed with a relatively low quality/effort project. But that depends on what counts as "success". If you are looking at just money or Github stars (or whatever the equivalent is in art or music) then that's one measure, but success could mean learning, personal satisfaction, something that helped or inspired someone else, the praise of a few people you look up to, or a job opportunity.

black_13 3y ago

[dead]

RajT88 3y ago

To look at this through the lens of an entrepreneur, "failure" is a relative term. If you learned something which contributes to your future success, it's hardly a failure. I have lots of defunct personal software projects that "failed", but all of those failures make me pretty good at my day job.

mwbajor 3y ago
Why do you need to finish a project? Is not finishing a project considered "a failure"? I have 100's of projects too I never finished but they typically morph into something else or I realize it was a bad idea. I think not having that would mean failure and it seems these true failures are rare.
- compiler-guy 3y ago
  Or I started on them, learned what I needed to learn or what they had to teach me, and then I moved on before finishing all the mundane parts. Still learned a bunch and figured some fun stuff out. That's not failure.

JohnMakin 3y ago

It's not a 1:1 comparison for software vs startups. The major difference being that the startup model is -> get a ton of investment based on a prototype, THEN try to figure out how to mature it and monetize it. Whereas lots of software projects have a direct path to revenue already.

zzbn00 3y ago

Developers are gonna develop... I agree if you give them a "new" software project risks are high and chance of success surprisingly low. Making do with existing software often better choice.

GMoromisato 3y ago

“All software development is R&D. As soon as it’s no longer research, it can be automated and the human work goes away.” To me, this is the First Rule of software engineering. We take it for granted, but seeing things through this lens explains so much, including (e.g.) the potential benefits of LLMs.

chinchilla2020 3y ago
In practice, the maintenance side eats up far more man-hours than the R&D side. Every software project has a shelf life except for a handful of very low-level ones that have survived the ages. All projects need maintenance until they reach their deprecation date.
- danielvaughn 3y ago
  I like saying the following: the difference between writing software and maintaining it, is the difference between raising your hands in the air and keeping them raised indefinitely.
  - pschuegr 3y ago
    i like that - great way of thinking about it.
  - paulryanrogers 3y ago
    Maybe more like raising a box onto a shelf in an earthquake zone. Then keep it on the shelf despite ground moving underneath every so often.
- fuzzfactor 3y ago
  The thing about R & D is that most of the time what's needed is overcoming difficult but important milestones if not accomplishing actual major breakthroughs. Failure on the preliminary R & D can be a complete show-stopper before you even get started. OTOH with such limited, poor & incorrect documentation pertaining to the hardware & software, especially in combination with each other, a strong background in the Experimentation & Discovery aspect of R & D is often the only way to achieve your objective when the intended initial logical approach fails to perform as it is supposed to do. This need can penetrate beyond maintenance all the way to end-of-life. One reason maintenance can chew up so many man-hours.

lakomen 3y ago

All the positivity. If I listened to the naysayers, I'd be nowhere. I won't even read the article. Motivation is a key requirement. If you don't believe in yourself and/ or your product, you might as well quit everything. Posts with titles like those are, for me, toxic, and I'll flag it.

crickey 3y ago
You sound like someone who hasnt worked very long in the industry. Being realistic anout failure allows one to build better products. Simplicity and maintainability and most important replacability. Allows a software to fail and not the business
- aeze 3y ago
  Neither of you are wrong, but it depends on where you're at. You need enough motivation to get across the finish line and ship a product. Many, many people fail here. If you're able to ship you need to be realistic about failure so you can iterate your product or move onto the next one with lessons learned.

dvt 3y ago

> If I were an executive sponsor of software initiatives, for example, I’d want to take some of the lessons from the VC world. I’d expect, and plan for, projects to just “not work.” I’d bake that into expectations all the way up. In any decently-run company, this already is the case. Most customer-facing projects are treated as startups that will fail (most do, some don't). I think expectations are well-balanced... but compensation, on the other hand... > And more importantly, I’d want the developers of the project to have skin in the game to compensate for the risk. I’d want them to share in the upside risk, just like early startup employees do with their stock options. Because in the absence of that kind of incentive and risk management structure, what I see is sort of the worst of both worlds (software and corporate politics): new software products usually fail but nobody wants to take the blame, resulting in pervasive fraud and willful ignorance and shame and scapegoating and bitterness. This hits the nail on the head. I remember working on a customer-facing product at X company about a decade ago. Our team was small and scrappy, and we were able to build a product that would eventually bring in $2M/month+. It felt very startuppy: we were regularly staying late at the office, getting takeout in the wee hours of the night, doing swarm sessions, war rooms, etc. I will say: it was engaging and fun. But what was our reward? A few months later, we got some cheap puffy jackets (estimated cost: $100 bucks) and a slap on the back: "good job team." Companies will never let you share in the wealth. Why? There are enough suckers out there that are more than happy with six figures (when they should be making seven). I was already enamored with startups since my late teens, but after that experience, I truly realized corporate upside is basically non-existent unless we're in a market bull run. The year after, I quit and started to solely place my bets on my own startups. In fact, the downside of betting on your own startup is fast converging with the downside of working at a FAANG or BigCo. Job security is shot (layoffs galore), perks are eroding (WFH, etc.), so what's the point? Best of both worlds is probably taking a BigCo salary and attempting your own thing on the side. (Obviously, young kids, spouses, debt, etc. can change the equation substantially.)

gnarcoregrizz 3y ago
Yep. An employee won't see any upside of the project they're working on. There are no incentives besides some nebulous promo dangling ("we'll see where you are at the next review cycle...") , and usually no way for employees to capture the upside of their project. I created something valuable for the company I work at, and I was left without upside - just my salary. Meanwhile, the people with stakes in the business say, "well you're making a salary," while they are buying new homes. Engineers - you are capable of creating an extreme amount of value that far exceeds your income. Take care of #1.

dangus 3y ago

The article assumes failure as more likely than not, but that’s not what the numbers say. I took a new ventures college class focusing on high tech startups and the statistics were more like: most startups get acquired, some IPO, and a small percentage fail. Software is one of the most profitable industries out there. Just look up margins compared to other industries. Now, I realize the article is talking about projects and not companies, but what’s the point of that? Example: A typical car company loses 100% of the money it puts into their infotainment system software. But they make a bunch of money when they sell the car.

bogle 3y ago
I think your ventures college class wasn't taught by someone with real experience. The rule of thumb is more like a 50% failure rate each year. Software may buck that trend. Here's some data that shows just 1/50th will exit in 5 years [1]. [1] (https://www.beauhurst.com/blog/startup-fail-scale-exit/ https://www.beauhurst.com/blog/startup-fail-scale-exit/)
fakedang 3y ago
Lol, more like 90% fail (including acquihired), 9% get acquired, and 1% IPO.

eagrwl 3y ago

I don't know if giving developers more skin in the game is the appropriate response to this. I do think they should have skin in the game for their work but I just think it's unrelated to this thesis. Most developers don't really have a material impact on the success/failure of the project. And that's because my inclination is that most software projects fail not because of some technical reason, but because it couldn't find product market fit. That's not something that's really on the developer. In fact, I'm not sure it's on anyone. There's inherent risk in every project, and the team's job is to maximize the probability of success. At least that's the way a process-first person would probably think about it. Results-first folks might argue that a great team will find a way to succeed. And then definitely, having more skin in the game will help with motivation. But I still think even the best team is just maximizing probability of success, and still they're more likely than not going to fail, because getting PMF is hard.

shusson 3y ago
> …it couldn't find product market fit. That's not something that's really on the developer Why is it not on the developer?
- hobs 3y ago
  Because in the (fairly wrong headed) world of today, the developer is told what to do by product folks and they mostly do it. That alone gets you to situations where the devs can see it obviously won't work, but the incentives and the egos are setup so that your job is just to build it, not critique it.

codingdave 3y ago

> To clarify, by “project,” I’m talking about something that’s large and customer-facing. Not a back-end Unicode migration or new integration test system or a plumbing job to redirect data flows or some incremental new feature on an existing product. Well, sure, if you restrict the definition of "project" to large high-risk software development, it may be true that most may fail. But in addition to the large projects under my belt, I've built literally hundreds of small, safe apps that offered incremental improvements to existing business processes, and they almost universally succeed. So I'd have the opposite conclusion of the article. No, don't learn from VCs. Don't aim high and expect to fail. Don't look for large projects and expect them to transform your business. Do look for the small steps that take you towards your goals, and work the ones that have the highest impact for the lowest risk. And in all honesty, most of the software work in the corporate world fits that mold. It just doesn't get any press because it is boring. Stable, but boring.

hedgehog0 3y ago
Do you have any advice or suggestions for college or graduate students who are not in industry, but interested in producing “stable boring” software business? Thank you. Added: With background in math and (theoretical) computer science.
- pphysch 3y ago
  I was trained as a mathematician but now focus mainly on developing "stable boring" software. Note that "stable boring" software is almost never "correct" from an academic perspective. The software is stable not because it has achieved theoretical perfection, but because it has been hardened through countless cycles of iteration, debugging, and customer feedback. The "boring" parts. My #1 advice would be to get a foothold ASAP. University IT/other IT departments can be a good starting point. Even if you don't start out as a SWE, any sort of systems-facing role will get you valuable domain expertise and you will 100% have opportunities to automate whatever work you are doing and eventually graduate into full-time development positions.
  - 3y ago

LaserToy 3y ago

I love the topic. My view on the companies: they are similar to countries in terms of organizational complexity. And the way companies are run are similar to the way countries are govern. Mostly due to the fact that there are not that many ways to manage groups of people or individuals. So, I’m not surprised the observation about startups also applies

deleted 3y ago

[deleted]

winternett 3y ago

We wonder why modern projects fail and somehow emerge as features incorporated into major products from big companies... It's because we store our ideas in knowledge bases and social platforms with backdoors on them, and we communicate on platforms run by powerful competitors (cough Gmail). We live in the age of silent espionage, where large money hoarding monopolies control information and silently monitor trends. That information is also used to crush competition at the ground level. Even your notepad application talks to the Internet... Your social media posts get consumed by crawlers, that report your ideas back to companies with large teams of devs that could easily spin up a clone of your idea 10 times faster than you could. It's at the point where writing thoughts in a notepad (on paper) will be the only way to keep them somewhat secure... Then of course, you need to be able to fully develop your ideas totally offline, until you're ready to launch... But then even after go live, you'll need to rely on those same systems that work to reverse engineer your best ideas, or to sell them in secret to your competition... We're doomed perhaps... As an independent software maker, you compete instantly with companies that run powerful espionage platforms, and that have money and human resources that can easily crush you, along with legal teams that can ensure you spend the rest of your life in a courthouse battling for ownership of your original brilliant ideas... Maybe it's time to just return to entrepreneurship that doesn't involve software development, or jurnalism, or anything online for that matter... Even our calculator app snitches over the Internet on us now, and it's far too late for an aging and very non-technical Congress to reign this shady brand of innovation espionage back into anything protective of our rights.

twosdai 3y ago
I don't really get this idea that companies can be so vastly competitent and incompetent at the same time. People make new products, if they make something that people want, it gets noticed. Eventually those with a lot of money come along and try to figure out how/if they can also make money on the same thing. It's not some vast conspiracy.
- winternett 3y ago
  You should take some time to look up the current dockets for antitrust cases before making simplistic statements like that. No one said anything about conspiracy... Anti-competitive business behavior though is definitely real, and growing for people that know about it through experience. Your lack of knowledge concerning how business actually works is apparent in your post.

indymike 3y ago

Software decays, some of it faster, some of it slower. Aside decay, we periodically have extinction events, like the switch to the web that killed a lot of thick client software, the shift to mobile, and even the shift to AI. Sometimes it's something mundane like fixing how time is tracked (Y2K) or ASCII->Unicode. To survive, software must have enough developer time to offset the decay and weather the extinction events. Hosted as a Service software has an additional pressure: the cost of hosting and additional maintenance pressure from forced updates. I think a lot of us, and a lot of customers don't really think about decay and extinction events as much as we should.

deleted 3y ago

[deleted]

thoughtsimple 3y ago

Most of the software I’ve written has gone into hardware products. Currently working on an embedded Linux system and writing a UI in ReactJS. We are late but only by a couple of months and I have every expectation that the software will be completed. The product has pre-sold about $1M already. If you want to be working on shipping products, work on embedded stuff. I’ve done customer facing business software too. Still mostly successful but that is where I’ve seen a few failures. One project I did was writing automated functional/integration tests didn’t see release but I take no blame for that one. The tests worked. The product didn’t.

jongjong 3y ago

My strategy around this is to make it so that every project I make builds on top of the previous one. My first project was a WebSocket client/server for developers, second one was a multi-blockchain ecosystem built using the WebSocket server/client, then I made a decentralized exchange to connect the blockchains. My current project is a no-code SaaS platform; it's being built using my WebSocket client/server and blockchain ecosystem as the auth and payment layer. When that fails at monetization, my next project will be to use the SaaS platform I will have made to copy successful existing SaaS platforms in various niches via a cryptocurrency-based subscription model. Then when that fails, my next project will be the lowest risk one, I will use all the stuff I built to offer contract-based development services to individual clients. When that fails, I will try to get into politics or write a book about failure.

tough 3y ago
I like the spirit jongjong

tmpX7dMeXU 3y ago

Honestly, from my perspective, and from anyone else not elbow deep in the VC-driven startup hellhole, this post reads absolutely insane. Why is this the only lens that you can look at this through? It feels…unhealthy.

Uptrenda 3y ago

Overly cynical neckbeard post. Didn't read.