These fields are all optional and need only be supplied if you would like a direct reply. Subject Your email address Your real name

You must answer this! If you don't, my spam filtering will ensure that I never see your email. What's 8 plus five (in digits only)?

Please make your changes here and then
Editing tips and layout rules.
File: GracefulDegradation ''' <link rel="alternate" type="application/rss+xml" ''' href="/rss.xml" title="RSS Feed"> ********> width="25%" |>> ''' <a title="Subscribe to my feed" ''' rel="alternate" ''' href="https://www.solipsys.co.uk/rss.xml"> ''' <img style="border-width: 0px;" ''' src="https://www.feedburner.com/fb/images/pub/feed-icon32x32.png" ''' align="middle" ''' alt="" />Subscribe!</a> _ ''' <a href="https://twitter.com/ColinTheMathmo"> ''' <img src="https://www.solipsys.co.uk/new/images/TwitterButton.png" ''' title="By: TwitterButtons.net" ''' width="212" height="69" ''' alt="@ColinTheMathmo" ''' /></a> <<| ---- My latest posts can be found here: * ColinsBlog ---- Previous blog posts: * DiagrammingMathsTopics * OnTheRack * SquareRootByLongDivision * BeyondTheBoundary * FillInTheGaps * SoftwareChecklist * NASASpaceCrews * TheBirthdayParadox * TheTrapeziumConundrum * RevisitingTheAnt * TheAntAndTheRubberBand * IrrationalsExist * MultipleChoiceProbabilityPuzzle * RandomEratosthenes * WrappingUpSquareDissection * DissectingASquarePart2 * DissectingACircle * DissectingASquare * AnOddityInTennis * DecisionTreeForTennis * DecisionTreesInGames * AMatterOfConvention * DoYouNourishOrTarnish * BinarySearchReconsidered * TwoEqualsFour * TheLostPropertyOffice * TheForgivingUserInterface * SettingUpRSS * WithdrawingFromHackerNews ---- Additionally, some earlier writings: * RandomWritings. * ColinsBlog2010 * ColinsBlog2009 * ColinsBlog2008 * ColinsBlog2007 * ColinsBlogBefore2007 ******** !! Graceful Degradation - 2014/12/12 I first learned about graceful degradation from a colleague. He prefaced his story by saying that good people learn from their mistakes, but the best people learn from other people's mistakes. This is a bit like the saying in aviation circles that a good landing is one you can walk away from, an /excellent/ landing is when they can use the 'plane again ... But I digress. He told me how he learned about graceful degradation, and the message was clear. He was telling me about his mistake so I could learn from it. I wish more people were willing to make their mistakes public - the software industry would certainly benefit if it could learn from everyone's mistakes. And his story goes, in broad outline (I forget some of the details) like this. He made a comfortable living from programming electronic tills. At the time these were programmed in assembly language, and the best output you could hope for during debugging was to see whether it opened the till or not. It was difficult work because there were no simulators, no higher level languages, no debuggers, no single-steppers, no help at all, really. You wrote you code in assembler, transferred it to the machine, then tested it to see if it worked. Sometimes it did. My colleague was amazing at this work, which is why he could get contracts in it any time he wanted, and the money was good. So he worked about six months of the year, then did whatever he wanted the rest of the time. Except at Christmas. That was when one of his biggest mistakes would come back to haunt him. A large department store in a major capital city used tills that ran his program. It was one of the most sophisticated systems around. Each till would keep a list of items sold, and then a central computer would interrogate each till in turn and find out how much had been sold of each item. It would then keep track of how many remained in stock, and would project when a re-ordering would be necessary. Re-ordering was not automatic, but staff would be alerted when stock was low on any items and decisions could be made. They loved the system. Buffer stock could be reduced, reducing the store's overheads, and making the entire store more responsive to consumer demand. Except at Christmas. You see, every Christmas the system, in essence, would simply stop. An entire floor of tills would stop responding, refusing to accept further purchases for an unpredictable length of time, and then suddenly start working again. There was no apparent reason, no apparent rhyme, and nothing they could do except call my colleague and get him to come in and "fix the problem." But there was really nothing he could do either, even when he worked out what the problem was. And what was the problem? Capacity. Each till would keep its list of items sold, and then when asked, would dump the list to the central computer. Then it would go back to -patronising- servicing the customer requirements until being asked again. The problem was that during the heaviest time of the year, there was simply too much to download. The queue in the till would fill before the central computer got back to it, and so it would have to stop, and wait to download its data, before it could restart. Entire floors of tills would grind to a halt, waiting to download their data and restart. The floor would simply stop. Not good at the busiest shopping time of the year. Really not good. [[[>50 It's hard for most people these days to understand just how limited the computing hardware was at the time. People have emailed me or commented saying "What he should have done is XXXX", without realising that what they were suggesting was completely beyond the compute power available. This was over 30 years ago. ]]] The patch that was run at Christmas was to make each till run slightly slow. There was still the occasional "I'm full so I'm stopping" moment, but in general the system would limp along and not exhibit the catastrophic failure of entire floors stopping. The difficulty was in judging exactly /how/ slow to make the tills run. He also made the central computer contact the tills in a clever, pseudo-random way, and that meant that if one till stopped on a floor, the others would probably still be working. !! So what /*should*/ have been done? [[[>50 (Added later ...) Another option might have been to continue processing sales and not keep the inventory up-to-date. That would have all sorts of implications, and I have no first-hand knowledge of whether it was considered. Knowing my colleague, I'm sure it was. ]]] Apart from having a faster communications system that could deal with the load being placed on it, each till could notice when its queue was 80% full and start slowing down. Then the performance of the system as a whole would degrade gracefully. Sales would slow slightly, evenly across the store, and come to match the processing throughput. Of course it would have been better if the system had simply been faster, but when overloaded, degrading gracefully is usually a better option than simply stopping. Think about it next time you worry about system capacity. Is it better to halt and clear the backlog, or degrade gracefully and continue to serve your customers? ---- |>> | |>> <<<< Prev <<<< ---- DiagrammingMathsTopics <<| | : | |>> >>>> Next >>>> ---- LearningTimesTables <<| | ---- ********> ''' <a href="https://mathstodon.xyz/@ColinTheMathmo"> ''' <img src="https://www.solipsys.co.uk/images/Mastodon_Mascot.png" ''' width="256" height="280" ''' alt="https://mathstodon.xyz/@ColinTheMathmo" ''' /></a> ******** ''' <a href="https://mathstodon.xyz/@ColinTheMathmo/">You can follow me on Mathstodon.</a> _ _ _ _ [[[> ''' <a href="https://twitter.com/ColinTheMathmo">Of course, you can also<br>follow me on twitter:</a> ''' <a href="https://twitter.com/ColinTheMathmo"> ''' <img src="https://www.solipsys.co.uk/new/images/TwitterButton.png" ''' title="By: TwitterButtons.net" ''' width="212" height="69" ''' alt="@ColinTheMathmo" ''' /></a> ''' <img src="/cgi-bin/CountHits.py?GracefulDegradation" alt="" /> ]]] ********< <<| ---- !! Send us a comment ... ''' <form action="https://www.solipsys.co.uk/cgi-bin/FormMail.pl" method=post> ''' <input type=hidden name="recipient" value="colinsblogcomment@solipsys.co.uk" > ''' <input type=hidden name="subject" value="Blog comment : GracefulDegradation" > ''' <input type=hidden name="redirect" value="https://www.solipsys.co.uk/new/ThankYouForYourComment.html" > ''' <input type=hidden name="missing_fields_redirect" value="https://www.solipsys.co.uk/RequestError.html"> ''' <input type=hidden name="env_report" value="REMOTE_HOST, REMOTE_ADDR, HTTP_USER_AGENT" > ''' <input type=hidden name="print_blank_fields" value="1" > ********> width="47%" You can send us a message here. It doesn't get published, it just sends us an email, and is an easy way to ask any questions, or make any comments, without having to send a separate email. So just fill in the boxes and then ''' <font size="+4"><INPUT TYPE="submit" VALUE="CLICK HERE TO SEND"></font> ******** width="53%" ********< ''' <table cellpadding="5"> ''' <tr> ''' <td valign="top">Your name </td> <td valign="top">:</td> ''' <td> <input type=text name="realname" size="48"> </td> ''' <tr> ''' <td valign="top">Email </td> <td valign="top">:</td> ''' <td> <input type=text name="email" size="48"> </td> ''' </tr> ''' <tr> ''' <td valign="top">Message </td> <td valign="top">:</td> ''' <td> <TEXTAREA NAME="Message" ROWS=10 COLS=64></TEXTAREA> </td> ''' </tr> ''' </table> ''' <center> ''' <font size="+4"> ''' <INPUT TYPE="submit" VALUE="CLICK HERE TO SEND"> ''' </font> ''' </center> ''' </form> ********<