{"id":114,"date":"2011-12-18T12:49:45","date_gmt":"2011-12-18T19:49:45","guid":{"rendered":"http:\/\/www.jsnover.com\/blog\/?p=114"},"modified":"2013-09-22T18:01:17","modified_gmt":"2013-09-23T01:01:17","slug":"iranian-drone-hack-and-technical-debt","status":"publish","type":"post","link":"https:\/\/www.jsnover.com\/blog\/2011\/12\/18\/iranian-drone-hack-and-technical-debt\/","title":{"rendered":"Iranian Drone Hack and Technical Debt"},"content":{"rendered":"<p>This week I read the story about <a title=\"Iran hijacked US drone\" href=\"http:\/\/www.csmonitor.com\/World\/Middle-East\/2011\/1215\/Exclusive-Iran-hijacked-US-drone-says-Iranian-engineer-Video\" target=\"_blank\">how Iran hacked and captured<\/a> one of our most sophisticated military drones. It struck me that this was an excellent example of the potentially disastrous ramifications of ignoring technical debt. \u00a0It appears that the potential to spoof GPS was known and ignored for many years. \u00a0Acknowledging and managing technical debt is an issue that separates the whiz kids from the graybeards in the tech industry. \u00a0Let me start by saying that a military boof-a-rama of this magnitude is, by necessity, going to be followed up with multiple misinformation campaigns so I doubt we\u2019ll really know what really happened for a few decades.\u00a0 Nevertheless it provides a teachable moment for us so let\u2019s explore this topic.<!--more--><\/p>\n<p>Technical debt is analogous to financial debt so let\u2019s start there.\u00a0 Imagine you are a fresh college graduate with a new job and a newly minted credit card.\u00a0 Thanks to the miracle of modern financial <a href=\"http:\/\/en.wikipedia.org\/wiki\/Svengali\">Svengalism<\/a>, you can buy things you don\u2019t have the money to pay for. \u00a0You use the card to get set up in a new apartment and\u00a0at the end of the month you have a choice, you can pay off the debt or you can pay the minimal possible. \u00a0Debt is not a problem if no one makes you pay attention to it.\u00a0 And there\u2019s the rub, at some point you reach\u00a0 your limit and the party comes to an abrupt halt.\u00a0 Not only do you have to start paying off your debt but you have accumulated a bunch of interest that needs to be paid off as well.\u00a0 At this point, you are screwed.\u00a0 You can\u2019t buy new stuff and you have to spend all your effort trying to pay off a mountain of debt.\u00a0 You pay and pay and pay but for all your effort and money going out, you have no new stuff to show for it \u2013 you are managing your financial debt.<\/p>\n<p>The same thing happens with technology.\u00a0 This is most clearly seen in startup companies but the same thing happens in most technology companies.\u00a0 At a tech startup, the most important thing to do is to get the right set of functions in the market as quickly as possible so you can start bringing money in.\u00a0 What this means is that you are often cutting corners \u2013 skipping documentation, ignoring supportability, deferring security work, doing quick and dirty designs vs. deep architectural work. \u00a0This might be a reasonable strategy for a startup because once you get the product out, you might get feedback that you need to go in an entirely different direction. \u00a0If that is the case, you can \u201cdeclare bankruptcy\u201d on your existing code, walk away from those debts and start on a new path.\u00a0 On the other hand, if you stick with that code, you have a technical debt which is going to have to be paid.\u00a0 In your\u00a0 next development cycle, you can either begin to pay down that technical debt or you can devote 100% of your resources on the next round of quick and dirty functions.\u00a0 Deciding when to start paying off your technical debt is what separates the whiz kids from the graybeards in the tech industry.<\/p>\n<p>I\u2019m sure most of us at some point have found ourselves on a project that was led by whiz kids that had completely ignored their technical debt and was now in shambles.\u00a0 I was hired at DEC to lead the turnaround of just such a project.\u00a0 The product was reasonably successful but the implementation \u201chad some issues\u201d.\u00a0 When I got onboard and did an assessment of where we were I was shocked \u2013 the product was a cobbled together hack using 18 (yes 18!) different languages.\u00a0 There was even some ADA code in there.\u00a0 I joked with one of the developers on the project saying, \u201cHow did that get in here?\u00a0 Did someone take a night course can decide to ship his homework in the product?\u201d \u00a0Imagine my horror when then answer came back, \u201cYes \u2013 that is exactly what happened\u201d.\u00a0 When we explained where the code base stood and what was required to move forward, the management team cancelled the project and decided to just release it with a few new bug fixes and features.\u00a0 The interesting aspect of this story is that the whiz kids responsible for this mess were viewed very positively \u2013 they got things done and delivered on time and they got promoted and moved on to go screw up bigger and better projects.\u00a0 This is an example of where ignoring technical debt lead to the death of a project.\u00a0 Often the results are less dramatic, you\u2019ll get a new version of the product with fewer new features.\u00a0 Sometimes the results of ignoring technical debt are much more dramatic.\u00a0 Like our drone.<\/p>\n<p>Drone technology is the darling of the US military\/industry\/political parties.\u00a0 They provide a tireless presence on the field of battle, they can project force without risking the political ramifications of putting US personnel in mortal danger, and they generate new military contracts for the latest and greatest technology.\u00a0 The original drones were relatively simple and effective monitoring devices. \u00a0They were great but had a lot of well understood problems.\u00a0 <a href=\"http:\/\/www.wired.com\/dangerroom\/2009\/12\/insurgents-intercept-drone-video-in-king-sized-security-breach\/\">The data they streamed back was unencrypted <\/a>so anyone could grab the signals and see what we saw as well as get detailed operational information about what we looked for and how we looked for it as well as how we operated the drones.\u00a0 The designers were able to anticipate some problems and attempted to address them. This provides us a great example of where you have to be just as vigilant about a mitigation as you are about the problem it tries to mitigate.\u00a0 The designers understood that there were various hostile and non-hostile situations where communications between the drone and the controllers would be severed.\u00a0 They addressed this by programming the drone to detect the situation and return home using GPS and a preprogrammed set of coordinates for the home base.\u00a0 And here is where the technical debt problem comes in.<\/p>\n<p>Apparently the military has known about the potential for <a href=\"http:\/\/www.wired.com\/dangerroom\/2011\/12\/iran-drone-hack-gps\/\">GPS to be spoofed for 20-30 years<\/a>.\u00a0 This is a technical debt.\u00a0 The Christian Science Monitor reports that what Iran did was to jam communications with the drone so it engaged it\u2019s \u201cfly home\u201d program and then spoofed the GPS signal to make it land in Iran.\u00a0 The Iranians now have some of our most sophisticated military technology because we failed to address our technical debt.<\/p>\n<p>When we decided to go-big on drones and transform them from a marginalized science project to the sharp point of the US military spear we faced a choice: we could either address our technical debt or we could add bells and missiles.\u00a0 It appears that we decided not to address our technical debt (or not to address it in time to avoid this mess).\u00a0 After all, where is the excitement in making things work?\u00a0 I\u2019m sure some argued that, \u201cThey do work, they just don\u2019t work as securely we&#8217;d like and we don\u2019t know that others can actually spoof it\u201d.\u00a0 Given a fixed budget, any money spent on addressing technical debt is money not spend adding new bells and missiles. \u00a0To ship is to choose. \u00a0And that is exactly the point &#8211; it is what separates the whiz kids from the graybeards.<\/p>\n<p>Whiz kids will ignore technical debts, putting 100% of the budget on new features. \u00a0They build houses of cards on foundations of sand and then move on before the waves come. \u00a0They\u00a0come off looking like superstars and then move on to screw up something bigger.\u00a0 As graybeards (and architects) we need to be the guardians of the future.\u00a0 We need to understand our debts and be vigilant in addressing them even though there is no clear and immediate benefit for doing so. \u00a0This is easier said than done. \u00a0It is easy when we are in charge and just set the rules. \u00a0It gets harder when we don&#8217;t own those decisions and need to advocate for them and fight for budget. \u00a0Few people are interested in hearing it so it takes courage to stand up and be a butthead to ensure the right things happen. \u00a0Some deal with it &#8220;off the books&#8221; by padding schedules with a fixed amount of overhead to address the issues. \u00a0One way of the other, it needs to happen or you end up with a disaster. \u00a0You can only avoid problems for so long and then you have to address them.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week I read the story about how Iran hacked and captured one of our most sophisticated military drones. It struck me that this was an excellent example of the potentially disastrous ramifications of ignoring technical debt. \u00a0It appears that &hellip; <a href=\"https:\/\/www.jsnover.com\/blog\/2011\/12\/18\/iranian-drone-hack-and-technical-debt\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-114","post","type-post","status-publish","format-standard","hentry","category-work"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/comments?post=114"}],"version-history":[{"count":22,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/114\/revisions"}],"predecessor-version":[{"id":210,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/114\/revisions\/210"}],"wp:attachment":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/media?parent=114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/categories?post=114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/tags?post=114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}