[bind10-dev] Quality of in-memory code

[JINMEI Tatuya / 神明達哉]

Catching up some old messages that have been buried in my spam folder
by accident...

At Wed, 28 Nov 2012 11:11:44 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> As I had some trouble explaining my concern during the call yesterday, I'm
> sending it in an email.
> 
> During the work on 2378, I decided to use the in-memory data source for some
> testing. And I encountered several glitches:
[...]
> However, my concern is _not_ about these concrete issues. I'll just create
> tickets for them and they should be easy to fix. My concern is, this is quite
> high amount of problems for the little part of the implementation I used.
> Therefore I fear the quality of the in-memory implementation is lower than our
> usual standard. I see several possibilities:
>  • My memory is not good enough and there's always such high amount of problems.
>  • We were in hurry with the implementation and the quality naturally reflected
>    that.
>  • There was some other problem with just this bit of code.
>  • We are getting worse in the ability to design and write code. In other words,
>    from now on, every new part of bind10 will have this amount of problems. This
>    could be because people have little idea about the design before it is split
>    single-handed into tasks and then are not consistent in how they think about
>    the general idea (what happened to our plan about design calls and
>    discussions?) or because there wasn't a f2f meeting for a while.
>  • Something else?

This seems to be quite a high level discussion, so opinions may
naturally vary, but I personally don't think the quality of the new
in-memory data source implementation is that low.  They are generally
and IMO reasonably modularized, well tested and documented, and each
method is reasonably concise and understandable (but it's also quite
possible that I'm biased because I was deeply involved in the design
and implementation, and I proposed many specific parts of it).

Some points were left unimplemented because we didn't need them right
now.  It's suboptimal, of course, but we need to prioritize things.

There are probably some inconsistency in interfaces.  I think it's a
result of our design/develop style: multiple developers work on
subsets of one big feature with initial roughly-fixed design,
discussing/changing some details during the implementation phase.
The resulting inconsistency is not really good, but I think this is a
tradeoff issue.  If, for example, a single assigned person exclusively
works on that part of the feature, the result will be more likely to
be consistent from the beginning.  But it will be more difficult to
review, integrate, and maintain.  Having multiple people involved will
be more likely to cause inconsistency, but more people are familiar
with the system in more details at the cost of that (so, for a longer
term, it will help improve maintainability).

I remember we discussed these pros and cons, probably in a different
context, before, and in my memory our general consensus is to keep the
multi-developer style with understanding and accepting its cost.

If the consensus hasn't changed, the question is to how to minimize
the cost such as resulting inconsistency.  There can be several
possibilities:
- fix more details in the design phase to minimize open points before
  the implementation phase.  I personally think this is not really
  good, because often we cannot be sure about some details until we
  actually implement, test and use it
- have more communication to clarify the points during the
  implementation phase.  I think we already do this, but it's probably
  not sufficient.
- have some post-complete fix phase to review the entire design and
  interface and fix obvious glitches.  That's probably one thing we
  are not doing well right now - in many cases we run out of time just
  to complete a feature, followed by another new feature.  We
  introduced a concept of "hardening sprint", but I'm afraid it's not
  working as we hoped (actually we've even skipped it for quite some
  time).  I think this is something we can improve right now.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.