SoylentNews is people
SoylentNews
Arthur T Knackerbracket has found the following story:
Gartner defines Bimodal IT as: “the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed”.
I find myself more than a little bemused by the concept. First of all, why would I want to manage two separate modes of activity? That means that either I have to employ different people with specialisms in different approaches (expensive) or I have to take on people who are skilled in both areas (which by definition means they're not going to be best-of-breed in either).
Second, I have a strange liking for the concepts that Gartner mentions in Mode 1: safety and accuracy. I find it useful that my IT systems don't kill people; here in Jersey, for example, it's frowned upon if too many employees die in tragic business systems accidents. And in my experience, the CFO tends to be quite irritable if the month-end numbers don't add up. I also find security and integrity fairly useful too, along with availability – all things that can suffer in Gartner's so-called Mode 2 at the expense of agility and speed.
Although the term “bimodal IT” is relatively new, the concept isn't. Back in the 1990s I worked in an environment with two distinct approaches to IT: one slow, steady and methodical, and the other fast-moving and bleeding edge. Did the latter break more than the former? No, actually it didn't – but only because it was done by a small number of very technical people who could respond quickly to issues. Did it bring advantages? Yes: it was doing IP-based wide area stuff long before the other part of the IT world.
Would I go back to that setup tomorrow? Not on your nelly – it put a group of techies out on a limb, largely unsupportable by the other team and hence permanently lumbered with supporting bleeding-edge technology whenever it threw a tantrum and interfacing it tenuously into the core systems in the face of reluctant sighs from the core support group.
I had another of these “parallel” examples more recently, when a new senior techie decided that he would spin up cloud-based servers seemingly at random alongside the company's well-managed, well-documented and extremely stable infrastructure. He took exception, for some reason, when someone called him a “f**king cowboy”.
(Score: 2) by c0lo on Sunday August 07 2016, @03:01AM
From Quality Assurance at all stages of the development process, not just a Quality Check at the end of a stage/the process.
Doesn't matter if your product passes the tests (whos tests?) if the architecture is brittle or your algos are poorly chosen or your code looks like an entry in an obfuscation context or your hardware is top class but your customer's is just average.
If it passes those tests either your test set is incomplete**, or you just got lucky this time around - do you want to bet you'll continue to be lucky forever, release after release?
My point? Testing is part of the QA and QA is part of the development of any safe system - why should testing get a special mention?
---
** Except for "hello-world" types of products, nobody is going to have all the all the money and time to thoroughly test all the combinations possible solely at the end of the cycle.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by khallow on Sunday August 07 2016, @03:35AM
I find it weird that the writer forgot about testing.
My point? Testing is part of the QA and QA is part of the development of any safe system - why should testing get a special mention?
Because it was a place where the so-called "agile" development is routinely used. After all, why have all those incomplete test which only cover some small portion of your testing space when you can just have the right one which completely tests your program correctly? After all, how hard could that test be to build? \sarc
(Score: 2) by c0lo on Sunday August 07 2016, @09:16AM
You can't. There's no such a thing as a "complete test plan". That's an ideal never to be reached (and that's true no matter the chosen dev life cycle)
A system can go correctly in a limited number of ways (what the programmers do is to "carve" a reduced set of state/transitions from the whole possible set of all programs; they are implementing what the reduced model of reality is required).
However, for every "correct" ways of doing things there are more ways in which the things may go wrong; test partitioning or not, there is no way in which you can test all the wrong conditions and see the program/system is "safe to use under adverse conditions". Why do you think fuzz testing [wikipedia.org] has a place in the toolset even if passing such a "test" offers no warranties of correctness, completeness, robustness of the tested product.
Want another example? How many times did you see anyone testing the installer of a program against installing in a wrong location? How many "wrong locations" can you imagine?
Does you list include installation on a removable device? Maybe a "write once" one mounted there?
What about the "trash bin"? No?
How many other cases of "wrong places" may exist that you (or anyone) cannot imagine now?
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by khallow on Sunday August 07 2016, @12:08PM
(Score: 2) by c0lo on Sunday August 07 2016, @02:06PM
If my understanding is right, you asked "Why there is no mention to testing when it comes to software safety?".
And I said: "Testing is a part of development, as is coding, software arch/design and all the rest. Why do you think testing is worth a special mention, when all the others contribute equally to the safety?"
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by khallow on Sunday August 07 2016, @03:00PM
And I said: "Testing is a part of development, as is coding, software arch/design and all the rest. Why do you think testing is worth a special mention, when all the others contribute equally to the safety?"
I think testing warrants special mention unlike the other parts you mention because it was an important example of flexibility and "agility". For the most part, tests are lightweight. They're meant to be low effort to construct (otherwise you're not going to make many of them), rapid to deploy and modify. If a new issue shows up, you don't want the tests coming out a few years later.