Loading ...
Sorry, an error occurred while loading the content.

Re: [agileDatabases] Re: Agile do Glossaries?

Expand Messages
  • Curt Sampson
    ... It depends entirely on how you do the transition. And if you even do it at all. Putting on my software project manager hat for a moment, my first question
    Message 1 of 37 , Sep 16, 2009
      On 2009-09-15 15:25 -0000 (Tue), deddy205ar wrote:

      > And then when Team 1 has moved on & Team 2 arrives, what does it
      > cost for them to re-learn the language?

      It depends entirely on how you do the transition. And if you even do it
      at all.

      Putting on my software project manager hat for a moment, my first
      question would be, now that I've got a good team that knows the project,
      why do you want to take those people away and replace them with those
      that don't know the project? It's obvious that that's going to cost you
      something, and potentially quite a lot if you do it in one fell swoop.

      But if you absolutely insist, I can give you a couple of choices.

      1. For a month before the transition, I put everybody on writing up
      the sort of documentation that the new team would need if the old
      team weren't around all of a sudden. Progress stops for that month,
      and after the transition, the new team, works very poorly until they
      re-learn all of the stuff that's hard to write down.

      2. We take away half the team a month before your proposed cutover
      date, and bring in a new half-team at the same time. The old and new
      developers all pair for the next two months, slowing down a bit due
      to training issues, but still able to react with correct bug fixes
      and good new features during that time. Then we pull out the rest of
      the old developers and put in the other half-team of new developers,
      leaving in place a half team of moderately experienced developers to
      help train up the new guys.

      > If this is a representative audience, it would appear that glossaries (e.g.
      > just a small dictionary) are NOT part of the typical drill.

      They might well be if you went for option 1. Being able to look up a
      glossary definition is certainly not anywhere near as useful as being
      able to talk to someone who really understands the deeper meanings of
      the term, but it's better than nothing, I suppose.

      Curt Sampson <cjs@...> +81 90 7737 2974
      Functional programming in all senses of the word:
    • Curt Sampson
      ... I have used both extensively, and I chose relational based on both theory and experience. ... If they didn t intend the order to have meaning, you ve
      Message 37 of 37 , Sep 24, 2009
        On 2009-09-21 08:31 -0500 (Mon), Dawn Wolthuis wrote:

        > I have both worked with and read about the RM, while I do not know how
        > much you have done with NF2 and all-data-is-variable-length DBMS's
        > (e.g. PICK). If you could let me know if you have the feel of both and
        > whether you have chosen relational based on experience or theory or
        > both, that will help me with my responses.

        I have used both extensively, and I chose relational based on both
        theory and experience.

        > We collected the order of these email addresses from the user, whether they
        > intended that order to have meaning or not.

        If they didn't intend the order to have meaning, you've started making
        up new information. I find it very difficult to think how making up new
        facts, especially when there's no agreement on what those facts mean,
        can ever be a good thing.

        > People work in lists.

        Actually, often people do not work in lists. You forcing them to work in
        lists when that is not actually what they really want to do is, well,
        I'd say "irresponsible."

        It's also likely to lead to programming errors. If I consider myself to
        have a set of e-mail addresses, {A,B,C}, and then your system appears
        to tell me later that {A,B,C} != {B,C,A}, because you're really saying
        [A,B,C] != [B,C,A], you're now producing wrong answers.

        > We put words in a sentence in an order.

        Certainly, but that doesn't mean that the order is important. There are
        many cases where two statements differing in order are intended to have
        the same meaning. For example:

        He went from his office to his home.
        He went to this home from his office.

        > We process information in an order.

        That at a low level certain operations happen before other operations
        is not an indication that we must assign meaning to that. In fact, we
        often go out of our way to avoid doing that, and many languages (such as
        SQL and Haskell) specifically indicate that ordering is not important in
        certain constructs.

        > Lists are a very powerful data structure.

        I fail to see the relevance here. Trees are more powerful data
        structures, yet I don't see you saying we must use trees everywhere. I
        would posit, too, that relations are a more powerful data structure yet,
        since they can represent much more than lists can do. In fact, in your
        own examples where you take a relational representation and represent
        part of that as a list, you maintain a relational representation for
        other parts of the data. You've now introduced complexity (and thus the
        potential for error) into your model for no discernible benefit, when it
        comes to modelling.

        I would normally chalk this down to confusion between the model and an
        implementation of the model, but you seem to be pretty clear that you
        consider this change to be something to be done because you want to
        change the model, rather than as an implementation strategy.

        > The RM causes lists that are not explicitly stated in the requirements
        > as needing to be lists to become sets.

        Right, as they should: if it's a set in the requirements, it should be
        a set in your model. If it's a list in the requirements, it should be a
        list in your model. Using the RM to model this makes it quite clear just
        what you're trying to specify. What is the problem with such clarity and

        > ...or otherwise because it is not important enough that the development
        > team wants to deal with the RM overhead in implementing this list...

        You are quite confused, here. If you are using appropriate tools, the
        overhead of modelling something as a list is larger than the overhead
        of modelling it as a set, because you now have to have extra operations
        to deal with the additional ordering data: you need to provide the user
        ways to specify where an insert occurs in a list, operations to re-order
        the list, and so on. You also need to make sure that in all of your
        internal operations you are correctly reasoning about what you're doing,
        which is significantly harder for lists than for sets.

        > In the case of the email addresses, if the user knows they have the power to
        > teach the computer their order, they might use that and they might not.

        This just gets worse and worse. If the user has assigned a meaning
        to the order, you need to know this, know what the meaning is, and
        deal with it with every use of the data. I posit that if you do not
        understand what your users mean, you're going to produce a broken piece
        of software, because you simply can't operate correctly on data where
        you don't understand the meaning.

        > Of course this could be accomplished it the RM, but my point is that
        > it often simply isn't.

        I accept that, regardless of the model developers are using, they may
        use it poorly and do a poor job of modelling things. I categorically
        deny that this in any way makes it a good idea to use models that
        encourage this sort of error.

        On 2009-09-22 09:47 +1000 (Tue), Clifford Heath wrote:

        > By advising others to implement multi-valued fields in non-MV stores,
        > you *will* cause bugs...

        Indeed; this is my whole point.

        > As a result, I can only say that you've voted for convenience over
        > quality.

        I don't think she's even voted for convenience. Poor specifications are,
        in my experience, the most common source of errors in software, and good
        developers should work hard to prevent this from happening. Use of a
        formal system to help expose incomplete, invalid and misunderstood parts
        of a specification is one of the most powerful tools we have. To run
        away from understanding of what one is doing may be "convenient" in the
        short term, but in the long term it leads to long, painful and ongoing
        struggles to fix "bugs" in the code.

        > Your Pick system actually *has* the ordinal element, but conveniently
        > hides it behind a array paradigm.

        Indeed. And this makes things more difficult, because as soon as you
        introduce this sort of thing, yet attempt to do operations on the
        elements within the list in relation to anything else in the database,
        you now have to deal with a more complex system.

        > Curt's argument is that the relational model is quite capable of
        > representing your lists, and there's no reason why a relational tool
        > shouldn't provide the same support that your MV system gives you. And
        > if not a tool, then build a relational list manager yourself, as I'm
        > sure Curt has.


        > In fact, better relational tools *are* available, but the DBMS tools
        > market is so political that they haven't become part of the SQL
        > "standard".

        I think that there's more to it than this: I think that there's a tragic
        lack of imagination amongst developers. These tools are not that hard to
        build yourself, but there are just too many "programmers" out there who
        shy away from writing programs and instead feel that they must restrict
        themselves to gluing together libraries and framework elements. Given a
        bad API, they prefer to use it rather than develop a good one.

        > The support that's required in this case is to create a data type for
        > the "ordinal" field that auto-assigns the next highest integer on an
        > insert. Perhaps optionally, also renumbers to avoid gaps on deletes.

        This is getting away from the main point, but just to show where you
        can go with this sort of thing when you stop restricting yourself to
        just the obvious things that some specific implementations happen to
        allow, that "ordinal" field need not be gap-free, nor even an integer
        (which does bring in the problem of renumbering, when you get down to
        the implementation). Make it a rational instead, and then you can always
        insert a new element between two others with no renumbering.

        Anyway, as far as I can tell here, Dawn is advocating avoiding precise
        specifications because she feels somehow that working from a less
        precise specification is likely to produce a better piece of software. I
        just don't understand how that could be.

        Curt Sampson <cjs@...> +81 90 7737 2974
        Functional programming in all senses of the word:
      Your message has been successfully submitted and would be delivered to recipients shortly.