some people think he's honest
he's not honest by any measure
are not in conflict. Trump uses profanity to appear honest; and as people associate profanity with honesty they attribute "straight-forward" and "honest" to his persona (I'm not American or pro or anti Trump, just an interested outside observer). Bullshit is an art, and he's better at it than most.
The way you describe what you are doing it sounds like you know what you want at the end of a fairly long time frame, and your doing one set of pretty basic planning and then acting surprised when that plan doesn't give you what you want at the end of the project. This is pretty typical when groups try to transition to an agile development process, and fail as a result. All you've done is throw away your detailed planning and chunked your work up into sprints.
Try Scaled Agile.
It's what we currently use and is the best tool-box that I've yet come across. Things like SCRUM etc don't define process at the business level (intentionally), nor do they describe how you plan out a project that's going to take a year or so to deliver. Scaled Agile does, and it's a very useful toolbox for getting the whole show to be agile (which is the end goal for a business as it allows the entire business/activity to adapt quickly to changing conditions, both internal and external). At the very least, it's useful to read (all online), as it demonstrates all the extra bits that you would need to transition fully.
A core tenet of Agile is that design, planning ahead to the end of a project, is impossible. In fairness, it probably IS impossible, for the people who believe that.
I'm so glad you're here as an obvious expert on all things software development process to explain Agile in such detail. It's so comforting to have a real professional help all us struggling dolts see why we've been getting it so wrong! I don't give two shits how you like to run your projects, but maybe you should stick to talking about things you know something about eh?
Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system.
Garbage, you simply show your ignorance. You know what? Agile is a meaningless term, you have some kind of image in your head of what it is (maybe informed by some group of idiots claiming to do it), and hence you can build this lovely strawman to set fire to. Here is the agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
No mention of not bothering with requirements, only that the emphasis when creating your processes is on the ability to respond to change. On any project that lasts more than a few months, that just sounds like damned smart idea. "No no! We must continue to follow this plan from a year ago, even though it no longer makes any sense in the current market!" Been there, done that, have the t-shirt. (You always get a t-shirt, no matter how big a balls-up it was).
Ever tried Agile development of a software library or of infrastructural systems? Stuff that needs to be thought out before publishing? Where experience counts? Where you don't have a team of 10 people dedicated to sprints of two weeks? Where produced software actually has to be maintained? In short, where you have a small shop that needs to make a difference.
Yes I have, SCRUM was the process used, and it all worked vastly better than the three failed projects before it (in our extreme waterfall shop). There is nothing magical about SCRUM, or any other process, it's mostly about letting good people do good work. The thing that SCRUM et al, gives you is a tight feedback loop, and that is a very useful thing if you have it all going nicely. I've worked in all kinds of setups, from super heavy process (which I just can't stand, who wants to sit around for 6 months just writing documentation and attending meetings?), to extreme isolation (here are the requirements, give us the result in 6 months), to agile of all different variations. I like SCRUM the best because I like working with other people, I like that the work is chunked, and I like that it deliberately only describes a tiny tiny part of the process. There are so many ways to do anything wrong, so many things that end up working despite human screw-ups, so little hard science around anything people oriented, and so much implied in vague terms like "agile" that these discussions are meaningless. Give me a couple of Devs of at least medium ability, a tester or two that know the product domain, and someone on the business side that is willing to talk product, and I can deliver you a successful project every damn time. Call it what you like.
I'm talking unnecessary use of tech that gets us nothing in return.
The major source for this exploit is going to be remote update of PLC firmware/logic. By remote, I don't mean "internet" but simply physically remote. This does give you something from a plant operation point of view as it is simply one more task that's automated, and potentially a very expensive task due to the dollars per hour for the task in question. So the tech does get you something, at the increased cost of additional "risk". These risks should be mitigable (security into the network, security of the network, security of the device), but it is certainly true that PLC level security is not what it should be. I expect we'll see things rapidly improve on this front as the IOT mass proliferation leads to many more problems, and hence more focus on the inherent weaknesses in this area, and hence forcing the big players to invest the necessary dollars in making their devices securable. SCADA and industrial automation has simply benefited from obscurity for a very long time and thus not had the selection pressure forcing the required evolution.
Let's say Theranos created a really slick USB device that lets a user do a blood test from their computer (stop laughing, it could happen).
Who's laughing? This already exists: I would hazard a guess that there are all kinds of patents around this tech. Seeing as the real innovation looks to be in the cool analog silicon interpreting DNA thing, I'd agree that the "driver" part is pretty much irrelevant.
You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page