Amit Ranjan at Webyantra points to the enormous leverage that software has on our day to day lives. The consequences of bugs are usually thought of in terms of customer dissatisfaction, schedule slippages and maybe at worst a bunch of pink slips. Next time someone trivializes testing or defect fixing, make them read this:
Explosion of Ariane 5, 1996 due to “…conversion of a 64 bit integer into a 16 bit signed integer lead to an overflow…”
Loss of Mars Climate Orbiter, 1999 due to “…mix-up between pounds and kilogram….”
Mars Polar Lander, 1998 due to “…software error that mistakenly identified the vibration caused by the deployment of the lander’s legs as being caused by the vehicle touching down on the Martian surface….”
Loss of Mariner 1, 1962 due to “..period instead of comma in FORTRAN DO-Loop…”
Breakdown of AT&T’s long-distance telephone network, 1990 due to “…a single line of buggy code in a complex software upgrade implemented to speed up calling caused a ripple effect that shut down the network….”
USS Yorktown dead in the water, 1998 due to “….input and Division by ‘0’. „ X / 0 = undefined…”
MIM-104 Patriot Missile Failure, 1991 due to “…rounding error”
Shutdown of 5 nuclear reactors, 1985 due to “..use of arithmetic sum of variables instead of the square root of the sum of the squares of the variables….”
Denver International Airport, 1994 due to “…baggage handling system broke down because of numerous bugs….”
Reading this definitely made me more reverent about my own beginnings- doing Y2K fixes. I used to resent the work and thought it as 'dumb' and spent a lot of time writing automation tools instead. :-)
programming
Linking and Sharing
If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Rounding errors and WW-III
Trackback
Trackback URI for this entry:
http://www.prakashonsoftware.org/blog/index.php/2008/08/25/rounding-errors-and-ww-iii/trackback/
I recently attended the JAX India seminar which covered topics like SOA and enterprise architecture. The organizers have put up some presentations online. I particularly liked the presentations by Tobias Israel, Ramesh Loganathan and Thilo Frotscher. Thilo is a top quality web services trainer/ architect and I richly recommend him for any web services related corporate training requirements. You can contact him at contact@frotscher.com. Note : I have no business relationship or personal friendship with Thilo. Just loved his sessions !
programming Technology Web2.0
Linking and Sharing
If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: JAX India -2007
Trackback
Trackback URI for this entry:
http://www.prakashonsoftware.org/blog/index.php/2007/06/05/jax-india-2007/trackback/
The McKinsey report on Web 2.0 and the relative lack of corporate interest in mashups made me dig a little deeper. I pulled out some data from the programmable web and did a run of MsExcel and this is what the top ten mashup API categories look like.
Here are some quick thoughts:
All the categories are consumer internet based.
Mapping and search predominate thanks to Google and Yahoo
The enterprise potential of mashups is largely untapped at least as far as these stats go.
Consumer Internet programming Technology Web2.0
Linking and Sharing
If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: The mashup API roll call.
Trackback
Trackback URI for this entry:
http://www.prakashonsoftware.org/blog/index.php/2007/04/12/the-mashup-api-roll-call/trackback/
UI design is something that receives less importance compared to the holy grail of coding. But we all hate websites with crappy layouts and cumbersome navigation structures. I came across this really neat tradeoff matrix on UI design by Mike Padilla.
| Design | Benefit | Cost |
|---|
| Shallow information architecture | Fewer clicks to find info | More clutter |
| Deep information architecture | Clean, reduced clutter | More clicks to find info |
| Small font | More information per screen | More difficult to read for some users |
| Large font | Easier to read | Less information per screen |
| Drop-down box | Selection amongst many choices using limited space | Hidden choices |
| Radio buttons | See all selections at all times | Additional space required, clutter |
| Icons | Quick recognition once learned, aesthetically pleasing | Must be learned |
| Text links | Always understood | Must be read, do not stand out as actionable items as much from other text |
| Abbreviations | Save space | Must learn or recognize |
| Full text | Easily understood | Requires additional space |
| Keyboard shortcuts | High speed of data entry | Must be learned |
| Point and click | Intuitive | Additional time required for interaction due to increase motor skills required |
Mike goes on to suggest the following factors to judge a UI:
Ease of learning and memorability Efficiency of use Error frequency, severity, and recovery Subjective satisfaction
programming Technology
Linking and Sharing
If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: UI design choices.
Trackback
Trackback URI for this entry:
http://www.prakashonsoftware.org/blog/index.php/2007/01/14/ui-design-choices/trackback/
Tell a friend
