> 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.
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.
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.
In my experience the post quality has been down-trending for a while, but the podcasts are top-tier. Definitely check it out. I also recommend the books:
I looked into that book, looks like it's really for venture backed companies trying to form a founding team. I'd recommend that you instead look up micro-SaaS, where you just target making $10k+ monthly recurring revenue and be set, rather than going on the VC treadmill and trying to raise capital, hire a team, etc which is often overkill for first time founders.
Rob Walling coined that term initially through his conference on it called MicroConf, he has a new book called The SaaS Playbook [0] which I'd recommend, he has a sample PDF here [1]. His older book Start Small, Stay Small [2] is also quite good.
But to start off with a free resource, Jason Cohen's video on designing a bootstrapped business can't be beat [3].
Thank you. Will try to workthrough some of the materials you mentioned, I have heard of read some of "Start Small, Stay Small" in the past, though not finished.
> I'd recommend that you instead look up micro-SaaS, where you just target making $10k+ monthly recurring revenue and be set, rather than going on the VC treadmill and trying to raise capital, hire a team, etc which is often overkill for first time founders.
Yeah, it's also my orginal goal and what I want to start with.
On a side note, I read "No Filter" and "That Will Never Work" and quite enjoyed them.
Glad to hear it. The main thing I've learned is to just start, building and marketing, talking to customers, etc. I used to read a lot of books and watch a lot of videos on the topic of startups and micro-SaaS but it obviously doesn't spontaneously generate a profitable startup just because we read about them.
Plenty of remote, especially if you lean towards the newer/tech-ish or tech-forward companies that are start-ups or forward-thinking legacy-structure companies.
One thought for you: RTO isn't so bad in this instance. Lots of insurance knowledge captured in the heads of older folks that prefer face-to-face. Their knowledge is the hardest to replicate but the most useful to system builders who really should know the business reasoning behind their efforts.
“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.
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.
Would the handful of low level ones include the many thousands of video games that run on pre internet consoles? One can argue that those projects are "finished" and not in need of maintenance but it really depends on your point of view. I'm sure people can find ways to say those projects are not finished (an example being the efforts to reverse engineer super mario 64 and zelda OOT have now shifted to correcting bugs in the game and squeezing every ounce of performance from the N64 given we now have foresight into how the hardware runs best)
They are "cheating" slightly though, because they get to run on a "unchanging" environment, i.e. the hardware is fixed and they generally don't have to suddenly support the latest version of Windows or similar.
I hear ya, and it goes back to how we want to define everything. Technically the software itself does not need maintenance. The "why" is because of unchanging hardware. Maybe more software should be developed for unchanging hardware. The problem is that the real world does not map well onto this paradigm.
....maybe AI will solve this problem for us one day. :P
At any point we could all just just agree to make an unchanging ExtremeLTS target if we really wanted. Just like, freeze a modern Linux and only do nonbreaking changes to any of the parts.
Unfortunately nobody seems to have done that for real practical use. There's UXN, which is cool, but I wouldn't want to use anything that minimal, especially not with the focus on ASM instead of a high level language.
We could also just decide to make a compiler to make N64 dev easier and just keep making most of our stuff for that, retro console games will probably always be playable for as long as civilization continues, but that would not exactly be practical.
But windows kinda already does the whole unchanging target thing, or did. Their backwards compatibility is so much better than Linux, where nothing works in 2 years because of all the dynamic linking.
Standard protocols rock. Sadly many RSS producers have degraded the content in their feeds which requires workarounds to get full articles or sign in or support new elements.
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.
> 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.)
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.
Companies want to have the scrappiness, grit, late hours, and employee devotion of a startup but without having to pay that pesky "outsized upside" when things go well.
I once worked for a small closely held company (CEO and family were the sole, bootstrapped shareholders, no institutional funding), where the CEO would regularly moan and complain that his employees were so lazy and not dedicated enough and that they should "treat it as if it were their own business." It never really dawned on him that they might do that if it actually were partially their own business, with an equity stake (or even a bonus structure that rewarded effort).
Are you willing to take the downside too? How about the company doesn't pay you anything but gives you a cut of the profit, but also charges you if the project fails.
To take the other side of this, what % of the wealth you created would you have been willing to share with the engineering teams charged with KTLO work, and by them doing so enabled your team to focus on the new product?
What about all the software teams who are not customer facing, and without whom you would not have had the opportunity to create this product?
How much of your success is due strictly to your team? What externalities are you not counting?
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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].
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.