tag:blogger.com,1999:blog-393540894130950585.post8791401147360099636..comments2024-03-22T00:23:29.865-07:00Comments on Never In Doubt: Tom DeMarco RecantsWard Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-393540894130950585.post-32501098919672134842010-02-16T05:05:41.664-08:002010-02-16T05:05:41.664-08:00neverindoubtnet.blogspot.com; You saved my day aga...neverindoubtnet.blogspot.com; You saved my day again.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-58190524819433234412009-07-22T14:56:59.844-07:002009-07-22T14:56:59.844-07:00Ward,
Well, I suppose you can hear it from me the...Ward,<br /><br />Well, I suppose you can hear it from me then: If there aren't tests, I won't even look at it.<br /><br />But I'll go further: If there aren't the right kinds of tests, I won't even look at it.<br /><br />This is a personal choice that comes from experiences of working on with high-performance projects. It's simply far too heart-breaking to drop into a project that hasn't understood the purpose of testing and how testing is done effectively. And further; a project whose management doesn't understand productivity beyond mere tool-driven efficiencies.<br /><br />Frankly, I haven't often heard many people in my own professional circle lay out a reasonable business case for TDD or BDD that would even convince me to use these things today, and I've been using TDD since 2000!<br /><br />It's really important that we understand the organizational and cultural effects and the organizational and cultural pre-conditions for these kinds of approaches. They're not tools. They're ways. They don't fit into every context, but I have yet to see a context that when steered toward the organizational and cultural qualities where TDD and BDD make sense that hasn't benefited.<br /><br />This is why I'm making a differentiation around local optima. Without broad experience in the ways as well as experience with the organizational and cultural aspects, then the perspective is bound to be distorted, and likely suffering from typical programmer distraction-by-tool-stimulation syndrome.<br /><br />I prefer to work on projects that are willing to embrace much higher performance than what can be delivered by mere tools, but I'm willing to use any tool that supports the organization as it changes its culture.<br /><br />I used to build systems with FoxPro. I used a primitive, ad hoc form of TDD. Those systems still work and are still in operation. They don't need to be changed, and have had few calls to be changed over the last 15 years. When they are changed, the productivity costs to the business borders on negligent. If I were to retrofit tests to those systems without changing their design, I might make the productivity problem even worse.<br /><br />Fit into a framework of organizational learning where a learning culture is leveraged methodically to raise expectations for productivity to a level above and beyond that which can be achieved by the mere tools that supported the journey, those tools are foundational.<br /><br />In the right context, TDD and BDD are foundational. I personally don't want to work anymore in the contexts where expectations for business productivity are lower than what can be achieved in a culture that understands TDD and BDD (for example) beyond the mere mechanics. It's like watching your best friend throw his life away on a video game addiction.<br /><br />There's no doubt that abruptly forcing new paradigms onto software development efforts that are facing the cumulative constraints of decades of primitive, sub-optimal productivity is no way to get some necessary software to see the light of day. But that's no reason to not begin to change culture and organization and tools and ways and means so that these conditions aren't perpetuated to the detriment of the businesses and the people they serve.<br /><br />The barriers to understanding things like TDD and BDD are rarely intellectual. They're typically organizational, and typically within organizations that continue to reinforce primitive ideas about management and culture.<br /><br />So, I don't want to look at something if it doesn't have tests, and the right kind of tests that evidence the kinds of culture and organization that won't continue to break my heart. Call it a personal weakness, but I can't erase my memory and experience in cultural and organizational change as easily as I can erase a file.Anonymoushttps://www.blogger.com/profile/10851121926952875016noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-27970514196780531112009-07-22T12:10:04.602-07:002009-07-22T12:10:04.602-07:00Tobin,
Project A has a much smaller return on inv...Tobin,<br /><br />Project A has a much smaller return on investment. Think of ROI as the project's profit (it's not organizational profit per se, but I'm representing it this way to create a temporary, synthetic context learning context).<br /><br />If the project's profit margin is so small, then the profit can be disrupted by smaller problems than if the profit margin were large.<br /><br />Because project A's profit is a narrow sliver, Project A is arguably well-served by rigorous controls that see that little-to-no amount of disruption enters the context.<br /><br />Those stricter controls are in place on project A to keep it from even minimal deviations because it has minimal return.<br /><br />Implicit in all of this is the recognition of the force of disruptions. Some kinds of disruptions might have minimal deviation, some might have maximal. Some disruptions are very small, but happen repeatedly or constantly so that they are incredible risk.<br /><br />Ultimately, we're talking about statistical process control here, which means measurement, metrics, and their use to manage work to a goal. Statistical process control isn't a substitute for ability, it's a support mechanism for learning about certain kinds of disruption and for shaping improvements.Anonymoushttps://www.blogger.com/profile/10851121926952875016noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-88347655399745195912009-07-22T12:02:15.091-07:002009-07-22T12:02:15.091-07:00@Scott - no doubt. That was exactly what he meant....@Scott - no doubt. That was exactly what he meant. And that alone makes it fascinating.<br /><br />But why squander the opportunity to hold the same mirror up to ourselves? What is this century's cant?<br /><br />I'm convinced we really agree on this one. I am not knocking TDD or BDD one bit. I am knocking comments I have heard (not from you) such as "if there aren't tests, I won't even look at it." Or the project is doomed because it lacks such-and-such.<br /><br />Maybe it would be better with such-and-such. Maybe lack of such-and-such makes it a poor example. But is it good stuff? Would it have seen the light of day or would it have been crippled had we insisted that those inspired to write it follow our practices? There are some amazing Excell, Access, and FoxPro apps out there. They live on because they do good service.<br /><br />I can't bring myself to recommend these technologies. But I must confess: too many of my "beautifully crafted" apps have slipped beneath the dark waters of irrelevance.<br /><br />I still wish I had invented the pet rock.<br /><br />Cheers, WWard Bellhttps://www.blogger.com/profile/10977457957771020146noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-33777419463786463742009-07-22T11:58:04.657-07:002009-07-22T11:58:04.657-07:00This might be dumb, but I don't understand the...This might be dumb, but I don't understand the following statement made by Demarco in the article:<br /><br />"What’s immediately apparent is that control is re- <br />ally important for Project A but almost not at all <br />important for Project B. This leads us to the odd <br />conclusion that strict control is something that <br />matters a lot on relatively useless projects and <br />much less on useful projects."<br /><br />Why would A need more control than B? What did I miss!Tobin Harrishttps://www.blogger.com/profile/02203581553681366247noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-62209697265753968472009-07-22T11:33:01.718-07:002009-07-22T11:33:01.718-07:00Ward,
> his challenge: your project has
> v...Ward,<br /><br />> his challenge: your project has<br />> value in inverse proportion to your<br />> concern for proper s/w engineering.<br /><br />In the context of the article that we're talking about, and in context of Tom DeMarco's work, software engineering has a specific meaning, and that meaning arguably has nothing to say directly about TDD or BDD for example.Anonymoushttps://www.blogger.com/profile/10851121926952875016noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-35835043265640297632009-07-22T11:26:02.932-07:002009-07-22T11:26:02.932-07:00@ Mathias - good reference.
@Scott .. right. And ...@ Mathias - good reference.<br /><br />@Scott .. right. And I think you make this point at length in your post <a href="http://is.gd/1HStC" rel="nofollow">The Myth of Developer Productivity"</a>.<br /><br />If I recall, the essence of your argument is that something truly improves productivity if it improves the entire production chain in a sustainable fashion.<br /><br />Mr. DeMarco's more far reaching point is that we have to keep the value of the project in mind at all times. That "value" is constantly on the move as what had priority 'x' today has "u" or "z" tomorrow. Hence his advice, "be ready to ship it any time because we may say 'enough' at any time."<br /><br />This would be cliche without his twist ... his challenge: <b>your project has value in inverse proportion to your concern for proper s/w engineering</b>. Ouch!<br /><br />@ctford and @chris ... I think you are in violent agreement. To say "substance trumps process" still leaves room for process to matter.Ward Bellhttps://www.blogger.com/profile/10977457957771020146noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-40170765064549122332009-07-21T15:12:01.658-07:002009-07-21T15:12:01.658-07:00"Saying software engineering's time is go..."Saying software engineering's time is gone is an overstatement."<br /><br />Is it? I don't think so. <br /><br />Look at it this way: Software development is a new discipline, relatively speaking. It doesn't have the time under its belt that other disciplines have. It doesn't have the legacy of ship building, or bridge engineering, or painting, or music writing. <br /><br />Some disciplines are clearly more science and engineering than craft or art. Software development? No one knew how to classify it or manage it or anything when it came on the scene. So they thought it was more of an engineering discipline. Maybe they were wrong? I've always *felt* like it was more of a craft than a science... And that's the way I read Mr. DeMarco's paper.Chris Holmeshttps://www.blogger.com/profile/12677831161747539594noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-18624250102491500172009-07-21T13:23:55.181-07:002009-07-21T13:23:55.181-07:00> If you find that TDD or DDD or BDD
> … are...> If you find that TDD or DDD or BDD<br />> … are what you talk about first,<br />> are you making the same category of<br />> mistake?<br /><br />Yes... if you're talking about them as local optima, which, unfortunately, many programmers often do.Anonymoushttps://www.blogger.com/profile/10851121926952875016noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-6769692099556663992009-07-18T04:31:10.446-07:002009-07-18T04:31:10.446-07:00Saying software engineering's time is gone is ...Saying software engineering's time is gone is an overstatement. A maturing movement will always pass from the "X is always good" stage to "properly done X is good" stage.<br /><br />Hopefully De Marco's article will help to dispell the zeolotry that Mathias mentioned in his comment.ctfordhttps://www.blogger.com/profile/05464902188219000642noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-68385014222384624262009-07-17T17:36:07.248-07:002009-07-17T17:36:07.248-07:00This reminded me of a book I read a while back, &q...This reminded me of a book I read a while back, "Priceless: On Knowing the Price of Everything and the Value of Nothing "; one of the points is that economists spend so much time trying to "price" things that they miss the bigger picture. I guess you could paraphrase this into "software engineering: on controlling everything and delivering nothing"...<br />It's also another illustration of the fascinating process by which a smart idea is expressed by a smart individual, but as the idea gains wider adoption it also gets simplified to the absurd, embraced by zealots with no taste for nuance!<br />That being said, I have to tip my hat to someone going against "software engineering" as a whole. In the realm of provocative statements, this is top material, and great food for thought!Mathiashttp://www-clear-lines.com/blognoreply@blogger.com