A topic sometimes debated on XML-Dev is that "worse is better", but the real topic is "simple is often better". Not always, but often. There are lots of examples from HTML (not so simple anymore), blogging formats, and further back, T-34 Soviet tanks, and not so far back, pagers. As one reads about 9/11 it quickly becomes apparent that the more sophisticated systems failed most frequently. The simpler systems like pagers were more effective but unfortunately, least distributed.
For those of us in the public safety industry, this is a lesson to be taken to heart. Command and control are worthless without communications and intelligence. While the dispatch center does thrive on sophisticated mapping and analysis technology, a command is most effective when it is presented in its simplest imperative form, such as, EVACUATE NOW!
4 comments:
Sometimes I'll take either side in a debate to see to it the debate takes up all of the issues. Not surprisingly, that position is misunderstood in communities that insist on adherence to the party position. The joy of blogging is that I can relate my reactions closer to real time. You are right that 'worse is better' is a rotten way to start the debate, but where the energy to create logic stems from the emotional, it is a way to start the fight.
1. Simple as possible. No logistics expert argues with that one. More moving parts means more fault modes means a smaller Mean Time Between Failure.
2. "As possible" means that one analyzes the device in the context of the mission and ensures that the failure modes of the device match the potential situations one will apply it in.
3. The web as 'the scalable universe' leads to one believing that if it doesn't scale to the web it isn't worth working on. This ignores that there are scales of application that are not isomorphic to the web. Since the web architecture has the conceit that it is isomorphic to the universe, and given Boltzman entropy, the web device can become simpler than is useful for some applications. In other situtations, both the public internet and the web device perfectly match the requirement. Caveat emptor should prevail but the reality is caveat vendor. XML is a product of simplifying SGML in light of lessons learned on the web. In most cases, it is the ideal messaging format but not all.
A cell phone is a great way to communicate when one is mobile and the situation is relatively benign. On the other hand, as someone who recently had a car in the shop for three weeks because a benign mammal with a cell phone tucked neatly under her ear rammed it from the rear, some situations are not so benign. The situation on 9/11 crushed first responders between their major incident plans and the unanticipated results of jet fuel burning furiously against metal 1000 feet in the air, and others in a situation where the dispatch centers were coping with unreliable information plus the urgency of their location.
Overbuilt systems tend to fail in the face of catastrophes. Even WWW systems. Even simpler systems such as RF.
The problem of catastrophe in formal systems have been studied over the years in various applications from biological systems, plantetary systems, to command and control systems, and so on using varying theories of chaos and complexity. Most of these can be boiled down to situated networks of communicating nodes. As the frequency of exchange and the complexity of given messages rises, so does the failure rate. Catastrophes are full of unknown unknowns. It is difficult to create major incident plans for such. Major incident plans rely on the ubiquity of reliable assets among these, communication devices. The rule of thumb seems to be that in such situations, simpler systems are more reliable. Selah.
Unfortunately, the procurement cycle precedes the fielding of assets and it is often complicated by consultancy and the desire for assets that confer status. For that reason, logistics analysts are used extensively by the military and should be by public safety procurement consultants.
Web technology receives a lot of press. That makes it a status conferring technology. But in some cases, it isn't the best solution or effective. Platform vendors must take on the role of logistics analysts and step up to the job of leading their industry instead of only reacting to RFPs.
BTW, Mike, I should add this: the art of analysis for design should include the notion that it is very important to identify where or in which components simplification benefits any user. Simplification for the developer can result in complexification for the end user. A common result of thin client design is that the user has to wade through many pages and forms to complete a complex transaction that could be better organized for the end user by a fat client with more local state management.
Then the problem that the user model is another 'no size fits all' challenge is to be accounted for. Jakob Nielsen might not be the best guide here in all cases.
Hi blogger:)
Well done - I can hardly receive a comment on my blog. The only comments I have are ones that my brother created:) Hope you keep yours good as much as it is now! Cheers:)
Regards,
Remove Adware
Hi blogger:)
I shall inform all my school friends about this blog... they were searching for the same information a couple of days/weeks ago. If they still need that information they will adore your blog:)
Regards,
blocker spyware
Post a Comment