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

Re: [scrumdevelopment] Help with The Inevitable Question

Expand Messages
  • Simon Kirk
    Hi David thanks for writing back. Answers inline: ... Funny you should mention the hardware, that s definitely something of a driver. However yes, I m pretty
    Message 1 of 38 , Aug 29, 2008
      Hi David thanks for writing back. Answers inline:

      On 29 Aug 2008, at 21:27, David H. wrote:

      >> We do bespoke software development for external clients on a project
      >> basis: obviously we've developed a long and intimate relationship
      >> with
      >> this client. This system runs the vast majority of their business.
      >> The client has now identified this system as a risk, they say because
      >> of the ageing technology, and its relatively poor design which has
      >> lead to a few nasty problems lately that have been hard to fix. Their
      >> new technical director has asked us (which has fallen to me) to
      >> prepare a presentation about how to bring this system "kicking and
      >> screaming into the century of the fruitbat" (my term not his, with a
      >> nod to TPratchett).
      > Does the business, with that I mean the people making the money, want
      > a new system? Or is this a case of the Technical director going awry
      > because he fears his ass is on the line if this is not running on a
      > 100 Core, Erlang driven machine?

      Funny you should mention the hardware, that's definitely something of
      a driver. However yes, I'm pretty sure the business do wish to
      modernise. I've met with various levels of the organisation and we
      know it's not just the TD.

      >> We think they've given us this opportunity because they realise we
      >> know their system and therefore their business practically better
      >> than
      >> they know themselves. They wanted us to evaluate the three choices of
      >> letting the system simply carry on until it died, rewriting it from
      >> scratch, or gradually modernising it.
      > Can you try to modernise while developing new stories? Incrementally?

      I absolutely think we can - I didn't want to go into too much detail
      as my email had already got long, but that is my preferred strategy
      (indeed it's the only strategy that I think would "work")

      >> I don't think a from-scratch rewrite would ever work, I favour the
      >> gradual modernisation. If anybody disagrees, please let me know,
      >> because I'd love to talk about it. But, my presentation is about
      >> there, and I've tried very hard to aim it squarely at the business,
      >> talking about ROI, Risk et al.
      > Well there are loads of good ideas and books out there to deal with
      > legacy code :)

      Indeed - we have the Feathers classic, not to mention Uncle Bob's new
      Clean Code book (which I REALLY recommend). The problem is that I
      can't get too code-detailed with the people for this presentation -
      hence why I've gone very business oriented.

      >> Here is my problem (at least the biggest I anticipate): I think that
      >> even if I manage to convince the client of my way of thinking, the
      >> inevitable question then is "OK, so we agree in theory with your
      >> approach, but the system does need a complete rewrite, so what do we
      >> tell the business about budget? We need to get the budget for all the
      >> work, not just some of it".
      > Does it need a complete rewrite? Does _everything_ simply not work?

      Well, it's hard to modernise the system away from VB6 without
      rewriting :)

      But seriously, some parts could really do with changing, yes. But I by
      no means want the "full on" rewrite. As I said above a gradual
      transition is very much the way forward for us, but the business
      people on their side are going to find that a bitter pill to swallow,
      because as said, they want the whole budget, and nothing but the
      budget ;)

      As a technical aside: this system is the very definition of legacy.
      Until my arrival two years ago, there were no automated tests *at
      all*. Since then I have been trying very hard to get tests in there to
      allow us to refactor with safety, and it's been successful as far as
      it's gone, meaning there are tests around stuff we've changed.

      But, this system has a custom-built VB6 persistency layer built into
      the core of every object: a true unit testing nightmare. So all the
      tests are functional. I think that tells you plenty about why sections
      need changing, in particular towards decoupling: at the moment
      everything is still pretty much a big ball of mud.

    • ceezone
      I agree with whatever you are saying Roy. But these are my observations/experience: 1. Most project managers have, heard of/Used (even if poorly)/considered,
      Message 38 of 38 , Sep 25, 2008
        I agree with whatever you are saying Roy.

        But these are my observations/experience:

        1. Most project managers have, heard of/Used (even if
        poorly)/considered, Function points.

        2. Very few have heard of Use case points.

        3. Almost no one has heard of COCOMO (shame)

        Someone somewhere (blast my memory) has made a very valid point about
        estimations showing a graph which corresponds to one of a the
        economics curve of law of diminishing marginal returns. This is a
        curve of estimation accuracy.vs.effort expended on arriving at the
        estimate. I think lot of organisation forget that!


        --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...>
        > Wonderful!! Apply mathematics and metrics (COCOMO-II - because
        COCOMO-I was found to be deficient and in need of improvement) and
        Function Points, which look great because of the emphasis on metrics
        and measurement and historical 'facts' ... and THEN ADD SOME
        CONTINGENCY ... which clearly indicates that all those metrics and
        measurements and estimating methods don't work very well ... and ...
        ummm ... what is the measure of 'some' in that 'add some contingency'
        bit?I'm sorry to be appearing to ridicule your suggestion, H. but ...
        well, yes, I am ridiculing your suggestion.
        > My advice to Simon would be to first ask the clients to give a full
        and accurate statement of requirements, and a clear contractual
        undertaking that if it is not stated in that specification, then it
        will not be included in the developed system. The client must provide
        that spec in sufficient detail for you to give an estimate of
        sufficient correctness. They surely are not so unreasonable as to ask
        you for accuracy without them also being accurate and correct and
        > If the existing system can be seen as being exactly what they want,
        and so can be pointed to as the spec., then one may ask the question
        Why on earth are they asking for a rewrite?
        > An interesting fact that arose from my research (albeit a
        reasonably restricted research activity to admit to the facts) into
        software estimating. I researched amongst consulting firms and
        contracting firms that represented well over 50% of the local
        industry in my home city; not one of them used COCOMO of any vintage,
        and not one of them used Function Point Analysis, and many of the
        project managers had never heard of COCOMO or Function Points. Do I
        come from the real boondocks of software projects?
        > Regards,
        > Roy Morien
        > To: scrumdevelopment@...: hmeftah@...: Mon, 1 Sep 2008 09:16:55
        +0000Subject: [scrumdevelopment] Re: Help with The Inevitable Question
        > Hi Simon,Many of my clients ask the same question. How estimate
        revamping anexisting application.You have to start from concrete
        facts: 1) your current application even it's not perfect works every
        day. 2) Your application is based on VB code, therefore this code
        isthe latest version of your application documentation.3) You know
        all functions and methods, screens, data structure andso on.4) you
        may know how long a new feature took to be designeddeveloped and
        tested.For my point of view your project is quite large so you may
        need aproof of concept phase to estimate time and budget. I think
        your gradual revamping is a good approach, upon these 4 basicfacts
        above you can estimate and budget for example section X whichwill use
        that method, that class, this sort of data structure, thisdatabase
        access. Use "playing cards" Scrum phase to estimate our teamvelocity
        at day one.Then refine your figures by using COCOMOII analysis,
        function pointsestimate and add some contingency.Good luckH. Meftah
        > _________________________________________________________________
        > Are you a friend magnet? Play now to win prizes for you and your
        > http://clk.atdmt.com/GBL/go/106906016/direct/01/?
      Your message has been successfully submitted and would be delivered to recipients shortly.