> "just do the parts of it we actually use".
25 years here. You can absolutely do this. Most software is orders of magnitude more complex than it needs to be.
The junior programmer you are talking about who wanted to rewrite it in a weekend tends to come back with a working program, not empty handed.
I agree. Just because you can buy some piece of software doesn't mean you should -- there is a lot of software that exists just to sell more consulting hours and will never fit the business. It's actually not hard at all to code and maintain much simpler alternatives.
Actually having to support multiple businesses with commercial software is hard. I've written a ton of custom software that far surpasses the capabilities of commercial offerings but if were to turn that into it's own commercial offering it would be large undertaking.
I've seen this happen with both juniors and seniors. They do come back with a working solution /for the happy path/. Because the happy path is easy. It turns out that most of the complexity sits in the unhappy paths.
I still don’t agree. The trick to good design is getting more things on the happy path. Most of the software I use is small and constructed in this manner.
"They only coded the happy path" is software engineer for "they coded it as if nothing would ever go wrong". It is definitely not good design to do that.
There's an engineering trap/fallacy I like to call "how hard could it be". How hard could it be to build a [whatever] clone? If you find yourself thinking that, stop what you're doing, because the answer is almost always "at least an order of magnitude harder than you think."
What I meant is that most commercial software has a large number of code paths. Because it’s built incrementally, not holistically. This creates complexity and cost.
If you’ve only worked on that kind of software it’s hard to know the alternative which is to aggressively prune code paths and rework your main code.
And open source example is Quake. I rarely come across software whose inherent complexity is more than quake.
Yeah, that's not what the person you were replying to is talking about. I was explaining the jargon.
Complexity and LoC has nothing to do with "only coding for the happy path". Both complex and simple software can be written this way.
A great example is the moltbook hilarity. They slapped together something that looked good and did function -- in the happy case only. They put together an "authorization" flow but exposed their entire database because they didn't know how to secure Supabase. They had no rate limiting on account creation -- so one dude created 1M in an hour.
Even putting aside adversarial usage, you have to code for, like, normal stuff going wrong or your app will lose data, crash, leak information, fall over, etc, etc.
I think you are not considering what I’m saying.
I’ll put you in the “it’s impossible to make software” camp.
Yes, I didn't really doubt the developer could do it, the problems are:
1. That's not a great use of the developer's time, and
2. anything in-house increases our training and support costs
1. The whole point of developer time is to save user time; if a developer can do that then it's worth it.
2. If the in-house software doesn't decrease training time or support costs then there is something wrong there.
1. No. The point of having engineers is to build product and make you money. They cannot make you money if you waste their time on building internal apps that do not make you money.
There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue. We get paid the big bucks because we can make companies a lot of money.
2. Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
If you write the tool, all of that is on you to do. If it goes down, you have to fix it. If it screwed up data, you have to fix it. Any time anyone has any questions? Guess what, you're the one they'll ask. All of that costs the company money, because you don't work for free. When you quit, the app is now useless and can't be fixed unless you did a lot of work beforehand.
It's best to think of DIY apps like those really really sticky noxious tarpits. It might look safe or easy to get into, but good luck getting out of them. You might end up at the bottom with the bones of everyone else who thought that DIYing it was a good idea.
> The point of having engineers is to build product and make you money.
You're making the assumption that all software development is for software products. My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.
> There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue.
If the SaaS app is $20K, I would agree. Probably the cheapest we have is $30K per year, most are an order of magnitude more than that. And it doesn't take a $100K of developer time to replace some of them.
> Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
Haaaa no, that's 100% not how that works. You buy a SaaS product then you pay them to install, configure, customize it. That can a small amount or a large amount. That can take a small amount of time or years. You can maybe hire people who have worked on that system, but probably not, and it's mostly bespoke knowledge that only a small amount of people have. They aren't cheap. But you might be entirely dependent on the vendor.
If it goes down, you have to put in a support ticket. You wait. Everyone is still on your case but you can't do anything about that. If you have access, sometimes you can fix it yourself -- and you do -- because waiting for support to do it properly is awful. If it's screwed data, good luck, they're not good at fixing that. Anytime anyone has any questions? Another support ticket. None of these people work for free; expensive support contracts. The level of support you get is completely divorced from that cost. You can't pay less if the support is terrible, you can't pay more to get better support (not that you would want to).
If I write the tool and it goes down, I can fix it. Awesome. If it screwed up the data, I'm more than capable of fixing that. If anyone has any questions, guess what, I actually know the answers. The company pays me for these services. When I quit, the app can be easily fixed because it's all standard technologies that lots of people know. Those SaaS tools? They're the black box that nobody knows how to configure, customize, or fix. The vendor isn't interested in doing anything more than the minimum needed to close the ticket.
> It might look safe or easy to get into, but good luck getting out of them.
Just try and switch away from your cloud SaaS product. You might not even be able to get your data out.
And both are completely different arguments then your original post.
No, those are the two main reasons management don't want to have internal systems belong to them
I see. I misread. My mistake. I agree - the issue is not technical it’s the responsibility for the project.