<div dir="ltr">Ancillary story.<div><br></div><div>On one occasion I did do a detailed business rule design to the extant of constructing a full on Zed document.  In this case there were 10-15K lines of completely opaque RPG code dealing with pricing.  Not a living soul on this planet understood how pails, buckets, gobs, and dump trucks full shadowy data (most of which at the end of the day, didn&#39;t influence a damn thing) were poured into said system and then machinations resulting in spitting out a price from the other end.  Think your digestive track here and you&#39;re pretty close.<div>
<br></div><div style>It took weeks to put the document together.  But ... when we went to code, it was the smoothest flowing constant stream effort to completion of any software project I&#39;ve experienced.  After code completion we found far more bugs in the spec than we did in the code.  Most of the issues were failures to uncover subtle corner cases (most of which were themselves bugs, legacy deprecated rules etc) in the RPG code.</div>
</div><div style><br></div><div style>Summary.</div><div style>Overall far less bugs.</div><div style>Lesser proportion of bugs were from variance between spec and code.</div><div style>Most bugs were in variance between spec and reality (actual business rules).</div>
<div style>Overall, I liked it the approach to the point where I would apply it again.</div><div style>Interestingly, I never have, though there have been a few situations where it would have been applicable.</div><div style>
<br></div><div style>These days, I&#39;d throw someone out the window who wanted to start coding from the get go with the idea we&#39;ll sort of Agile random walk the code and logic to the desired end state, as I will someone who advocating full on upfront MBase.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 11:36 AM, Richard Cleis <span dir="ltr">&lt;<a href="mailto:rcleis@me.com" target="_blank">rcleis@me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My experience is the same. But try to explain to a program or project manager that at least four things gradually change to complete a project: design, code, tests, and docs. I am no longer expecting to ever work on a project where the leaders do not insist each of those is a milestone completed in some exact order that was preconceived by someone who never finished a good project.<br>

<br>
rac<br>
<br>
On Mar 19, 2013, at 2:29 PM, Patrick Li wrote:<br>
<br>
&gt; My personal experience is that a good and detailed design is hard to<br>
&gt; get to *without* doing the coding.<br>
&gt;  -Patrick<br>
&gt;<br>
&gt; On Tue, Mar 19, 2013 at 1:50 PM, Jos Koot &lt;<a href="mailto:jos.koot@gmail.com">jos.koot@gmail.com</a>&gt; wrote:<br>
&gt;&gt; One remark down intermixed in your email.<br>
&gt;&gt; Jos<br>
&gt;&gt;<br>
&gt;&gt;&gt; -----Original Message-----<br>
&gt;&gt;&gt; From: <a href="mailto:users-bounces@racket-lang.org">users-bounces@racket-lang.org</a><br>
&gt;&gt;&gt; [mailto:<a href="mailto:users-bounces@racket-lang.org">users-bounces@racket-lang.org</a>] On Behalf Of Hendrik Boom<br>
&gt;&gt;&gt; Sent: martes, 19 de marzo de 2013 15:15<br>
&gt;&gt;&gt; To: <a href="mailto:users@racket-lang.org">users@racket-lang.org</a><br>
&gt;&gt;&gt; Subject: Re: [racket] OFFTOPIC - Quote on Programming<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I forget where that quotation came from originally, but it<br>
&gt;&gt;&gt; antedated the<br>
&gt;&gt;&gt; days where internal documentation was the norm.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Tue, Mar 19, 2013 at 06:20:57AM +0100, Jos Koot wrote:<br>
&gt;&gt;&gt;&gt; Well, that may depend on how you define &quot;clever code&quot;.<br>
&gt;&gt;&gt; Surely it is clever<br>
&gt;&gt;&gt;&gt; to write well documented code that can easily be<br>
&gt;&gt;&gt; understood, debugged,<br>
&gt;&gt;&gt;&gt; maintained and reused by yourself and by others.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The &quot;clever&quot; refers to cleverness merely in producing a<br>
&gt;&gt;&gt; foemalism that<br>
&gt;&gt;&gt; appears to work.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Understanding may require<br>
&gt;&gt;&gt;&gt; knowledge of the discipline the code is written for, of<br>
&gt;&gt;&gt; course. In my<br>
&gt;&gt;&gt;&gt; opinion it helps a lot first finishing the documentation<br>
&gt;&gt;&gt; and the design<br>
&gt;&gt;&gt;&gt; (both user and &#39;inside&#39; docs) before starting coding.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; You&#39;re talking about metacleverness -- the know-yourself kind of<br>
&gt;&gt;&gt; cleverness that acknowledges your own limitations and take them into<br>
&gt;&gt;&gt; account.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; With good and well<br>
&gt;&gt;&gt;&gt; described design it is even possible to leave the coding to<br>
&gt;&gt;&gt; another person,<br>
&gt;&gt;&gt;&gt; just like an architect designs a building and constructors build it.<br>
&gt;&gt;&gt;&gt; My 2c, Jos<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I&#39;ve never found it to be feasible to leave the coding to another<br>
&gt;&gt;&gt; person, except in cases where the remaining coding is so<br>
&gt;&gt;&gt; trivial that a<br>
&gt;&gt;&gt; machine could do it.<br>
&gt;&gt;<br>
&gt;&gt; I have experienced some good things leaving the coding to others. I think<br>
&gt;&gt; that in some cases a good and detailed design makes coding almost trivial.<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [ In which case it makes sense to use a compiler.  :-) ]<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -- hendrik<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; From: <a href="mailto:users-bounces@racket-lang.org">users-bounces@racket-lang.org</a><br>
&gt;&gt;&gt; [mailto:<a href="mailto:users-bounces@racket-lang.org">users-bounces@racket-lang.org</a>]<br>
&gt;&gt;&gt;&gt; On Behalf Of Harry Spier<br>
&gt;&gt;&gt;&gt; Sent: martes, 19 de marzo de 2013 2:56<br>
&gt;&gt;&gt;&gt; To: users<br>
&gt;&gt;&gt;&gt; Subject: [racket] OFFTOPIC - Quote on Programming<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I found this quote on a blog and couldn&#39;t help sharing it :-)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &quot;Debugging is twice as hard as writing the code in the first place.<br>
&gt;&gt;&gt;&gt; Therefore if you write the code as cleverly as possible, you are by<br>
&gt;&gt;&gt;&gt; definition not smart enough to debug it.&quot; Brian Kernigan<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; ____________________<br>
&gt;&gt;&gt;&gt;  Racket Users list:<br>
&gt;&gt;&gt;&gt;  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ____________________<br>
&gt;&gt;&gt;  Racket Users list:<br>
&gt;&gt;&gt;  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
&gt;&gt;<br>
&gt;&gt; ____________________<br>
&gt;&gt;  Racket Users list:<br>
&gt;&gt;  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
&gt; ____________________<br>
&gt;  Racket Users list:<br>
&gt;  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br>
<br>
____________________<br>
  Racket Users list:<br>
  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</blockquote></div><br></div>