public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Offel <michael.offel@web.de>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
Date: Tue, 12 Jul 2011 23:50:48 +0100	[thread overview]
Message-ID: <296725421.20110712235048@web.de> (raw)
In-Reply-To: <CANEZrP1gEx0_A+BQfJLQ1jppc=-qS1DwruR_wXsP-ctqZGGnjA@mail.gmail.com>

Monday, July 11, 2011, 10:33:04 AM, Mike Hearn wrote:

>> My overall suggestion is to begin a complete rewrite, inspired by the old
>> code rather than moving a lot of "known to be somehow functional" around.

> This essay is old but still relevant, I think:

>   http://www.joelonsoftware.com/articles/fog0000000069.html

It is indeed a very good one but I disagree in two points. First

> As  a  corollary  of  this  axiom, you can ask almost any programmer
> today  about  the code they are working on. "It's a big hairy mess,"
> they will tell you. "I'd like nothing better than to throw it out and start over."
If  someone  asks  me  this  question  about the project I'm currently
working  on  I  would never answer like that. This is important in the
threads  context  because  it  gives  me the confidence to say you can
build  very  large  C++ projects with lots of programers attached over
multiple years and still have a very clean and nice code base. And the
article does also accidently points to one of the roots of messy code.


> Back  to  that  two  page  function. Yes, I know, it's just a simple
> function  to  display  a  window,  but it has grown little hairs and
> stuff on it and nobody knows why. Well, I'll tell you why: those are
> bug  fixes. One of them fixes that bug that Nancy had when she tried
> to  install  the  thing  on  a  computer  that  didn't have Internet
> Explorer.  Another  one  fixes  that  bug  that occurs in low memory
> conditions.  Another  one fixes that bug that occurred when the file
> is  on  a floppy disk and the user yanks out the disk in the middle.
> That  LoadLibrary  call  is  ugly  but it makes the code work on old
> versions of Windows 95.
Well,   if   you  can not identify the meaning of some hairs, they are
either  attached  to  the  wrong  place, in an unclear way or are just
missing  a  line  of  comment.  There  are  studies about what size of
function  and  up  to  what  number  of  variables per function can be
covered  by  the average code reading programer. And these numbers are
low.


Second,  I  agree  with the point that you can not give up your market
leadership by beginning from scratch and you will if you do so. Unless
you  do  it like microsoft did in his example by simultaneously extend
the  old code base. And microsoft does this all the time, just look at
Windows 9x compared to Windows NT and the dead object oriented Windows
kernel. (They did buy lots of that but that is not the point here)
The  mistake  is  to  compare  a  small  project  like  Bitcoin to any
application  like  Word  or  Netscape. The author did explicitly write
that  he  does  not  mean  that  partial  rewrite  is a bad thing. And
rewriting  the  Bitcoin  client with three or four guys is like a tiny
rewrite in a real world application like Word.
> It's important to remember that when you start from scratch there is
> absolutely  no  reason  to believe that you are going to do a better
> job than you did the first time.
In  case of Bitcoin there is reason to believe that a rewrite would be
better.  The first version was hacked together by far less programmers
and  by at least one who did not care about readability, what tells me
that  he  possibly did never work on a real project before. And we now
have  a  known  to  work  protocol,  what  did  for sure slow down the
development a lot and caused rewrites.



Michael




  parent reply	other threads:[~2011-07-12 22:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-10 22:37 [Bitcoin-development] overall bitcoin client code quality Michael Offel
2011-07-10 23:07 ` Douglas Huff
2011-07-10 23:31 ` Jeff Garzik
2011-07-10 23:36 ` Matt Corallo
2011-07-11  2:01 ` Luke-Jr
2011-07-12  4:13   ` Alan Grimes
2011-07-12  5:19     ` Jeff Garzik
2011-07-11  9:33 ` Mike Hearn
2011-07-12  3:31   ` Gavin Andresen
2011-07-12  7:21   ` John Smith
2011-07-12 22:50   ` Michael Offel [this message]
2011-07-12 21:47 Michael Offel
2011-07-12 23:40 ` Gregory Maxwell
2011-07-13  0:17 ` Matt Corallo
2011-07-13 11:50   ` Mike Hearn
2011-07-13 13:04     ` Andy Parkins
2011-07-13 18:37       ` Luke-Jr
2011-07-13 21:41         ` Andy Parkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=296725421.20110712235048@web.de \
    --to=michael.offel@web.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox