{"id":84,"date":"2005-09-11T04:18:31","date_gmt":"2005-09-11T04:18:31","guid":{"rendered":"http:\/\/alephnaught.wordpress.com\/2005\/09\/11\/death-march\/"},"modified":"2008-10-31T16:38:12","modified_gmt":"2008-10-31T23:38:12","slug":"death-march","status":"publish","type":"post","link":"https:\/\/www.alephnaught.com\/Blog\/2005\/09\/11\/death-march\/","title":{"rendered":"Death March"},"content":{"rendered":"<div id=\"content_div-84\">\n<ul>\n<li><strong>Title: <\/strong><a href=\"http:\/\/www.amazon.com\/exec\/obidos\/tg\/detail\/-\/013143635X\/qid=1126437427\/sr=2-1\/ref=pd_bbs_b_2_1\/102-9495726-4240950?v=glance&amp;s=books\" target=\"NewWindow\">Death March<\/a><\/li>\n<li><strong>Author: <\/strong>Edward Yourdon<\/li>\n<li><strong>Paperback: <\/strong>304 pages<\/li>\n<li><strong>Publisher: <\/strong>Prentice Hall PTR; 2 edition (December 7, 2003)<\/li>\n<li><strong>ISBN: <\/strong>013143635X<\/li>\n<\/ul>\n<p>Two things of interest I found in <span style=\"text-decoration: underline;\">Death March<\/span> by Edward Yourdan:<\/p>\n<ul>\n<li> <em>Formal risk management<\/em> &#8212; This is a concept I&#8217;ll discuss later in<br \/>\nthis chapter.<\/li>\n<li> <em>Agreement on interfaces<\/em> &#8212; hardware interfaces, software interfaces,<br \/>\nand interfaces between your system and other external systems.<\/li>\n<li> <em>Peer reviews<\/em> &#8212; inspections, walkthroughs, reviews, etc. These are<br \/>\ncommonly understood, but often rejected by death march projects, for they<br \/>\nfeel the effort will slow them down. Intellectually, most of us agree that<br \/>\npeer reviews are beneficial, but given the kind of pressure we see in death<br \/>\nmarch projects, there&#8217;s a tendancy for everyone to hunker down and churn out<br \/>\nhis or her own work, without bothering to have it reviewed by other team members.<\/li>\n<li> <em>Metric-based scheduling and management<\/em> &#8212; this says that we should<br \/>\nbase our schedules and estimates on metrics derived from previous projects.<br \/>\nBut as noted earlier, there may not have been any previous death march projects,<br \/>\nand if there were any, it&#8217;s unlikely that anyone bothered recording any useful<br \/>\nmetrics (other than a body count of human casualties). But, if there are any<br \/>\nmetrics available from &#8220;normal&#8221; projects, these can be used to calibrate the<br \/>\nestimates being produced in the death march project &#8212; if only to see how<br \/>\nhysterically optimistic those estimates really are!<\/li>\n<li> <em>Binary quality gates at the &#8220;inch-pebble&#8221; level<\/em> &#8212; i.e., rather<br \/>\nthan having milestones every three months, during which the project team reports<br \/>\nthat they&#8217;re 97 percent done with all coding, there should be weekly, or even<br \/>\n<em>daily<\/em> inch-pebbles with &#8220;binary&#8221; indications of progress. One means<br \/>\nof accomplishing this is the &#8220;daily build&#8221; strategy discussed later in this<br \/>\nchapter.<\/li>\n<li> <em>Project-wide visibility of project plan and progress vs. plan<\/em> &#8212;<br \/>\nthis is consistent with my recommendations in earlier chapters. Things are<br \/>\ntough enough in a death march project without having the manager hide the<br \/>\nstatus from the rest of the team.<\/li>\n<li> <em>Defect tracking against quality targets<\/em> &#8212; one of the ideas here<br \/>\nis that defects identified, tracked, and resolved <em>early<\/em> in the development<br \/>\nprocess cannot only give an indication of the defect levels in the final delivered<br \/>\nsystem, but can also eliminate defects when they are relatively inexpensive,<br \/>\nrather than waiting until the system testing stage of the project.<\/li>\n<li> <em>Configuration management<\/em> &#8212; whether this is called version control,<br \/>\nsource code management, or some other term, it&#8217;s usually regarded as an essential<br \/>\npractice in most high-pressure projects.<\/li>\n<li> <em>People-aware management accountability<\/em> &#8212; alas, this is something<br \/>\nthat most death march projects <em>don&#8217;t<\/em> pay enough attention to; as mentioned<br \/>\nearlier, manay death march projects are set up as suicide missions or kamikaze-style<br \/>\nprojects.<\/li>\n<\/ul>\n<p style=\"padding-left: 60px;\"><sub><span style=\"text-decoration: underline;\">Death March<\/span>, Edward Yourdan, pp. 152-153.<\/sub><\/p>\n<ul>\n<li><em>Innocent<\/em> (has never heard of Technology X) &#8212; this obviously requires<br \/>\nno time at all.<\/li>\n<li><em>Aware<\/em> (has read an article about Technology X) &#8212; roughly an hour,<br \/>\nin most cases, is enough for a software developer to be in a position where<br \/>\nhe or she can voice strong opinons about the advantages and disadvantages<br \/>\nof the tool, even though he or she has never seen or used it.<\/li>\n<li><em>Apprentice<\/em> (has attended a five-day workshop) &#8212; a week, perhaps<br \/>\ncompressed into two days because of the pressure of a death march project.<br \/>\nBut, note that at this point, the developer has probably done nothing more<br \/>\nthan play with canned turorials provided by the vendor, or dabbled with a<br \/>\nsmall exercise to illustrate the features of the tool. He or she hasn&#8217;t encountered<br \/>\nthe glitches, shortcomings, and &#8220;gotchas&#8221; of the tool; he or she hasn&#8217;t seen<br \/>\nhow (or if) it will scale up for large, complex projects; he or she hasn&#8217;t<br \/>\ntried to integrate it with most of the other tools in the environment.<\/li>\n<li><em>Practitioner<\/em> (ready to use Technology X on a real project) &#8212; a month<br \/>\nis probably required to explore the nuances of the tool and become sufficiently<br \/>\ncomfortable to use the tool on a &#8220;real&#8221; project.<\/li>\n<li><em>Journeyman<\/em> (uses Technology X naturally on the job; complains bitterly<br \/>\nif it is taken away) &#8212; this usually takes 6-12 months, and if the tool really<br \/>\nis a silver bullet, the developer becomes an evangelist, doing his or her<br \/>\nbest to persuade everyone that it&#8217;s the most wonderful tool on earth.<\/li>\n<li><em>Master<\/em> (has internalized the details of Technology X; knows when<br \/>\nto break the rules) &#8212; usually two or three years, which also means that the<br \/>\ndeveloper has survived through two or three new product releases, has found<br \/>\nall of the support groups and discussion groups on the Internet, and knows<br \/>\nall of the unlisted phone numbers for the technical support gurus at the vendor&#8217;s<br \/>\norganization.<\/li>\n<li><em>Expert<\/em> (writes books, gives lectures at conferences, looks for ways<br \/>\nto extend Technology X into new galaxies) &#8212; Page-Jones was focusing on methodologies<br \/>\nin his paper, and it&#8217;s not clear that this applies to tools and technology.<\/li>\n<\/ul>\n<p style=\"padding-left: 60px;\"><sub><span style=\"text-decoration: underline;\">Death March<\/span>, Edward Yourdan, p. 187, from the <strong>Sevent Stages of Software Engineering Mastery<\/strong> by Page-Jones<\/sub><\/p>\n<\/div>\n<div class=\"translate_block\" style=\"display: none;\">\n<hr class=\"translate_hr\" \/>\n<a class=\"translate_translate\" id=\"translate_button_post-84\" lang=\"en\" xml:lang=\"en\" href=\"javascript:show_translate_popup('en', 'post', 84);\"><span>Translate<\/span><\/a><img data-recalc-dims=\"1\" src=\"https:\/\/i0.wp.com\/www.alephnaught.com\/Blog\/wp-content\/plugins\/google-ajax-translation\/transparent.gif?resize=16%2C16&#038;ssl=1\" id=\"translate_loading_post-84\" class=\"translate_loading colorbox-84\" style=\"display: none;\" width=\"16\" height=\"16\" alt=\"\" \/>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Title: Death March Author: Edward Yourdon Paperback: 304 pages Publisher: Prentice Hall PTR; 2 edition (December 7, 2003) ISBN: 013143635X Two things of interest I found in Death March by Edward Yourdan: Formal risk management &#8212; This is a concept I&#8217;ll discuss later in this chapter. Agreement on interfaces &#8212; hardware interfaces, software interfaces, and [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[3,4],"tags":[2344],"class_list":["post-84","post","type-post","status-publish","format-standard","hentry","category-books","category-computer","tag-books"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p2w3Qj-1m","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/posts\/84","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/comments?post=84"}],"version-history":[{"count":0,"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/posts\/84\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/media?parent=84"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/categories?post=84"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alephnaught.com\/Blog\/wp-json\/wp\/v2\/tags?post=84"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}