Simple proofs are often only possible, because the language of mathematics become increasingly descriptive over time.
The language conveniently helps us make incredibly complicated statements by using specialized terms. Simple solution are rarely that simple, once we eschew the jargon of the field.
We stand on the shoulders of giants, and all that.
The thing about bugs is their subtle influence on overall product quality.
It's like building a wall; if one layer of bricks is laid unevenly, at least a number of layers built on top of it will have to compensate. Usually, this compensation takes form in increased development times or increased complexity / convolution of new features.
Furthermore, it lowers end users' overall trust in the platform.
Both of these two effects will have at least some negative impact on profitability, though it may be lower than the increased profitability gained by adding new features.
I'm not saying all bugs should be fixed immediately at the expense of new features, but I've rarely been in a situation, where it felt "right" to ignore a bug indefinitely.
With three kids, my current side project is my day job, at least if measuring by workload. Taking on more work, voluntarily or not, will be at a significant personal cost for me.
I don’t get the constant peddling of hussle porn in SWE circles.
The “only valid use cases” of privacy is not to hide illegal or criminal activity.
Crypto currency is a wasteful, destructive, expensive and innefficient technology that has few benefits except facilitating crimes like tax evasion, money laundering, financing terrorism and purchasing drugs.
> SAP is sold to the C=suit, never to IT or business operations, nor any of the people that will ever come onto contact with the software.
Plenty of terrible corporate software works like this. Precurement has a checklist of features, and that list never includes "Has great UX", because only the people on the floor has to use it.
I'm looking at you JIRA...
> SAP project often fail (this is not specific to SAP but common for large projects). Making sure that in case the project fails it is the customers fault will be strategically taken into account from day 1.
I was a consultant at a major software consultancy for the better part of three years. No matter what, it is always the costumor's fault, even when it isn't.
Paying a customer back some 100 billable hours worth of payments is simply just not feasible, when a large part of consultants have less than a years worth of work experience.
While you sit down and talk about the project with senior and managing consultants, you are being deluded with a completely skewed perception of the base level competence of those that will carry out the work.
The higher hierarchical "level" a consultant is at, the less implementation work they'll do, because associates will take longer time doing the same tasks and will therefore sell more billable hours.
The entire T&M consulting industry is economically incentivized to produce organisations that shirks responsibility, while simultaneously work on "too big to fail" projects, because that's where the money is at.
> SAP is a fairly closed ecosystem. Typically consultants are recruited straight out of school and never leave the stack as it is very different from the rest of the industry. It has it's own cultute and habits that do not travel well outside of it's niche.
Not to mention that it has its own programming language. I had a colleague that worked as a SAP consultant, and she said it was horrible. Features like "variables names can consist of at most 8 characters" certainly didn't help.