{"id":277,"date":"2015-02-20T20:42:35","date_gmt":"2015-02-20T20:42:35","guid":{"rendered":"http:\/\/dawilson.co.uk\/blog\/?p=277"},"modified":"2015-02-20T20:52:17","modified_gmt":"2015-02-20T20:52:17","slug":"good-luck-and-watch-out-for-bugs","status":"publish","type":"post","link":"https:\/\/dawilson.co.uk\/blog\/good-luck-and-watch-out-for-bugs\/","title":{"rendered":"Good luck, and watch out for bugs!"},"content":{"rendered":"<p>The latest issue of\u00a0<a href=\"http:\/\/www.ganssle.com\/tem-subunsub.html\" target=\"_blank\">The Embedded Muse<\/a>\u00a0contains the following quote regarding the use of the term &#8220;bug&#8221; by software developers:<\/p>\n<blockquote><p>We could, for instance, begin with cleaning up our language by no longer calling a bug &#8220;a bug&#8221; but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz., with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it is a disguise that the error is the programmer&#8217;s own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect. While, before, a program with only one bug used to be &#8220;almost correct,&#8221; afterwards a program with an error is just &#8220;wrong.&#8221; &#8211; Edsger W. Dijkstra.<\/p><\/blockquote>\n<p>After reading this statement I began to think about how I\u00a0use the word &#8220;bug&#8221; myself, and also how this term has been used and perceived by other software engineers that I have worked with.<\/p>\n<p>My conclusion is that I would\u00a0tend to agree with Dijkstra in that this jovial little word often provides a handy way for programmers to deflect blame away from themselves for what are, in reality, mistakes. Perhaps though this is not always such a bad thing.<\/p>\n<p>When working closely with others, keeping things civilised should be a top priority.\u00a0I&#8217;m not sure that scrutinising the &#8220;errors&#8221; created by colleagues is helpful in this situation, and\u00a0maybe apportioning some of the blame instead to &#8220;the bugs&#8221;\u00a0is a perfect way to keep things light-hearted.<\/p>\n<p>The following\u00a0message was written in my leaving card by a fellow software engineer\u00a0when I moved on to a new company, and I think it demonstrates nicely how this small\u00a0word can\u00a0play an effective part in building camaraderie within a team.<\/p>\n<figure style=\"width: 1115px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/dnrgxa.dm2302.livefilestore.com\/y2pi20DWGPI4OksDO-h9hHQT8ODEAEIuZEQNPQ60xSudgCO4raC-5REj3AzDPuhKEOV8mdryBRvjJ3M2PDmxkF9CIV7PdkeBlo_kzwlieAlCgfPA24ht6IktUMegfEZ-reE-QxcGGHMS90TnnCHgeotVA\/WP_20150220_001.jpg?psid=1\" alt=\"Good luck, and watch out for bugs!\" width=\"1115\" height=\"1115\" \/><figcaption class=\"wp-caption-text\">Good luck, and watch out for bugs!<\/figcaption><\/figure>\n<p>It is important to note however that these imaginary little mites cannot be made scapegoats for us. We must take responsibility for our own mistakes and ensure that we learn from them.<\/p>\n<p>So in this spirit of self-analysis, I have tried to come up with the top three sources of bugs in the projects that I have worked on,\u00a0together with\u00a0the relative heuristics that could be\u00a0applied to overcome them.<\/p>\n<h3>1. Increased code size and complexity<\/h3>\n<p>Large, unwieldy and complex\u00a0pieces of source code make it difficult to spot both your own mistakes and the mistakes produced by others.<\/p>\n<p><em>Heuristic: Build systems using\u00a0software components that are as small and simple as possible.<\/em><\/p>\n<h3>2. Poor understanding of the hardware and software environment<\/h3>\n<p>A\u00a0poor understanding of the programming language, operating system or hardware platform used on a project can lead to subtle errors that may\u00a0not become\u00a0immediately apparent. This can lead to strange and erratic behaviour occurring during longer term use.<\/p>\n<p><em>Heuristic: Seek to fully understand the hardware and software environment. Document any assumptions and have them checked by someone who has a fuller understanding of the system.<\/em><\/p>\n<h3>3. Hacked code<\/h3>\n<p>Changes made to code\u00a0during a frantic debugging session can easily be forgotten about and may lead to problems\u00a0if they make their way into\u00a0production code.<\/p>\n<p><em>Heuristic:\u00a0Carry out\u00a0debugging\u00a0using a dedicated copy of the\u00a0source code.\u00a0Only copy fixes into the production code once they are proven.<\/em><\/p>\n<p>&nbsp;<\/p>\n<p>Of course there are many other sources of bugs, but these three made the top of my personal list.\u00a0It would be great to read about your own top\u00a0sources and their\u00a0related heuristics in the comments section below.<\/p>\n<p>Whatever the project you&#8217;re currently working on: Good luck with it, and watch out for bugs!<\/p>\n<p>DW.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The latest issue of\u00a0The Embedded Muse\u00a0contains the following quote regarding the use of the term &#8220;bug&#8221; by software developers: We could, for instance, begin with cleaning up our language by no longer calling a bug &#8220;a bug&#8221; but by calling it an error. It is much more honest because it squarely puts the blame where &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/dawilson.co.uk\/blog\/good-luck-and-watch-out-for-bugs\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Good luck, and watch out for bugs!&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[27,6],"class_list":["post-277","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-bugs","tag-software-engineering"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/posts\/277","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=277"}],"version-history":[{"count":25,"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/posts\/277\/revisions"}],"predecessor-version":[{"id":302,"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/posts\/277\/revisions\/302"}],"wp:attachment":[{"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=277"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=277"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dawilson.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=277"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}