Few days ago we visited a company that makes avionics for small private planes. I looked at the hardware, a simple touch screen and tiny linux computer with usual sensor connections. I thought I could build this myself in a weekend for may be $300 tops which is an order of magnitude lower than their sell price. However what I learned was that the thing is expensive is not because hardware or software is expensive but the QA and certification process. There are regulations that avionics needs to work in all kind of weather at wide range of temperatures and pressures while still being accurate and have million hour of run time testing without any crashes and survive extreme shocks, vibrations and G-forces. Someone is after all betting their lives on your device. Now suddenly you have to care about strength of every soldering joint, specs of every transistor and reliability of every screw. Add on to this the customer support, marketing, warranties, legal expenses, returns and other typical overhead of production. If I'd to make device that is compliant of all these, it wouldn't come cheap. Making a hobby device for demo to school kids is quite different than making device that would help people make life and death decisions.
A company I worked for had a new website built (their big customer facing domain). It was just a Drupal theme, responsive, absolutely nothing fancy.
An old friend of mine guessed $20k, maybe $30k tops if you were being crazy, and I thought even that was high. Back in our consulting days we probably would have quoted lower.
They brought on a company for $1 mil, ended up 6 months late and $1.6 mil.
Gotta love those project managers and "status update meetings" to burn the cash.
Most companies won't buy unless you can guarantee a support contract for at least two years with new features being included in it. This is why software prices just skyrocket easily.
Recounting my experiences from the biggest customer (the federal government), everything costs a million plus because you have to have so many bodies to support it. Aside from the obviously unnecessary committee meetings in which a panel of stakeholders spend four hours debating the minutiae of a website (font, colors, stock photo selection, the usual), you have to have an "architect" to navigate the bureaucratic process of getting DNS entries, database tables and backup systems hooked up because you can't possibly bring your own.
You have to have at least one developer who makes sure that its authentication uses CAC, X.509 or at least Active Directory as its authentication source. You have to have at least one specialist developer who ensures that logs and audit trails are DCAA compliant.
You have to have at least one developer to ensure that the website is 509 compliant.
So on and so forth, and that's not even counting however many developers you need to actually build the basic functionality they've hired you to build.
On top of that, you need to have a proposals team capable of submitting a proposal to an FBO request for proposal, a contracts lawyer to ensure that you're meeting the contract terms with the technical solution you're providing, an accounts payable & accounts receivable team to team up with the contracts lawyer to figure out how to prove to the government that you actually delivered the module or widget they're insisting is deficient so that they can slough off paying you for as long as possible because they're in continuing resolution, a veteran / minority / woman / disadvantaged person with ownership stake to be eligible for program 8A opportunities, a project manager to actually manage the work, a program manager to try and upsell the opportunity and keep their ear to the ground to get the insider details on potentially up and coming work that they can pass to the proposals team, and a subcontractor with some kind of past qualifications in government work that you can leverage to ensure the government that you are, by proxy, also qualified to do that kind of work for that kind of government agency.
And of course, with the myriad, competing interests of the various stakeholders, a Herculean degree of risk aversion, and the fact that everybody wants you to fail, including the customer who didn't sign on to a risky project that will likely fail so are duty bound to ensure that it does fail and especially your "support team" of people who you have to ask for DNS entries, database tables, etc. that are actually competitors of yours that also bid on the work but obviously failed to win, they just want you to fail so the contract can get re-bid and they have another shot at winning it.
Of course, that's not the worst part - the worst part is if and when a project appears likely to succeed despite all the attempts at ensuring it doesn't? Then everybody and their mom becomes "active" stakeholders in your project because it's a chance to hitch their wagon up to a success that they can put on their resumes to get promoted... they want you to customizer your project to suit their needs so they can put their stamp on it so it provides a clear and measurable benefit to their division / department even though this work is clearly ad hoc, not in the contract, and they're extremely unlikely to want to pay you for it because of that.
when it comes to maintaining code that affects financial data and customer information the certification can be pretty extreme to people not familiar with the risks. Even two teams of auditors can be involved for some work (internal and external). Even after it deploys you watch new changes like a hawk
This realization you had is precisely one of the reasons for which I was very vocal in a recent thread [1] about a startup that wants to (watch out, projectile vomiting coming) make manufacturing "orders of magnitude" better.
The problem with a lot of these ideas is ignorance of what real product development and manufacturing entails in the context of real-life applications, regulatory constraints, liability and more.. They think that because you can iterate code fast while sipping a latte at Starbucks the same "logic" can be applied to manufacturing and, voilà, "orders of magnitude" better manufacturing.
Reality, as you have come to realize, is often far more complex that machining a few pieces of metal, throwing together a microprocessor board and writing code over a weekend. And every industry is different.
> Add on to this the customer support, marketing, warranties, legal expenses, returns and other typical overhead of production.
This is often why startups and SMEs can sell at lower cost too. The overheads are lower. I work for a medical devices company and our main competitor is more expensive than us and keeps having layoffs (or so it is rumoured). It's hard for them to cut prices for similar products when they have 10x the staff.
Business love regulation. Really keeps the upstarts out of the game if they need to have twenty different certifications to get their product to compete.
This can be true, but there's a more immediate reason they love them: the perception that the industry is safe leads to greater sales volume and much cheaper sales cycles.
As an example, consider restaurant sanitation regulations. If restaurants are frequently unsafe, people will learn pretty quickly that it's better to eat at home. But if restaurants are generally seen as safe, people will eat out a lot more. That benefits all restaurant owners.
Or you could just not regulate medical devices, and if someone dies from a lethal dose of radiation from an X-ray machine then shrug they shouldn't have used that model I guess.
Is that really the only other choice here? Knocking down straw men will also not get us where we need to be.
Regulation can harm at least as much as it can help. Consider that regulation is based on ideas that people think might help a situation, then add in some partisanship. When coming up with ideas, how likely is it that an idea is not going to be a good one vs it will do some good?
Perhaps it would be better if there was some way to incrementally evaluate regulations. Perhaps if they had a defined lifetime to force re-evaluation in light of actual experience. This would prevent at least one negative aspect of regulation - locking into practices that were thought to be safe and maybe were, but are no longer the best/safest way to do things.
