With a few exceptions such as assembly if your code is not readable you are doing it wrong. Code needs to be maintainable. The maintenance costs and lifespan of code often far exceed development cost and time span. If you are not writing clear code you are writing crappy code.
I was once complimented on the clarity or my Perl code. I posted some and got several stero-typical responses fo 'well it could be written better as....'. Then someone piped in and said something like, "screw it, It's clean and easy to read. There's nothing wrong with it". And that is what my experience as a maitnence programmer taught me. If no one can read it to maintain it, it is crappy code.
Don't use your retirement for this! Too risky. Only money you can afford to lose.
White. Now what sort of penguin is standing next to you?
That looks good on paper but rarely works out in real life. In order for it to work everyone must be honest and a monopoly does not exist. We are a very far way from the idealized small shopkeeper model of Adam Smith. Here are some reasons for government regulation of taxis:
1) So customers do not get ripped off. Prices are set or at least clearly advertised.
2) So customers are not raped or murdered. If you hire a ride from Joe Random taxi driver without licensing and a background check you have no assurance about the driver. In fact the lack of assurance could kill the industry as people look for other options.
3) Insurance. If there is an accident are passengers, occupants of other vehicles, or pedestrian need to be covered if the taxi driver is at fault.
4) Mechanical safety of the vehicle. Has the Uber and Lyft cars been checked over for dangerous faults or wear and tear? Are the tires good? Etc.
5) ENSURING competition. If one company gets too big you restrict their licenses while issuing more for their competitors. Sometimes the best way to approach the ideal of a free market is through careful regulation. Free market != unregulated market.
Those are the ones on of the top of my head. The world is much more complex that Economics 101 or a fictional account of how one writer thinks the world should work. It is even more complex and dynamic that even people with Phds in economics can imagine, IMO. Instead of simplistic solutions we need to look for solutions that actually work.
1) Start a business. If you are an engineer with a PE stamp you can do it.
2) Invent something. Preferably something that helps people.
3) Buy into a start up and help it grow. One that you can desconstruct and see if the people are just BSing you. Risky.
4) Like 3, microfinance. Also risky.
Besides you engineering training you should learn a little accounting and finance. This is required if you want to understand the basics of investing.
Land you can farm. Silver is worthless.
Do a little reading on Iran-Contra and the role drug money played. See also how the same approach was used to fund an illegal war in Laos by the CIA, Panama, Mexico and a host of others.
Here's a starting point:
The health care industry was unregulated until about the 20's. So many people died that the FDA and a host of health and sanitation laws were pass. Then the death rate started to drop.
People forget that for a long time going to a hospital actually increased your odds of dying.
Just like in the US. Swap out the old wife for the young one.
I was going to post that the problem domain is much more demanding because it is much less constrained. Heat, cold, vibration, pot holes, safety, pollution controls, timing, ignition, etc. There is specialist knowledge Google et. al. simply do not have. Much more difficult than a shiney little mobi app. Over 100 years of domain knowledge goes into each and every car. Hell, they still can't even get the maps straight. A problem that was solved years ago by map makers.
Will the driverless car be secure from cracking?
Nah. Probably one of these:
OK, this is close to what i was going to say. But basically I think if you approach it as a 'one size fits all' or some sort of silver bullet approach it will fail. Use it in the domains it is good at. For other projects, you have to look else where.
In my case we have teams scattered across the world working on a very large enterprise scale project. I do not think Agile works well in that environment. I am unsure what does. ANd unfortunately we are doing things referred to as 'Agile' but is not. It is merely an excuse to keep us on an insane release schedule. SSDD. Or to put it another way, 'Ground Hog Day'.
Two words, "ejection seat".