It's hard to say though. There's enough of a libertarian leading in the party now that I don't think the pro-corporate faction could get away with it. They're essentially a minority in the party, with enough clout to stop or delay bureaucrats but not enough to add their own regulations (ie, barring municipal utilities is adding regulation, while allowing them is more hands-off, and the hypocrisy would be obvious even to factions who normally only care about social issues).

It's a slippery slope, soon the railroad barons will have to allow anyone to transport on their tracks!

640 kilobit is enough for anyone!

Just yesterday was watching him in Mission: Impossible.

True. However tobacco companies did some marketing to try and overcome that stigma, and it worked pretty well from the 40s through 60s. Remember the television doctors who'd be smoking while talking to patients, stuff like that.

Most non-open source for embedded systems still comes with source code. It's almost mandatory because you will have to fix it eventually, and they sometimes won't supply object files in a format you can use.

No, probably 6 months to a year before they tell you that they can't reproduce it and close your ticket.

Third party code can be harder to maintain. The third party often will not help you out, even if you do have an active support contract the support that you get is substandard. If you're Cisco they might help you out, if you're a tiny company with 50 people they'll ignore you and put minimal resources into resolving your problem.

I swear I am not making this up, but I called support once for one component and told them about the bug and details of the fix I came up with for it. They told me that if I already had a fix then why was I calling them.

That's one reason I think that the most popular libraries are probably safest, because others are more likely to find the problems before you do.

I think there's a form of superstition out there to never write any code that's not glue code. Some of this is from a phobia about reinventing the wheel, so that people will waste time in order to avoid wasting time. But some also comes from thinking that third party code will be correct and so increase overall reliability (no matter how much flimsy duck tape is required to attach it).

I see managers with this thinking, it's as if they are assuming their own staff are a bunch of morons so it's safer to rely on a third party. The worst is when the boss spends a lot of money on a third party library that you could have written yourself, and which you end up spending most of your time fixing it yourself instead.

Crime prevention includes several aspects. Crime deterrance for example; when people see the highway patrol on the side of the road, they slow down, and giving out a small number of tickets does affect the behavior of people without ticket. Similarly, arresting people for burglary discourages some (not all) from doing the same crime, and sometimes causes the person convicted from not committing the crime again in the future.

For the border patrol, seeing the vehicles going up and down near the fence causes people to try to cross somewhere else. An area with a few apprehensions also causes people to try somewhere else. Ie, prevention.

This only works though if a new task A can be compared to older task B. That so rarely happens to me. It might be common in some other areas though, as in "add a new web page with a different customers name up top". But when last month I worked on improving a crypto engine and this month I'm fixing the network MAC layer, and next month I'll do board bring up, then the evidence just doesn't accrue very fast. Then there's a problem that the amount of outside interference is not a constant, some months I can get lots done and in other months I barely have time for my real tasks.

But there are so many managers up the chain that take all these estimates as the truth. Before the project starts, before any data sheets have even been read, we're asked to come up with all tasks we think will be needed, then give an estimate for each task. This all gets put on a chart and managers stare at it. Then you'll be asked what percentage of time you can work on each one, and you'll say 50% maybe because they get really mad at you if you are honest and say 10%. Then the chart gets printed and put up on some walls.

The problem then is that the chart is not updated. The developers are too busy to figure out some goofy planning software so that they can budge their estimate and the managers don't always do it. Along the way half those tasks you thought were needed either vanish or are replaced by something else and some new ones are added (because now you have some datasheets and requirements, you thought of something you forget, etc). We open and close tickets that aren't on any project plan. The planning and actual work just don't coincide, they're done by different groups of people with completely different sets of motiviations.

I have been at one place though that managed to estimate things well and had some good planning. I honestly don't know how they did it, except that they moved slooowly. They weren't developing a brand new product from scratch (like I am now) but just adding incremental features, lots of time spent planning before starting by people who are engineers and not managers, a set of bug-fix releases were pre-planned, and there was a multi month back end for QA. They spent more time on documentation than some entire projects I've been on. And it was waterfall. But that was only for two years of my career.

In the real world though, there's a whole lot of penalizing that gets done. Thus a whole lot of stress.

A soft voice says "plugh".

Most managers are completely awful at management. Of course, most programmers are pretty mediocre at programming too. But bad management can hurt a lot more because there are fewer of them and they wield much more power. Sometimes these bad managers used to be the mediocre programmers who were promoted to where someone thought they'd do less damage.

But sometimes managers are good. The difference is whether the employees are expected to be helping the manager look good or if the manager is trying to make the employees look good instead.

And most of my job is actually jumping into shark infested waters carrying a book entitled "shark training made easy".