[fabfabfab]

Speaking of purity, the first thing Hacker News would do is try to run SAP on a Kubernetes cluster, refactor crucial bits in Rust and shard the database into sqlite3.db files on per user basis. We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names. Bringing pets to work is mandatory.

[_glass]

:D You can run SAP in the cloud on Kubernetes: https://cap.cloud.sap/docs/guides/deployment/deploy-to-kyma

Also you can re-write everything in Rust https://blogs.sap.com/2020/07/23/learning-rust-with-cap-part...

[davidkunz]

Ah, that's my blog post :)

[Cthulhu_]

And ironically, the end result would be worse and more complicated, but the people that worked on it would get to write a blog and put it on their CV about it, and move on elsewhere without having to live with their own decisions.

[jdhzzz]

Declare victory and move on...

[jwr]

This is so true! As the author of a (small) ERP/MRP SaaS, I am often amused when I read HN and observe the thundering herds of fashion followers — today it's Kubernetes and Rust, Postgres and sqlite have a longer lifespan, but tomorrow it's going to be something else entirely, and you necessarily need to use those :-)

[lycopodiopsida]

I am always thinking about Vinge's "A Deepness in the Sky" and computer archeology: there is an accumulation of the code base and at some point most code will be some kind of legacy.

It is not feasible to rewrite it in the fancy language/technology du jour - huge waste of resources for things which already work fine and at the moment you are done you have to start again, since the IT-pendulum is traveling in the opposite direction.

We, as an industry are really bad at working with legacy code, but for a lot of us it may be the main task if we endure this line of work for some decades more.

[ebiester]

I think there's a bigger issue at play that at some point I want to write on.

Small problems benefit from small tools. Large problems benefit from large tools. However, small problems grow and your bet as a small problem is that your tools will grow with you.

In practice, they usually do. If they don't, you end up extending the tool or rewriting it in a larger tool.

So, our tools start small, and small companies use small tools, and the ecosystems grow together. Then, the successful ecosystems end up the next large problem toolkit.

As you're a small ERP SaaS, you're banking on growing with your customers, I presume. And you can make an argument to start on the large tools at the cost of initial velocity, but that's your tradeoff.

I really think the innovation that needs to happen is a system that has a prescribed growth path. Retool/Excel/similar that can compile to a simple app that can adapt to more complex patterns as the need comes.

[pjmlp]

Same here, all the hip trends of the day, and then back to the same Java, .NET and C++ that I have been touching for several decades, Boring Technology™.

[FlyingSnake]

Meanwhile people are spinning up profitable SaaS based on PHP and making it to the bank.

[Archelaos]

> We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names.

Already happening: https://apphaus.sap.com/location/heidelberg

[moss2]

Almost right. The conference rooms would be glasswalled and have funny names, but no one would be there because everyone is working from home.

[Havoc]

And then plan fails due to insufficient foozball table count

[xcambar]

And apply to YC

[moffkalast]

> refactor crucial bits in Rust

on't forget rewriting all the scripts in Zig of course.

[sdave]

Someone would claim to implement sap over a weekend !