I've been a technical advisor for several startups, I'd say that overall this advice is wrong.
Most startups stay in it way longer than they should.
I'm happy that things worked out in your example, but they generally don't. Mostly because founders reason with their feelings instead of applying logic, statistics and probabilities of success.
I think I'll just write something similar and wrap Apache with a shell scrip, claim that it's a web server written in bash, post it here and see what reaction I get, just for shits and giggles.
It's not exactly the same though. Stolen cars does not have the potential to affect your daily day life as broken software can.
I agree that the blame does not lie on the engineers that created the cars or software though. In the end it's a problem of cost, you could write better software, but it would cost you time, money and shifted focus in the education of software developers and so on. Users are not willing to pay for that cost, they are very upset when reality bites them in the rear though...
I agree, Siberian cold due to changed flows of different currents seems more likely as the end result due to climate change for the Nordics rather than increased temperatures.
Increasing temperatures now does not equal increased temperatures later, when the system has stabilized again.
I'm not saying it will happen, just that it seems more likely with what the current data seems to imply, my current information is from some pop culture article though, so I'm the first one to agree that that information might be wrong.
My company that I work at actually closes bug reports that has been in "pending customer feedback" for more than 6 months automatically. The customer is free to re-open the issue at a later date if it's still an issue.
I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.
The difference is that engineering over all is mature enough that you can make incremental changes over time and it still does not invalidate what you did previously. If you built a bridge 10 years ago its probably safe enough to leave standing even if you can build a safer bridge today.
The same cannot be said for programming yet. It's hard to improve the safety of the tool, the C compiler, without breaking your past bridges or having to redo the work again, i.e rebuilding the bridge.
Well, I agree that you can wish that the tool was better designed, that's a whole different thing though.
What I meant to say, in a rather roundabout way to be fair, is that the problem is both the language and the programmers. C is a tool that is too hard to use correctly, but the programmers who write crappy C code are to blame for their crappy code. It's another thing if an expert fails to use the tool safely, then one might blame the design of the tool used.
There seems to be 2 camps, one camp blames C and one camp blame it on poor programmers. Poor programmers have given C a reputation and the tool itself is too hard to use correctly, even for experts, so both camps are right and also wrong...
I think some of the decisions made for C back in the day where fine, C was designed to be lightning fast and close to the metal, but I think it's time to pivot. I don't think it's necessary to sacrifice security to squeeze out the last percent of "speed" today. C has a lot of legacy code still in use though, so I don't think it will ever happen, that's why I use other languages for production code today and only write C when needed for C code bases still in use.
Well, I do think a programming language is a tool and it is kind of wrong to blame the tool for the mistakes made by the one wielding it.
The problem with C is that it's a tool where you have no safety and I don't think there's a programmer alive that can actually use it in a safe manner. I guess some are close, but they will still end up with the occasional wound here and there on their bodies...
I would probably avoid using C for anything I put in production today, I still love the language though. It still feels special, sitting down with all that power at your fingertips knowing that you'll have a built in buffer overflow if you lose focus for a second, gets (no pun intended) my blood flowing! :-)
I agree, especially since a portion of the "new" movies are regurgitation of old classics anyway and more often than not weaker than the original movies.
I used to do TDD, I found that it didn't work that well for me.
I still think that the code base you work on dictates how you should be testing. It also dictates which testing strategy I use.
I test for different things when writing C than I do when I write Python for example. My testing strategy is different if I write a networked C application compared to if I write a Ruby on Rails app.
Also the tools I have available to me when writing the code dictates how I will test, which is tied into which language I write in.
And I really disagree that code has to be awful because you are not forced to write unit tests. I work with a team of 4 other experienced and responsible programmers. We actually don't have to have rules that force us to do anything. We are responsible enough and experienced enough to know what to do and when to do it.
40 - 50 % of our code base doesn't have a single unit test, because it doesn't have to have any. Are we infallible, no. Does mistakes happen? Yes. Do we sometimes go back and add unit tests to code that we thought didn't need any. Yes, it happens.
Would unit tests have saved us sometimes? Yes. If it would have, then we are responsible and go back and add that test.
I think it's a failure to ever believe that unit tests provide any correctness proof. The only thing you achieve with unit tests is to prove that you are still bug for bug compatible when changing your code.
I think experience is needed to know when to unit test. Some code might not need any tests at all while other code might need quite a lot of tests.
My personal experience, for the code bases I work on, shows that for those code bases mocking is usually not beneficial, we find more problems with integration testing and fuzzing. That holds for those code bases, it might very well be different for other code bases, and here's where experience comes in again...
Yes, I agree. The question is what the system need to change into?
I'm not an expert, but it seems that all known political and/or economic systems fail in the face of greed and selfishness. Or maybe greed is the effect of a failed political system, either or all known systems are a failure from my perspective.
I think capitalism balanced by laws has worked best so far, but you seem to need so many laws that it creates loopholes. I.e blacklists doesn't work that well, especially not a complex blacklist. (And I'd even suggest that the blacklist has been trojaned by lobbyists and other agendas.)
The problem is that we have elected leaders that only care about being in power. They will happily watch the world burn unless a majority of the voters want them to move.
Sadly I don't think most people are ready to make the necessary sacrifices to stop climate change. At least not yet. And I think we will pass the point of no return before people are ready to make those sacrifices.
The problem is not technology or scientific, the problem is human nature.
Most startups stay in it way longer than they should.
I'm happy that things worked out in your example, but they generally don't. Mostly because founders reason with their feelings instead of applying logic, statistics and probabilities of success.