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

Cowboy Spaghetti coding

Expand Messages
  • mojavescout
    Hello and thank you for letting me join this group. Here is my story and my questions. BACKGROUND: I am the IT Director for a small IT shop of 2 developers and
    Message 1 of 27 , Aug 24, 2010
    • 0 Attachment
      Hello and thank you for letting me join this group. Here is my story and my questions.

      BACKGROUND:

      I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

      I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

      We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

      Goals:

      Move FoxPro tables to SQL Server
      Eliminate Spaghetti Code
      Create a means for multideveopers to code this application

      Challenges:
      Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

      Other developer must be trained on logic and immersed in current code to assist.

      Questions:

      The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

      Can you run effective Scrum teams with 1 or two team members only?


      This is the first, I am sure, of many inquiries and I thank you for you for any assistance.
    • Alan Dayley
      If I may back up a bit, I have a question. If the current code is so bad, why are you keeping it? Couldn t you just use the current running application as a
      Message 2 of 27 , Aug 24, 2010
      • 0 Attachment
        If I may back up a bit, I have a question.

        If the current code is so bad, why are you keeping it?  Couldn't you just use the current running application as a "functioning spec" and write new code to perform the same functions?  You would then have clean code from the start and eliminate the need for anyone to learn the current spaghetti code.

        Yes, your sprint should end with shippable code that an end user can use.  It may not be business functional yet, for example, it may only allow data input but have no reporting yet, or something like that.  But the sprint should deliver complete code that works.

        Alan

        On Tue, Aug 24, 2010 at 9:13 AM, mojavescout <john_thebabe@...> wrote:
         

        Hello and thank you for letting me join this group. Here is my story and my questions.

        BACKGROUND:

        I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

        I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

        We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

        Goals:

        Move FoxPro tables to SQL Server
        Eliminate Spaghetti Code
        Create a means for multideveopers to code this application

        Challenges:
        Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

        Other developer must be trained on logic and immersed in current code to assist.

        Questions:

        The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

        Can you run effective Scrum teams with 1 or two team members only?

        This is the first, I am sure, of many inquiries and I thank you for you for any assistance.


      • PeteCRuth@aol.com
        What s your primary objective? Is it to implement Scrum or to successfully migrate your data and programs to SQL Server? There are many in the Scrum
        Message 3 of 27 , Aug 24, 2010
        • 0 Attachment
          What's your primary objective? Is it to implement Scrum or to successfully migrate your data and programs to SQL Server? There are many in the Scrum community who believe that Scrum is best applied to the development of new systems, rather than in the maintenance of existing systems. I reject that notion (and have often been roundly criticized as a "blasphemer" for voicing it). For me, Scrum is a process whose principles can be applied to virtually any project, and I've used it in the maintenance and conversion of scores of systems for my clients. The key for me is to apply the spirit of the rules, when the letters of the rules seem to get in the way of progress; that is, don't get hung up in the dogma. (I've seen many a sprint, and project, nearly derailed by arguments regarding "approved Scrum protocols". 
           
          You've probably got a strategy in mind, but here are some points that have proven beneficial to me in projects like yours. I start by analyzing the source code to identify what tables get "touched" by what code. There are probably a slew of commercial products to do this, but I use a program I wrote quite some time ago that produces what is essentially a "where used" list of table and column names and the location of the references to them in the source code. This can be especially helpful when "Cowboy Coding" has been employed, as it helps to identify instances of duplicate code. More to the point, it minimizes the time you have to spend digging the information out manually, and it reflects the current status of the code better than any previously-produced documentation. Once you know where all the skeletons are buried, you can determine the best way to proceed. 
           
          From there, you can take whatever path you like to modularize/refactor/optimize the code.       
           
          Again, I've found Scrum (as well as other agile methods), to be useful and effective in projects like yours.
           
          Regards,
           
          Pete ("the Babe") Ruth (from my high school baseball days).
           
           
          In a message dated 8/24/2010 9:14:32 A.M. Pacific Daylight Time, john_thebabe@... writes:
           

          Hello and thank you for letting me join this group. Here is my story and my questions.

          BACKGROUND:

          I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

          I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

          We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

          Goals:

          Move FoxPro tables to SQL Server
          Eliminate Spaghetti Code
          Create a means for multideveopers to code this application

          Challenges:
          Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

          Other developer must be trained on logic and immersed in current code to assist.

          Questions:

          The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

          Can you run effective Scrum teams with 1 or two team members only?

          This is the first, I am sure, of many inquiries and I thank you for you for any assistance.

        • Maurice le Rutte
          First of all I d like to point out that the rules of Scrum are in the end what you make of it. It is not like a law defined by nature or by the government,
          Message 4 of 27 , Aug 24, 2010
          • 0 Attachment
            First of all I'd like to point out that the 'rules of Scrum' are in the end what you make of it. It is not like a law defined by nature or by the government, so you can adjust it any way you see fit. It may have impact on the effectiveness of your software development, positive or negative. The Scrum framework is simple and effective and that I wouldn't change too much too quickly, I wouldn't have too many discussions on 'the requirements of Scrum', as you wrote. Nobody is going to haunt you for doing it differently.

            The team's size does of course have impact on what you do. You should strive for the lowest process still effective. For example I'm not sure whether I would want somebody to have the role of ScrumMaster. I would still do the timeboxing, including the sprint I & II planning sessions, the review and some kind of retrospective, which may be some more of a reflection talk with each other.

            As keeping money flowing in is important I would advise to have the priorities still set by business, so have a product owner. You don't want to end up in the situation that the priorities are primarily set by the developers. Of course, setting priorities require input from the developers, but they don't make the last call.

            I don't know how feasible it is to make a big-bang switch from your old database engine to a new database engine, nor if it is possible to use the two engines at the same time. I do think that if you start refactoring you'll probably find out that you will want to change your database design, so you might give that some thought of how you are going to handle that.

            You indicate that the structure of the program has become too difficult to understand, so there is a need to rewrite what's there. You can't just start anew as you wouldn't have a sellable product until you had all features you already had. Note that what you may regard as defects may have become features for the customers, so be prepared to receive feedback that they liked the old way better. [*]

            I wouldn't just start around changing the code, my strategy has been to refactor a part of the code when there is a defect to be fixed or a new feature needs to be added to a part. We then imagined how we would have liked to be if there was no code already and use that as basis for the redesign.

            At the end of a sprint you should still have a working product, including the refactorings you made. If you don't do this the risks of regression grows all the time. You can use the old developer to find out if it still does what it did. It is likely that he'll still know the nitty gritty details.

            Maurice.
            [*] Yes, that actually happens.

            Op 24-8-2010 18:13, mojavescout schreef:
             

            Hello and thank you for letting me join this group. Here is my story and my questions.

            BACKGROUND:

            I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

            I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

            We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

            Goals:

            Move FoxPro tables to SQL Server
            Eliminate Spaghetti Code
            Create a means for multideveopers to code this application

            Challenges:
            Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

            Other developer must be trained on logic and immersed in current code to assist.

            Questions:

            The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

            Can you run effective Scrum teams with 1 or two team members only?

            This is the first, I am sure, of many inquiries and I thank you for you for any assistance.



            -- 
            http://www.scrummaster.nl / http://twitter.com/scrumnl
          • George Dinwiddie
            Hi, Mojave Scout, It is a daunting task, indeed. But gradual refactoring of legacy code to a better foundation for the future is, in my experience, possible.
            Message 5 of 27 , Aug 24, 2010
            • 0 Attachment
              Hi, Mojave Scout,

              It is a daunting task, indeed. But gradual refactoring of legacy code
              to a better foundation for the future is, in my experience, possible.
              Your migration task is orthogonal to Scrum.

              Take a look at the Strangler Pattern. Martin Fowler has a good writeup
              on the web.

              On 8/25/10 12:13 AM, mojavescout wrote:
              > Goals:
              >
              > Move FoxPro tables to SQL Server

              What language are you using for the code? Can it access both FoxPro and
              SQL Server? Or are you changing implementation languages, too?

              > Eliminate Spaghetti Code

              Did you forget the step of solving the Arab/Israeli conflict in the
              Middle East?

              > Create a means for multideveopers to code this application
              >
              > Challenges:
              > Senior developer claims no usable code can be created in a single
              > Sprint. Says it will take months to swim through this code.

              I suspect he's under-estimating.

              > Other developer must be trained on logic and immersed in current code
              > to assist.

              Trained? How about work with it, and have the original coder highly
              available to answer questions and demonstrate things?
              >
              > Questions:
              >
              > The rules of Scrum require usable code at the end of a Sprint
              > correct? Is it ever possible that this would not be the case? Maybe I
              > do not know th definition of "usable code".

              The system should still work, and any new features that have been added
              should work.

              > Can you run effective Scrum teams with 1 or two team members only?

              Yes, it's just the work gets done slower. And you probably need less
              formality for your meetings.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Roy Morien
              I do like what you wrote, Maurice. And I too have found that problem of the users objecting to new design because it wasn t like the old design. Whether or not
              Message 6 of 27 , Aug 24, 2010
              • 0 Attachment
                I do like what you wrote, Maurice. And I too have found that problem of the users objecting to new design because it wasn't like the old design. Whether or not that a defect that was seen as a feature or not I am not sure, but certainly users are often very nostalgic about their old system interface. "But that's not the way the old system did it" is a very familiar cry to me.
                 
                I would add some questions to your email, to find out more about this problem of 'spaghetti code'. How much of that 'spaghetti code' is to do with table handling, as in

                ·    ADD new records,

                ·    DELETE existing records,

                ·    MODIFY existing records,

                ·    SEARCH for specific records,

                ·    MOVE, COPY records

                ·    LIST records,

                ·    SEQUENCE records

                ·    QUERY, EXTRACT sets of information from the table

                ·    REPORT on data in the table.

                ·    Create Database Stored Procedures and Triggers

                 
                I would suggest that with 100+ tables, each of which requires at least those basic functions of Add, Delete, Change, then it would be a good idea to write some standard 'table handling' or 'table maintenance' programs and then set up almost a production line of copying and modifying those standard programs for every table. Some of those 'copies' might take 2 hours max. to change for the new table, some may take as little as 15 minutes. Yes, 100+ tables is not a trivial task, but it can certainly be made much simpler and faster by using this strategy of standard programs and reuse.
                 
                The problem of 'spaghetti code' becomes much more of a problem when you are looking at transaction processing type programs. But again, a large part of transaction processing programs, in an on-line, interactive database processing system is really just table updating ... not all, of course, but a lot.
                 
                And of course, now you are using SQLServer, you can put a lot of tale processing code into SQL scripts, which can simplify things even further.
                 
                Last question ... Is your current software product so broken that iot can't continue to be used 'as is' until you have created a new SQLServer-based version of the system? I had a similar situation when I had to rewrite a DOS/Clipper system into Windows/Delphi. But I must admit, I had it much easier because I had written the Clipper code using the same development tactics that I outlined above ... standard programs copied for each table.
                 
                if 'mojavescout' wants some more explanation about what I am talking about, he (she) can contact me offline. I would be happy to share my experience and approach with him.
                 
                Regards,
                Roy Morien
                 

                To: scrumdevelopment@yahoogroups.com
                From: maurice.lerutte@...
                Date: Tue, 24 Aug 2010 22:11:40 +0200
                Subject: Re: [scrumdevelopment] Cowboy Spaghetti coding

                 
                First of all I'd like to point out that the 'rules of Scrum' are in the end what you make of it. It is not like a law defined by nature or by the government, so you can adjust it any way you see fit. It may have impact on the effectiveness of your software development, positive or negative. The Scrum framework is simple and effective and that I wouldn't change too much too quickly, I wouldn't have too many discussions on 'the requirements of Scrum', as you wrote. Nobody is going to haunt you for doing it differently.

                The team's size does of course have impact on what you do. You should strive for the lowest process still effective. For example I'm not sure whether I would want somebody to have the role of ScrumMaster. I would still do the timeboxing, including the sprint I & II planning sessions, the review and some kind of retrospective, which may be some more of a reflection talk with each other.

                As keeping money flowing in is important I would advise to have the priorities still set by business, so have a product owner. You don't want to end up in the situation that the priorities are primarily set by the developers. Of course, setting priorities require input from the developers, but they don't make the last call.

                I don't know how feasible it is to make a big-bang switch from your old database engine to a new database engine, nor if it is possible to use the two engines at the same time. I do think that if you start refactoring you'll probably find out that you will want to change your database design, so you might give that some thought of how you are going to handle that.

                You indicate that the structure of the program has become too difficult to understand, so there is a need to rewrite what's there. You can't just start anew as you wouldn't have a sellable product until you had all features you already had. Note that what you may regard as defects may have become features for the customers, so be prepared to receive feedback that they liked the old way better. [*]

                I wouldn't just start around changing the code, my strategy has been to refactor a part of the code when there is a defect to be fixed or a new feature needs to be added to a part. We then imagined how we would have liked to be if there was no code already and use that as basis for the redesign.

                At the end of a sprint you should still have a working product, including the refactorings you made. If you don't do this the risks of regression grows all the time. You can use the old developer to find out if it still does what it did. It is likely that he'll still know the nitty gritty details.

                Maurice.
                [*] Yes, that actually happens.

                Op 24-8-2010 18:13, mojavescout schreef:
                 

                Hello and thank you for letting me join this group. Here is my story and my questions.

                BACKGROUND:

                I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

                I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

                We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

                Goals:

                Move FoxPro tables to SQL Server
                Eliminate Spaghetti Code
                Create a means for multideveopers to code this application

                Challenges:
                Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

                Other developer must be trained on logic and immersed in current code to assist.

                Questions:

                The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

                Can you run effective Scrum teams with 1 or two team members only?

                This is the first, I am sure, of many inquiries and I thank you for you for any assistance.




                -- 
                http://www.scrummaster.nl / http://twitter.com/scrumnl

              • Wouter Lagerweij
                ... For me, the definition of usable code is code that can be released. What that means in the context of this application depends on your approach: Are you
                Message 7 of 27 , Aug 25, 2010
                • 0 Attachment
                  On Tue, Aug 24, 2010 at 6:13 PM, mojavescout <john_thebabe@...> wrote:
                   

                  Hello and thank you for letting me join this group. Here is my story and my questions.

                  BACKGROUND:

                  I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

                  I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

                  We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

                  Goals:

                  Move FoxPro tables to SQL Server
                  Eliminate Spaghetti Code
                  Create a means for multideveopers to code this application

                  Challenges:
                  Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

                  Other developer must be trained on logic and immersed in current code to assist.

                  Questions:

                  The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

                  Can you run effective Scrum teams with 1 or two team members only?

                  This is the first, I am sure, of many inquiries and I thank you for you for any assistance.


                  For me, the definition of usable code is code that can be released. What that means in the context of this application depends on your approach: Are you 'refactoring' (on a fairly large scale), or re-writing?

                  If refactoring, then 'usable code' means that at the end of every sprint, you have  a working system, which can be released should you wish to do so. In general, this is a *very* good idea to do when doing these kind of changes, since it forces you to not take steps that are too big while refactoring. And it fits in the agile way of working, forcing you to fail early.

                  A re-write would be a little different, in that you would have 'releaseable code', but not a releaseable feature set at the end of each sprint. This could work if your customers can continue using the old version while you write a new one. Of course, any changes that have to be made while you write the new one will be added to your 'rework' scope, which can get to be quite painful. I've been in that situation, and would only recommend going this way if the software is very small, and a re-write very quick. But if that were the case, you wouldn't have this issue, probably... 

                  In either case, make sure you spend a *lot* of time on testing. I don't know the technology involved, but making sure that you know you didn't break anything in your rewrite/refactoring is Rule Number One. 

                  The second Rule Number One is that you get  involvement from your product owner/client, and discuss per piece of work whether the current functionality *should* remain as-is. 
                  I've seen situation where great pains were taken to ensure complete feature parity and pixel-perfect data-migration, taking a huge amount of time, where the customer in the end said: 'Oh that! We don't really use that...'. Or, worse, 'Oh yeah, those records are in there, but they'll never be looked at again.'  In the cases where those remarks came *before*  we started the work, this was nice. In the cases where it came *during*, it was still a bit of a relieve. In the cases where it came while looking back at a failed project, it was a bit painful...

                  Wouter



                   
                • Tim Bryan
                  I am new to this group as well and excited about learning more about agile methodologies; in particular scrum. I am wondering what tools everyone is using to
                  Message 8 of 27 , Aug 25, 2010
                  • 0 Attachment

                    I am new to this group as well and excited about learning more about agile methodologies; in particular scrum.  I am wondering what tools everyone is using to manage their scrum projects.  I found Axosoft OnTime on the web and wondering if anyone has any comments about this product or others.

                    Thanks

                     

                    Best Regards;

                     

                    Tim Bryan

                    Vice President

                    Senior Developer

                    BT Systems

                    Frankston, Texas

                    Web: http://www.btsapps.com

                    The pursuit of happiness is the chase of a lifetime!

                     

                  • Michael Sync
                    I m using AgileZen in one of my project. And also, I m using TFS 2010 with official Agile template (and other scrum templates ).. I like AgileZen more.. Thanks
                    Message 9 of 27 , Aug 25, 2010
                    • 0 Attachment
                      I'm using AgileZen in one of my project. And also, I'm using TFS 2010 with official Agile template (and other scrum templates ).. I like AgileZen more.. 

                      Thanks and Best Regards,
                      Michael Sync

                      Don't go the way life takes you.
                      Take life the way you go

                      http://michaelsync.net


                      On Wed, Aug 25, 2010 at 7:24 PM, Tim Bryan <tbryan@...> wrote:
                       

                      I am new to this group as well and excited about learning more about agile methodologies; in particular scrum.  I am wondering what tools everyone is using to manage their scrum projects.  I found Axosoft OnTime on the web and wondering if anyone has any comments about this product or others.

                      Thanks

                       

                      Best Regards;

                       

                      Tim Bryan

                      Vice President

                      Senior Developer

                      BT Systems

                      Frankston, Texas

                      Web: http://www.btsapps.com

                      The pursuit of happiness is the chase of a lifetime!

                       


                    • Malcolm Anderson
                      This doesn t show up to me so much as a Scrum Question tm but more of a how do we refactor this bad boy? plus as an old foxpro coder, I can t resist this
                      Message 10 of 27 , Aug 25, 2010
                      • 0 Attachment
                        This doesn't show up to me so much as a "Scrum Question tm" but more of a "how do we refactor this bad boy?"

                        plus as an old foxpro coder, I can't resist this question.

                        I once had to maintain a brittle foxpro app for the state of Oregon and found that some of the procedures were 1300 lines long.  The first thing I did was to create a set of test cases, and then start refactoring that code to get it down to manageable sized procedures, while still being able to run my tests. 

                        Two suggestions,
                        1) Buy and Read Michael Feathers, "Working Effectively With Legacy Code"

                        2) Set your first 2 week sprint's goal to move 1 (one) table over to SQL, with all associated logic moved to it's associated new home.  Make it a small table that is infrequently used.  Call it "a proof of concept", or "a quick win"

                        Good Luck

                        Malcolm

                         



                        On Tue, Aug 24, 2010 at 11:13 AM, mojavescout <john_thebabe@...> wrote:
                         

                        Hello and thank you for letting me join this group. Here is my story and my questions.

                        BACKGROUND:

                        I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

                        I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

                        We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

                        Goals:

                        Move FoxPro tables to SQL Server
                        Eliminate Spaghetti Code
                        Create a means for multideveopers to code this application

                        Challenges:
                        Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

                        Other developer must be trained on logic and immersed in current code to assist.

                        Questions:

                        The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

                        Can you run effective Scrum teams with 1 or two team members only?

                        This is the first, I am sure, of many inquiries and I thank you for you for any assistance.


                      • mojavescout
                        Thanks Alan! Yes creating new code is the utltimate goal however the logic and industry knowledge developed over 7 years lies within our Senior developer and
                        Message 11 of 27 , Aug 25, 2010
                        • 0 Attachment
                          Thanks Alan!

                          Yes creating new code is the utltimate goal however the logic and industry knowledge developed over 7 years lies within our Senior developer and his expertise is VFP only. Not only that but we have committed to rolling out a new version with improved features and business development has expectations. So our approach is to have both developers add these features for the new version rollout and also make the code more readable and usable for any developer to help in migrating to a new platform preferably web based. This strategy should allow us to deliver to BD as well as be able to outsource some of the migration. That is the plan so far.



                          --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
                          >
                          > If I may back up a bit, I have a question.
                          >
                          > If the current code is so bad, why are you keeping it? Couldn't you just
                          > use the current running application as a "functioning spec" and write new
                          > code to perform the same functions? You would then have clean code from the
                          > start and eliminate the need for anyone to learn the current spaghetti code.
                          >
                          > Yes, your sprint should end with shippable code that an end user can use.
                          > It may not be business functional yet, for example, it may only allow data
                          > input but have no reporting yet, or something like that. But the sprint
                          > should deliver complete code that works.
                          >
                          > Alan
                          >
                          > On Tue, Aug 24, 2010 at 9:13 AM, mojavescout <john_thebabe@...> wrote:
                          >
                          > >
                          > >
                          > > Hello and thank you for letting me join this group. Here is my story and my
                          > > questions.
                          > >
                          > > BACKGROUND:
                          > >
                          > > I am the IT Director for a small IT shop of 2 developers and one
                          > > Sys/Network Admin. We develop in house applications that drive our company's
                          > > services. The main application, which we would stop all business if it died,
                          > > was written by our senior developer by himself years before I or the others
                          > > on my team started on with the company. He admits it is spaghetti code
                          > > written in Visual FoxPro and right now our only methodology we follow, if
                          > > you can call it one, is cowboy coding.
                          > >
                          > > I have taken on the daunting task of migrating those 100+ tables to SQL
                          > > Server and doing away with the spaghetti code. Our other developer has not
                          > > had the exposure to the logic or code so he will have to be immersed in this
                          > > as well or we will have a lone developer forever on this application. We
                          > > continue to have projects to add features to this application that dwill
                          > > drive business development so you can see that a lone developer will hamper
                          > > speed to market and competitive advantage.
                          > >
                          > > We have not had our Sprint planning meeting yet and are just talking about
                          > > the requirements of Scrum.
                          > >
                          > > Goals:
                          > >
                          > > Move FoxPro tables to SQL Server
                          > > Eliminate Spaghetti Code
                          > > Create a means for multideveopers to code this application
                          > >
                          > > Challenges:
                          > > Senior developer claims no usable code can be created in a single Sprint.
                          > > Says it will take months to swim through this code.
                          > >
                          > > Other developer must be trained on logic and immersed in current code to
                          > > assist.
                          > >
                          > > Questions:
                          > >
                          > > The rules of Scrum require usable code at the end of a Sprint correct? Is
                          > > it ever possible that this would not be the case? Maybe I do not know th
                          > > definition of "usable code".
                          > >
                          > > Can you run effective Scrum teams with 1 or two team members only?
                          > >
                          > > This is the first, I am sure, of many inquiries and I thank you for you for
                          > > any assistance.
                          > >
                          > >
                          > >
                          >
                        • mojavescout
                          Pete, Looks like we both use The Babe from our baseball glory days. Cool Yes you nailed it in your points. We want to migrate due to the limitations of
                          Message 12 of 27 , Aug 25, 2010
                          • 0 Attachment
                            Pete,

                            Looks like we both use "The Babe" from our baseball glory days. Cool

                            Yes you nailed it in your points. We want to migrate due to the limitations of VFP(2GB table limits ugh) to SQL server but also be able to modularize the code so we can start developing for Web Services and possible outsourcing to relieve project congestion.

                            Thanks for your points I am going to include them in our IT meeting.

                            John

                            --- In scrumdevelopment@yahoogroups.com, PeteCRuth@... wrote:
                            >
                            > What's your primary objective? Is it to implement Scrum or to successfully
                            > migrate your data and programs to SQL Server? There are many in the Scrum
                            > community who believe that Scrum is best applied to the development of new
                            > systems, rather than in the maintenance of existing systems. I reject that
                            > notion (and have often been roundly criticized as a "blasphemer" for
                            > voicing it). For me, Scrum is a process whose principles can be applied to
                            > virtually any project, and I've used it in the maintenance and conversion of
                            > scores of systems for my clients. The key for me is to apply the spirit of the
                            > rules, when the letters of the rules seem to get in the way of progress;
                            > that is, don't get hung up in the dogma. (I've seen many a sprint, and
                            > project, nearly derailed by arguments regarding "approved Scrum protocols".
                            >
                            > You've probably got a strategy in mind, but here are some points that have
                            > proven beneficial to me in projects like yours. I start by analyzing the
                            > source code to identify what tables get "touched" by what code. There are
                            > probably a slew of commercial products to do this, but I use a program I wrote
                            > quite some time ago that produces what is essentially a "where used" list
                            > of table and column names and the location of the references to them in the
                            > source code. This can be especially helpful when "Cowboy Coding" has been
                            > employed, as it helps to identify instances of duplicate code. More to the
                            > point, it minimizes the time you have to spend digging the information out
                            > manually, and it reflects the current status of the code better than any
                            > previously-produced documentation. Once you know where all the skeletons are
                            > buried, you can determine the best way to proceed.
                            >
                            > From there, you can take whatever path you like to
                            > modularize/refactor/optimize the code.
                            >
                            > Again, I've found Scrum (as well as other agile methods), to be useful and
                            > effective in projects like yours.
                            >
                            > Regards,
                            >
                            > Pete ("the Babe") Ruth (from my high school baseball days).
                            >
                            >
                            >
                            > In a message dated 8/24/2010 9:14:32 A.M. Pacific Daylight Time,
                            > john_thebabe@... writes:
                            >
                            >
                            >
                            >
                            > Hello and thank you for letting me join this group. Here is my story and my
                            > questions.
                            >
                            > BACKGROUND:
                            >
                            > I am the IT Director for a small IT shop of 2 developers and one
                            > Sys/Network Admin. We develop in house applications that drive our company's
                            > services. The main application, which we would stop all business if it died, was
                            > written by our senior developer by himself years before I or the others on
                            > my team started on with the company. He admits it is spaghetti code written
                            > in Visual FoxPro and right now our only methodology we follow, if you can
                            > call it one, is cowboy coding.
                            >
                            > I have taken on the daunting task of migrating those 100+ tables to SQL
                            > Server and doing away with the spaghetti code. Our other developer has not
                            > had the exposure to the logic or code so he will have to be immersed in this
                            > as well or we will have a lone developer forever on this application. We
                            > continue to have projects to add features to this application that dwill
                            > drive business development so you can see that a lone developer will hamper
                            > speed to market and competitive advantage.
                            >
                            > We have not had our Sprint planning meeting yet and are just talking about
                            > the requirements of Scrum.
                            >
                            > Goals:
                            >
                            > Move FoxPro tables to SQL Server
                            > Eliminate Spaghetti Code
                            > Create a means for multideveopers to code this application
                            >
                            > Challenges:
                            > Senior developer claims no usable code can be created in a single Sprint.
                            > Says it will take months to swim through this code.
                            >
                            > Other developer must be trained on logic and immersed in current code to
                            > assist.
                            >
                            > Questions:
                            >
                            > The rules of Scrum require usable code at the end of a Sprint correct? Is
                            > it ever possible that this would not be the case? Maybe I do not know th
                            > definition of "usable code".
                            >
                            > Can you run effective Scrum teams with 1 or two team members only?
                            >
                            > This is the first, I am sure, of many inquiries and I thank you for you
                            > for any assistance.
                            >
                          • mojavescout
                            Maurice, Very helpful and I am also going to bring ths up at our IT meeting as we discuss the use of Scrum and our strategy. I m glad I joined this group.
                            Message 13 of 27 , Aug 25, 2010
                            • 0 Attachment
                              Maurice,

                              Very helpful and I am also going to bring ths up at our IT meeting as we discuss the use of Scrum and our strategy. I'm glad I joined this group. Thank you.

                              John
                            • mojavescout
                              Roy Very good points and it looks like I am going to take away something from each reply and bring it to the table with my team. The code is very usable but
                              Message 14 of 27 , Aug 25, 2010
                              • 0 Attachment
                                Roy

                                Very good points and it looks like I am going to take away something from each reply and bring it to the table with my team. The code is very usable but known only by our Senior developer. We are at critical mass as the VFP tables are reaching their limits(2GB) and we end up playing a game of creating more tables. Normalization is not always followed so you see the spiral we are getting into as we go further. I might just take you up on that offline contact request.

                                Thanks

                                John- MojaveScout

                                --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
                                >
                                >
                                > I do like what you wrote, Maurice. And I too have found that problem of the users objecting to new design because it wasn't like the old design. Whether or not that a defect that was seen as a feature or not I am not sure, but certainly users are often very nostalgic about their old system interface. "But that's not the way the old system did it" is a very familiar cry to me.
                                >
                                >
                                >
                                > I would add some questions to your email, to find out more about this problem of 'spaghetti code'. How much of that 'spaghetti code' is to do with table handling, as in
                                >
                                >
                                >
                                >
                                >
                                >
                                > · ADD new records,
                                >
                                > · DELETE existing records,
                                > · MODIFY existing records,
                                > · SEARCH for specific records,
                                > · MOVE, COPY records
                                >
                                > · LIST records,
                                > · SEQUENCE records
                                > · QUERY, EXTRACT sets of information from the table
                                > · REPORT on data in the table.
                                > · Create Database Stored Procedures and Triggers
                                >
                                >
                                > I would suggest that with 100+ tables, each of which requires at least those basic functions of Add, Delete, Change, then it would be a good idea to write some standard 'table handling' or 'table maintenance' programs and then set up almost a production line of copying and modifying those standard programs for every table. Some of those 'copies' might take 2 hours max. to change for the new table, some may take as little as 15 minutes. Yes, 100+ tables is not a trivial task, but it can certainly be made much simpler and faster by using this strategy of standard programs and reuse.
                                >
                                >
                                >
                                > The problem of 'spaghetti code' becomes much more of a problem when you are looking at transaction processing type programs. But again, a large part of transaction processing programs, in an on-line, interactive database processing system is really just table updating ... not all, of course, but a lot.
                                >
                                >
                                >
                                > And of course, now you are using SQLServer, you can put a lot of tale processing code into SQL scripts, which can simplify things even further.
                                >
                                >
                                >
                                > Last question ... Is your current software product so broken that iot can't continue to be used 'as is' until you have created a new SQLServer-based version of the system? I had a similar situation when I had to rewrite a DOS/Clipper system into Windows/Delphi. But I must admit, I had it much easier because I had written the Clipper code using the same development tactics that I outlined above ... standard programs copied for each table.
                                >
                                >
                                >
                                > if 'mojavescout' wants some more explanation about what I am talking about, he (she) can contact me offline. I would be happy to share my experience and approach with him.
                                >
                                >
                                >
                                > Regards,
                                >
                                > Roy Morien
                                >
                                >
                                >
                                > To: scrumdevelopment@yahoogroups.com
                                > From: maurice.lerutte@...
                                > Date: Tue, 24 Aug 2010 22:11:40 +0200
                                > Subject: Re: [scrumdevelopment] Cowboy Spaghetti coding
                                >
                                >
                                >
                                >
                                >
                                >
                                > First of all I'd like to point out that the 'rules of Scrum' are in the end what you make of it. It is not like a law defined by nature or by the government, so you can adjust it any way you see fit. It may have impact on the effectiveness of your software development, positive or negative. The Scrum framework is simple and effective and that I wouldn't change too much too quickly, I wouldn't have too many discussions on 'the requirements of Scrum', as you wrote. Nobody is going to haunt you for doing it differently.
                                >
                                > The team's size does of course have impact on what you do. You should strive for the lowest process still effective. For example I'm not sure whether I would want somebody to have the role of ScrumMaster. I would still do the timeboxing, including the sprint I & II planning sessions, the review and some kind of retrospective, which may be some more of a reflection talk with each other.
                                >
                                > As keeping money flowing in is important I would advise to have the priorities still set by business, so have a product owner. You don't want to end up in the situation that the priorities are primarily set by the developers. Of course, setting priorities require input from the developers, but they don't make the last call.
                                >
                                > I don't know how feasible it is to make a big-bang switch from your old database engine to a new database engine, nor if it is possible to use the two engines at the same time. I do think that if you start refactoring you'll probably find out that you will want to change your database design, so you might give that some thought of how you are going to handle that.
                                >
                                > You indicate that the structure of the program has become too difficult to understand, so there is a need to rewrite what's there. You can't just start anew as you wouldn't have a sellable product until you had all features you already had. Note that what you may regard as defects may have become features for the customers, so be prepared to receive feedback that they liked the old way better. [*]
                                >
                                > I wouldn't just start around changing the code, my strategy has been to refactor a part of the code when there is a defect to be fixed or a new feature needs to be added to a part. We then imagined how we would have liked to be if there was no code already and use that as basis for the redesign.
                                >
                                > At the end of a sprint you should still have a working product, including the refactorings you made. If you don't do this the risks of regression grows all the time. You can use the old developer to find out if it still does what it did. It is likely that he'll still know the nitty gritty details.
                                >
                                > Maurice.
                                > [*] Yes, that actually happens.
                                >
                                > Op 24-8-2010 18:13, mojavescout schreef:
                                >
                                >
                                > Hello and thank you for letting me join this group. Here is my story and my questions.
                                >
                                > BACKGROUND:
                                >
                                > I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.
                                >
                                > I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.
                                >
                                > We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.
                                >
                                > Goals:
                                >
                                > Move FoxPro tables to SQL Server
                                > Eliminate Spaghetti Code
                                > Create a means for multideveopers to code this application
                                >
                                > Challenges:
                                > Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.
                                >
                                > Other developer must be trained on logic and immersed in current code to assist.
                                >
                                > Questions:
                                >
                                > The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".
                                >
                                > Can you run effective Scrum teams with 1 or two team members only?
                                >
                                > This is the first, I am sure, of many inquiries and I thank you for you for any assistance.
                                >
                                >
                                >
                                >
                                > --
                                > http://www.scrummaster.nl / http://twitter.com/scrumnl
                                >
                              • mojavescout
                                Thanks Wouter, Refactoring looks to be the strategy. Thanks for the examples and I how Scrum can be applied. John
                                Message 15 of 27 , Aug 25, 2010
                                • 0 Attachment
                                  Thanks Wouter,

                                  Refactoring looks to be the strategy. Thanks for the examples and I how Scrum can be applied.

                                  John

                                  --- In scrumdevelopment@yahoogroups.com, Wouter Lagerweij <wouter@...> wrote:
                                  >
                                  > On Tue, Aug 24, 2010 at 6:13 PM, mojavescout <john_thebabe@...> wrote:
                                  >
                                  > >
                                  > >
                                  > > Hello and thank you for letting me join this group. Here is my story and my
                                  > > questions.
                                  > >
                                  > > BACKGROUND:
                                  > >
                                  > > I am the IT Director for a small IT shop of 2 developers and one
                                  > > Sys/Network Admin. We develop in house applications that drive our company's
                                  > > services. The main application, which we would stop all business if it died,
                                  > > was written by our senior developer by himself years before I or the others
                                  > > on my team started on with the company. He admits it is spaghetti code
                                  > > written in Visual FoxPro and right now our only methodology we follow, if
                                  > > you can call it one, is cowboy coding.
                                  > >
                                  > > I have taken on the daunting task of migrating those 100+ tables to SQL
                                  > > Server and doing away with the spaghetti code. Our other developer has not
                                  > > had the exposure to the logic or code so he will have to be immersed in this
                                  > > as well or we will have a lone developer forever on this application. We
                                  > > continue to have projects to add features to this application that dwill
                                  > > drive business development so you can see that a lone developer will hamper
                                  > > speed to market and competitive advantage.
                                  > >
                                  > > We have not had our Sprint planning meeting yet and are just talking about
                                  > > the requirements of Scrum.
                                  > >
                                  > > Goals:
                                  > >
                                  > > Move FoxPro tables to SQL Server
                                  > > Eliminate Spaghetti Code
                                  > > Create a means for multideveopers to code this application
                                  > >
                                  > > Challenges:
                                  > > Senior developer claims no usable code can be created in a single Sprint.
                                  > > Says it will take months to swim through this code.
                                  > >
                                  > > Other developer must be trained on logic and immersed in current code to
                                  > > assist.
                                  > >
                                  > > Questions:
                                  > >
                                  > > The rules of Scrum require usable code at the end of a Sprint correct? Is
                                  > > it ever possible that this would not be the case? Maybe I do not know th
                                  > > definition of "usable code".
                                  > >
                                  > > Can you run effective Scrum teams with 1 or two team members only?
                                  > >
                                  > > This is the first, I am sure, of many inquiries and I thank you for you for
                                  > > any assistance.
                                  > >
                                  >
                                  > For me, the definition of usable code is code that can be released. What
                                  > that means in the context of this application depends on your approach: Are
                                  > you 'refactoring' (on a fairly large scale), or re-writing?
                                  >
                                  > If refactoring, then 'usable code' means that at the end of every sprint,
                                  > you have a working system, which can be released should you wish to do so.
                                  > In general, this is a *very* good idea to do when doing these kind of
                                  > changes, since it forces you to not take steps that are too big while
                                  > refactoring. And it fits in the agile way of working, forcing you to fail
                                  > early.
                                  >
                                  > A re-write would be a little different, in that you would have 'releaseable
                                  > code', but not a releaseable feature set at the end of each sprint. This
                                  > could work if your customers can continue using the old version while you
                                  > write a new one. Of course, any changes that have to be made while you write
                                  > the new one will be added to your 'rework' scope, which can get to be quite
                                  > painful. I've been in that situation, and would only recommend going this
                                  > way if the software is very small, and a re-write very quick. But if that
                                  > were the case, you wouldn't have this issue, probably...
                                  >
                                  > In either case, make sure you spend a *lot* of time on testing. I don't know
                                  > the technology involved, but making sure that you know you didn't break
                                  > anything in your rewrite/refactoring is Rule Number One.
                                  >
                                  > The second Rule Number One is that you get involvement from your product
                                  > owner/client, and discuss per piece of work whether the current
                                  > functionality *should* remain as-is.
                                  > I've seen situation where great pains were taken to ensure complete feature
                                  > parity and pixel-perfect data-migration, taking a huge amount of time, where
                                  > the customer in the end said: 'Oh that! We don't really use that...'. Or,
                                  > worse, 'Oh yeah, those records are in there, but they'll never be looked at
                                  > again.' In the cases where those remarks came *before* we started the
                                  > work, this was nice. In the cases where it came *during*, it was still a bit
                                  > of a relieve. In the cases where it came while looking back at a failed
                                  > project, it was a bit painful...
                                  >
                                  > Wouter
                                  >
                                • mojavescout
                                  Thanks George! I have answered your questions below. I appreciate the help. John - MojaveScout ... John Wrote: No, staying with VFP for now, Java in future and
                                  Message 16 of 27 , Aug 25, 2010
                                  • 0 Attachment
                                    Thanks George! I have answered your questions below. I appreciate the help.

                                    John - MojaveScout

                                    --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                    >
                                    > Hi, Mojave Scout,
                                    >
                                    > It is a daunting task, indeed. But gradual refactoring of legacy code
                                    > to a better foundation for the future is, in my experience, possible.
                                    > Your migration task is orthogonal to Scrum.
                                    >
                                    > Take a look at the Strangler Pattern. Martin Fowler has a good writeup
                                    > on the web.
                                    >
                                    > On 8/25/10 12:13 AM, mojavescout wrote:
                                    > > Goals:
                                    > >
                                    > > Move FoxPro tables to SQL Server
                                    >
                                    > What language are you using for the code? Can it access both FoxPro and
                                    > SQL Server? Or are you changing implementation languages, too?

                                    John Wrote: No, staying with VFP for now, Java in future and using SQL Stored procedures. Looked at C Sharp and .Net but the capital required seemed outside budget as well as the expertise.
                                    >
                                    > > Eliminate Spaghetti Code
                                    >
                                    > Did you forget the step of solving the Arab/Israeli conflict in the
                                    > Middle East?

                                    John Wrote: I have a plan for that as well but after I finish up on my work on a cold fusion lunch pail.

                                    > > Create a means for multideveopers to code this application
                                    > >
                                    > > Challenges:
                                    > > Senior developer claims no usable code can be created in a single
                                    > > Sprint. Says it will take months to swim through this code.
                                    >
                                    > I suspect he's under-estimating.

                                    John Wrote: Might be
                                    >
                                    > > Other developer must be trained on logic and immersed in current code
                                    > > to assist.
                                    >
                                    > Trained? How about work with it, and have the original coder highly
                                    > available to answer questions and demonstrate things?

                                    John Wrote: Yes that is the plan. I was not exactly clear but they will develop features expected by Business Development in the same application together. This is a new version rollout we have been committed to and I will have both of them working on it. Both will sit in the same room and be sequestered. I have the CEOs consent on this as it will prolong the new version rollout.
                                    > >
                                    > > Questions:
                                    > >
                                    > > The rules of Scrum require usable code at the end of a Sprint
                                    > > correct? Is it ever possible that this would not be the case? Maybe I
                                    > > do not know th definition of "usable code".
                                    >
                                    > The system should still work, and any new features that have been added
                                    > should work.
                                    >
                                    > > Can you run effective Scrum teams with 1 or two team members only?
                                    >
                                    > Yes, it's just the work gets done slower. And you probably need less
                                    > formality for your meetings.
                                    >
                                    > - George
                                    >
                                    > --
                                    > ----------------------------------------------------------------------
                                    > * George Dinwiddie * http://blog.gdinwiddie.com
                                    > Software Development http://www.idiacomputing.com
                                    > Consultant and Coach http://www.agilemaryland.org
                                    > ----------------------------------------------------------------------
                                    >
                                  • mojavescout
                                    Malcolm, Checking on the price of this book now. We do have tables that are used infrequently so we can migrate over in one Sprint then we can evaluate the
                                    Message 17 of 27 , Aug 25, 2010
                                    • 0 Attachment
                                      Malcolm,

                                      Checking on the price of this book now. We do have tables that are used infrequently so we can migrate over in one Sprint then we can evaluate the process and the logice involved. Good idea. Thanks

                                      John- MojaveScout


                                      --- In scrumdevelopment@yahoogroups.com, Malcolm Anderson <malcolm.b.anderson@...> wrote:
                                      >
                                      > This doesn't show up to me so much as a "Scrum Question tm" but more of a
                                      > "how do we refactor this bad boy?"
                                      >
                                      > plus as an old foxpro coder, I can't resist this question.
                                      >
                                      > I once had to maintain a brittle foxpro app for the state of Oregon and
                                      > found that some of the procedures were 1300 lines long. The first thing I
                                      > did was to create a set of test cases, and then start refactoring that code
                                      > to get it down to manageable sized procedures, while still being able to run
                                      > my tests.
                                      >
                                      > Two suggestions,
                                      > 1) Buy and Read Michael Feathers, "Working Effectively With Legacy Code"
                                      >
                                      > 2) Set your first 2 week sprint's goal to move 1 (one) table over to SQL,
                                      > with all associated logic moved to it's associated new home. Make it a
                                      > small table that is infrequently used. Call it "a proof of concept", or "a
                                      > quick win"
                                      >
                                      > Good Luck
                                      >
                                      > Malcolm
                                      >
                                      >
                                      >
                                      >
                                      >
                                      > On Tue, Aug 24, 2010 at 11:13 AM, mojavescout <john_thebabe@...>wrote:
                                      >
                                      > >
                                      > >
                                      > > Hello and thank you for letting me join this group. Here is my story and my
                                      > > questions.
                                      > >
                                      > > BACKGROUND:
                                      > >
                                      > > I am the IT Director for a small IT shop of 2 developers and one
                                      > > Sys/Network Admin. We develop in house applications that drive our company's
                                      > > services. The main application, which we would stop all business if it died,
                                      > > was written by our senior developer by himself years before I or the others
                                      > > on my team started on with the company. He admits it is spaghetti code
                                      > > written in Visual FoxPro and right now our only methodology we follow, if
                                      > > you can call it one, is cowboy coding.
                                      > >
                                      > > I have taken on the daunting task of migrating those 100+ tables to SQL
                                      > > Server and doing away with the spaghetti code. Our other developer has not
                                      > > had the exposure to the logic or code so he will have to be immersed in this
                                      > > as well or we will have a lone developer forever on this application. We
                                      > > continue to have projects to add features to this application that dwill
                                      > > drive business development so you can see that a lone developer will hamper
                                      > > speed to market and competitive advantage.
                                      > >
                                      > > We have not had our Sprint planning meeting yet and are just talking about
                                      > > the requirements of Scrum.
                                      > >
                                      > > Goals:
                                      > >
                                      > > Move FoxPro tables to SQL Server
                                      > > Eliminate Spaghetti Code
                                      > > Create a means for multideveopers to code this application
                                      > >
                                      > > Challenges:
                                      > > Senior developer claims no usable code can be created in a single Sprint.
                                      > > Says it will take months to swim through this code.
                                      > >
                                      > > Other developer must be trained on logic and immersed in current code to
                                      > > assist.
                                      > >
                                      > > Questions:
                                      > >
                                      > > The rules of Scrum require usable code at the end of a Sprint correct? Is
                                      > > it ever possible that this would not be the case? Maybe I do not know th
                                      > > definition of "usable code".
                                      > >
                                      > > Can you run effective Scrum teams with 1 or two team members only?
                                      > >
                                      > > This is the first, I am sure, of many inquiries and I thank you for you for
                                      > > any assistance.
                                      > >
                                      > >
                                      > >
                                      >
                                    • James Lor
                                      Hi I once had to update legacy spaghetti code. What I did was rename all the variables into something meaningful. PaidAmount instead of x, Taxes instead of y,
                                      Message 18 of 27 , Aug 25, 2010
                                      • 0 Attachment

                                        Hi

                                         

                                        I once had to update legacy spaghetti code. What I did was rename all the variables into something meaningful. PaidAmount instead of x, Taxes instead of y, etc. Then I indented everything. A lot less daunting after that.

                                         

                                        James Lor

                                         

                                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mojavescout
                                        Sent: Wednesday, August 25, 2010 1:43 PM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: [scrumdevelopment] Re: Cowboy Spaghetti coding

                                         

                                         

                                        Malcolm,

                                        Checking on the price of this book now. We do have tables that are used infrequently so we can migrate over in one Sprint then we can evaluate the process and the logice involved. Good idea. Thanks

                                        John- MojaveScout

                                        --- In scrumdevelopment@yahoogroups.com, Malcolm Anderson <malcolm.b.anderson@...> wrote:

                                        >
                                        > This doesn't show up to me so much as a "Scrum Question tm" but
                                        more of a
                                        > "how do we refactor this bad boy?"
                                        >
                                        > plus as an old foxpro coder, I can't resist this question.
                                        >
                                        > I once had to maintain a brittle foxpro app for the state of Oregon and
                                        > found that some of the procedures were 1300 lines long. The first thing I
                                        > did was to create a set of test cases, and then start refactoring that
                                        code
                                        > to get it down to manageable sized procedures, while still being able to
                                        run
                                        > my tests.
                                        >
                                        > Two suggestions,
                                        > 1) Buy and Read Michael Feathers, "Working Effectively With Legacy
                                        Code"
                                        >
                                        > 2) Set your first 2 week sprint's goal to move 1 (one) table over to SQL,
                                        > with all associated logic moved to it's associated new home. Make it a
                                        > small table that is infrequently used. Call it "a proof of
                                        concept", or "a
                                        > quick win"
                                        >
                                        > Good Luck
                                        >
                                        > Malcolm
                                        >
                                        >
                                        >
                                        >
                                        >
                                        > On Tue, Aug 24, 2010 at 11:13 AM, mojavescout
                                        <john_thebabe@...>wrote:
                                        >
                                        > >
                                        > >
                                        > > Hello and thank you for letting me join this group. Here is my story
                                        and my
                                        > > questions.
                                        > >
                                        > > BACKGROUND:
                                        > >
                                        > > I am the IT Director for a small IT shop of 2 developers and one
                                        > > Sys/Network Admin. We develop in house applications that drive our
                                        company's
                                        > > services. The main application, which we would stop all business if
                                        it died,
                                        > > was written by our senior developer by himself years before I or the
                                        others
                                        > > on my team started on with the company. He admits it is spaghetti
                                        code
                                        > > written in Visual FoxPro and right now our only methodology we
                                        follow, if
                                        > > you can call it one, is cowboy coding.
                                        > >
                                        > > I have taken on the daunting task of migrating those 100+ tables to
                                        SQL
                                        > > Server and doing away with the spaghetti code. Our other developer
                                        has not
                                        > > had the exposure to the logic or code so he will have to be immersed
                                        in this
                                        > > as well or we will have a lone developer forever on this application.
                                        We
                                        > > continue to have projects to add features to this application that
                                        dwill
                                        > > drive business development so you can see that a lone developer will
                                        hamper
                                        > > speed to market and competitive advantage.
                                        > >
                                        > > We have not had our Sprint planning meeting yet and are just talking
                                        about
                                        > > the requirements of Scrum.
                                        > >
                                        > > Goals:
                                        > >
                                        > > Move FoxPro tables to SQL Server
                                        > > Eliminate Spaghetti Code
                                        > > Create a means for multideveopers to code this application
                                        > >
                                        > > Challenges:
                                        > > Senior developer claims no usable code can be created in a single
                                        Sprint.
                                        > > Says it will take months to swim through this code.
                                        > >
                                        > > Other developer must be trained on logic and immersed in current code
                                        to
                                        > > assist.
                                        > >
                                        > > Questions:
                                        > >
                                        > > The rules of Scrum require usable code at the end of a Sprint
                                        correct? Is
                                        > > it ever possible that this would not be the case? Maybe I do not know
                                        th
                                        > > definition of "usable code".
                                        > >
                                        > > Can you run effective Scrum teams with 1 or two team members only?
                                        > >
                                        > > This is the first, I am sure, of many inquiries and I thank you for
                                        you for
                                        > > any assistance.
                                        > >
                                        > >
                                        > >
                                        >

                                      • Steven Gojanovich
                                        Good concept . Great book!   Steve ... From: Malcolm Anderson Subject: Re: [scrumdevelopment] Cowboy Spaghetti coding To:
                                        Message 19 of 27 , Aug 25, 2010
                                        • 0 Attachment
                                          Good concept . Great book!
                                           
                                          Steve

                                          --- On Wed, 8/25/10, Malcolm Anderson <malcolm.b.anderson@...> wrote:

                                          From: Malcolm Anderson <malcolm.b.anderson@...>
                                          Subject: Re: [scrumdevelopment] Cowboy Spaghetti coding
                                          To: scrumdevelopment@yahoogroups.com
                                          Date: Wednesday, August 25, 2010, 10:30 AM

                                           
                                          This doesn't show up to me so much as a "Scrum Question tm" but more of a "how do we refactor this bad boy?"

                                          plus as an old foxpro coder, I can't resist this question.

                                          I once had to maintain a brittle foxpro app for the state of Oregon and found that some of the procedures were 1300 lines long.  The first thing I did was to create a set of test cases, and then start refactoring that code to get it down to manageable sized procedures, while still being able to run my tests. 

                                          Two suggestions,
                                          1) Buy and Read Michael Feathers, "Working Effectively With Legacy Code"

                                          2) Set your first 2 week sprint's goal to move 1 (one) table over to SQL, with all associated logic moved to it's associated new home.  Make it a small table that is infrequently used.  Call it "a proof of concept", or "a quick win"

                                          Good Luck

                                          Malcolm

                                           



                                          On Tue, Aug 24, 2010 at 11:13 AM, mojavescout <john_thebabe@...> wrote:
                                           
                                          Hello and thank you for letting me join this group. Here is my story and my questions.

                                          BACKGROUND:

                                          I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.

                                          I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.

                                          We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.

                                          Goals:

                                          Move FoxPro tables to SQL Server
                                          Eliminate Spaghetti Code
                                          Create a means for multideveopers to code this application

                                          Challenges:
                                          Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.

                                          Other developer must be trained on logic and immersed in current code to assist.

                                          Questions:

                                          The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".

                                          Can you run effective Scrum teams with 1 or two team members only?

                                          This is the first, I am sure, of many inquiries and I thank you for you for any assistance.



                                        • Malcolm Anderson
                                          Yup, amazing how readable code can become when you make minor changes like that. There are days when brownfield development can be a lot of fun ..... Oh, so
                                          Message 20 of 27 , Aug 25, 2010
                                          • 0 Attachment
                                            Yup, amazing how readable code can become when you make minor changes like that.

                                            There are days when brownfield development can be a lot of fun ..... "Oh, so THAT'S what this hunk of code is supposed to do, into your own method you go"

                                            Of course, it helps if you have put together a raft of unit and integration tests before you start.

                                            Malcolm



                                            On Wed, Aug 25, 2010 at 12:53 PM, James Lor <James.Lor@...> wrote:
                                             

                                            Hi

                                             

                                            I once had to update legacy spaghetti code. What I did was rename all the variables into something meaningful. PaidAmount instead of x, Taxes instead of y, etc. Then I indented everything. A lot less daunting after that.

                                             

                                            James Lor

                                             

                                            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mojavescout
                                            Sent: Wednesday, August 25, 2010 1:43 PM
                                            To: scrumdevelopment@yahoogroups.com
                                            Subject: [scrumdevelopment] Re: Cowboy Spaghetti coding

                                             

                                             

                                            Malcolm,

                                            Checking on the price of this book now. We do have tables that are used infrequently so we can migrate over in one Sprint then we can evaluate the process and the logice involved. Good idea. Thanks

                                            John- MojaveScout

                                            --- In scrumdevelopment@yahoogroups.com, Malcolm Anderson <malcolm.b.anderson@...> wrote:
                                            >
                                            > This doesn't show up to me so much as a "Scrum Question tm" but more of a
                                            > "how do we refactor this bad boy?"
                                            >
                                            > plus as an old foxpro coder, I can't resist this question.
                                            >
                                            > I once had to maintain a brittle foxpro app for the state of Oregon and
                                            > found that some of the procedures were 1300 lines long. The first thing I
                                            > did was to create a set of test cases, and then start refactoring that code
                                            > to get it down to manageable sized procedures, while still being able to run
                                            > my tests.
                                            >
                                            > Two suggestions,
                                            > 1) Buy and Read Michael Feathers, "Working Effectively With Legacy Code"
                                            >
                                            > 2) Set your first 2 week sprint's goal to move 1 (one) table over to SQL,
                                            > with all associated logic moved to it's associated new home. Make it a
                                            > small table that is infrequently used. Call it "a proof of concept", or "a
                                            > quick win"
                                            >
                                            > Good Luck
                                            >
                                            > Malcolm
                                            >
                                            >
                                            >
                                            >
                                            >
                                            > On Tue, Aug 24, 2010 at 11:13 AM, mojavescout <john_thebabe@...>wrote:
                                            >
                                            > >
                                            > >
                                            > > Hello and thank you for letting me join this group. Here is my story and my
                                            > > questions.
                                            > >
                                            > > BACKGROUND:
                                            > >
                                            > > I am the IT Director for a small IT shop of 2 developers and one
                                            > > Sys/Network Admin. We develop in house applications that drive our company's
                                            > > services. The main application, which we would stop all business if it died,
                                            > > was written by our senior developer by himself years before I or the others
                                            > > on my team started on with the company. He admits it is spaghetti code
                                            > > written in Visual FoxPro and right now our only methodology we follow, if
                                            > > you can call it one, is cowboy coding.
                                            > >
                                            > > I have taken on the daunting task of migrating those 100+ tables to SQL
                                            > > Server and doing away with the spaghetti code. Our other developer has not
                                            > > had the exposure to the logic or code so he will have to be immersed in this
                                            > > as well or we will have a lone developer forever on this application. We
                                            > > continue to have projects to add features to this application that dwill
                                            > > drive business development so you can see that a lone developer will hamper
                                            > > speed to market and competitive advantage.
                                            > >
                                            > > We have not had our Sprint planning meeting yet and are just talking about
                                            > > the requirements of Scrum.
                                            > >
                                            > > Goals:
                                            > >
                                            > > Move FoxPro tables to SQL Server
                                            > > Eliminate Spaghetti Code
                                            > > Create a means for multideveopers to code this application
                                            > >
                                            > > Challenges:
                                            > > Senior developer claims no usable code can be created in a single Sprint.
                                            > > Says it will take months to swim through this code.
                                            > >
                                            > > Other developer must be trained on logic and immersed in current code to
                                            > > assist.
                                            > >
                                            > > Questions:
                                            > >
                                            > > The rules of Scrum require usable code at the end of a Sprint correct? Is
                                            > > it ever possible that this would not be the case? Maybe I do not know th
                                            > > definition of "usable code".
                                            > >
                                            > > Can you run effective Scrum teams with 1 or two team members only?
                                            > >
                                            > > This is the first, I am sure, of many inquiries and I thank you for you for
                                            > > any assistance.
                                            > >
                                            > >
                                            > >
                                            >


                                          • Roy Morien
                                            You are welcome at any time, John. I have a couple of interesting little stories (at least, I think they are interesting) about those standard programs that
                                            Message 21 of 27 , Aug 25, 2010
                                            • 0 Attachment
                                              You are welcome at any time, John.
                                               
                                              I have a couple of interesting little stories (at least, I think they are interesting) about those 'standard programs' that I mentioned.
                                               
                                              In one shop, where we had Mantis newly installed (for the ignorant ... or the young ... Mantis was an IDE published by Cincom for IBM mainframes in the 1980's ... sort of an early text-based VB) I developed a set of standard programs to do what I have said ... Add records, Delete records, Change records, Find records etc. in a table. I was able to develop very quickly using these standard programs. One day I was asked to introduce these to relatively newbie programmer, who promptly started to spend many many hours changing them, because he didn't like my style of programming.  So instead of getting the job done qickly with proven 'template programs', as I called them, he sort of got the job done after a very lengthy period of time with his new look programs. Because of this, the IT manager indicated that this was proof that my concept of 'template programs' wasn't very useful.  That same IT manager also told me that he totally failed to see how I could prophesy the future processing requirements of the organisation and encapsulate that in a few so-called 'template programs'. What he really totally failed to see was that I was not prophesying the future processing requirements, but I was in part establishing future interface guidelines and standards for when that type of processing was required ... which in fact was usually the case. Online, interactive database processing was basically the order of the day, and still is in most commercial organisations processing their data.
                                               
                                              By the way, in Mantis, I had, for example, a 1500 line 'template program' to do all these good things. At about the 200 line mark, I had a comment '*/ no code changes below this line are needed /*'. So, 1300+ lines of code were 'free' every time you modified the code for another table. The 200 or so changeable lines were basically to do with primary key handling, virtual field handling, field editting etc. which was table-specific.
                                               
                                              I moved to another organisation where I also introduced my Mantis 'template programs'. This time, the IT manager was quite impressed. But after some months, they decided to move to ADABAS and the associated language (whose name escapes me for the moment). The IT manager asked me to collaborate with a newly hired 'expert programmer' in that language, for the purpose of developing a similar set of template programs in the new language. After some weeks of development, the 'expert programmer' proudly showed me a set of very simple programs to 'Add a record', to 'Delete a record' etc. I asked him why he hadn't developed an integrated set of functionality to do data maintenance (ie:, Add, Delete, Edit etc etc) in one program. His answer was that programmers who were not very familiar with this new language would have difficulty understanding all the code. This view of things totally missed the point that 75% of the code did not need to be changed. It totally missed the point too that maybe those 'newbie' programmers could fast-track their learning by looking at his expertly scupltured code. Unfortunately as it turned out his code was not very expertly scupltured.
                                               
                                              My last little anecdote is about students doing a project, which was in industry, and not really trivial, although it wasn't huge. These students adopted Access and Access VBA for development 'because it was simple to do'. I told them that they could get no assistance from me because I didn't know anything about Access VBA. My expertise, at that time, was in Borland Delphi, which I had used to develop a new set of 'template programs'. They persisted, however, because 'using Access made it smple to develop the system'. This was especially when they used the forms wizard etc. The inevitable outcome (I think) was that they failed to produce a system that came anywhere near meeting professional and useability standards. So they Failed the subject.  However, I gave them the chance to re-do the project, using my Delphi templates programs, which they had assumed were too complex. In 4 weeks they had a new system up and running, which delighted the client, and was very successful in meeting the requirements. They told me that by using the template programs they were able to produce this very good result very quickly, much to their surprise, and they were delighted with it. They then passed the subject and went on their merry way to graduate and become ... real estate salesmen, MacDonald managers ... something like that Winking smile
                                               
                                              Anyway, my point in telling these little anecdotes is 3-fold: 1. Using a well developed, sophisticated set of 'template programs' works, and works extremely well. 2. Many IT people just don't get it!  3. Newbie developers can be very productive, and learn very effectively, by using a good set of templae programs.
                                               
                                              Regards,
                                              Roy Morien

                                              To: scrumdevelopment@yahoogroups.com
                                              From: john_thebabe@...
                                              Date: Wed, 25 Aug 2010 17:16:17 +0000
                                              Subject: [scrumdevelopment] Re: Cowboy Spaghetti coding

                                               
                                              Roy

                                              Very good points and it looks like I am going to take away something from each reply and bring it to the table with my team. The code is very usable but known only by our Senior developer. We are at critical mass as the VFP tables are reaching their limits(2GB) and we end up playing a game of creating more tables. Normalization is not always followed so you see the spiral we are getting into as we go further. I might just take you up on that offline contact request.

                                              Thanks

                                              John- MojaveScout

                                              --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
                                              >
                                              >
                                              > I do like what you wrote, Maurice. And I too have found that problem of the users objecting to new design because it wasn't like the old design. Whether or not that a defect that was seen as a feature or not I am not sure, but certainly users are often very nostalgic about their old system interface. "But that's not the way the old system did it" is a very familiar cry to me.
                                              >
                                              >
                                              >
                                              > I would add some questions to your email, to find out more about this problem of 'spaghetti code'. How much of that 'spaghetti code' is to do with table handling, as in
                                              >
                                              >
                                              >
                                              >
                                              >
                                              >
                                              > · ADD new records,
                                              >
                                              > · DELETE existing records,
                                              > · MODIFY existing records,
                                              > · SEARCH for specific records,
                                              > · MOVE, COPY records
                                              >
                                              > · LIST records,
                                              > · SEQUENCE records
                                              > · QUERY, EXTRACT sets of information from the table
                                              > · REPORT on data in the table.
                                              > · Create Database Stored Procedures and Triggers
                                              >
                                              >
                                              > I would suggest that with 100+ tables, each of which requires at least those basic functions of Add, Delete, Change, then it would be a good idea to write some standard 'table handling' or 'table maintenance' programs and then set up almost a production line of copying and modifying those standard programs for every table. Some of those 'copies' might take 2 hours max. to change for the new table, some may take as little as 15 minutes. Yes, 100+ tables is not a trivial task, but it can certainly be made much simpler and faster by using this strategy of standard programs and reuse.
                                              >
                                              >
                                              >
                                              > The problem of 'spaghetti code' becomes much more of a problem when you are looking at transaction processing type programs. But again, a large part of transaction processing programs, in an on-line, interactive database processing system is really just table updating ... not all, of course, but a lot.
                                              >
                                              >
                                              >
                                              > And of course, now you are using SQLServer, you can put a lot of tale processing code into SQL scripts, which can simplify things even further.
                                              >
                                              >
                                              >
                                              > Last question ... Is your current software product so broken that iot can't continue to be used 'as is' until you have created a new SQLServer-based version of the system? I had a similar situation when I had to rewrite a DOS/Clipper system into Windows/Delphi. But I must admit, I had it much easier because I had written the Clipper code using the same development tactics that I outlined above ... standard programs copied for each table.
                                              >
                                              >
                                              >
                                              > if 'mojavescout' wants some more explanation about what I am talking about, he (she) can contact me offline. I would be happy to share my experience and approach with him.
                                              >
                                              >
                                              >
                                              > Regards,
                                              >
                                              > Roy Morien
                                              >
                                              >
                                              >
                                              > To: scrumdevelopment@yahoogroups.com
                                              > From: maurice.lerutte@...
                                              > Date: Tue, 24 Aug 2010 22:11:40 +0200
                                              > Subject: Re: [scrumdevelopment] Cowboy Spaghetti coding
                                              >
                                              >
                                              >
                                              >
                                              >
                                              >
                                              > First of all I'd like to point out that the 'rules of Scrum' are in the end what you make of it. It is not like a law defined by nature or by the government, so you can adjust it any way you see fit. It may have impact on the effectiveness of your software development, positive or negative. The Scrum framework is simple and effective and that I wouldn't change too much too quickly, I wouldn't have too many discussions on 'the requirements of Scrum', as you wrote. Nobody is going to haunt you for doing it differently.
                                              >
                                              > The team's size does of course have impact on what you do. You should strive for the lowest process still effective. For example I'm not sure whether I would want somebody to have the role of ScrumMaster. I would still do the timeboxing, including the sprint I & II planning sessions, the review and some kind of retrospective, which may be some more of a reflection talk with each other.
                                              >
                                              > As keeping money flowing in is important I would advise to have the priorities still set by business, so have a product owner. You don't want to end up in the situation that the priorities are primarily set by the developers. Of course, setting priorities require input from the developers, but they don't make the last call.
                                              >
                                              > I don't know how feasible it is to make a big-bang switch from your old database engine to a new database engine, nor if it is possible to use the two engines at the same time. I do think that if you start refactoring you'll probably find out that you will want to change your database design, so you might give that some thought of how you are going to handle that.
                                              >
                                              > You indicate that the structure of the program has become too difficult to understand, so there is a need to rewrite what's there. You can't just start anew as you wouldn't have a sellable product until you had all features you already had. Note that what you may regard as defects may have become features for the customers, so be prepared to receive feedback that they liked the old way better. [*]
                                              >
                                              > I wouldn't just start around changing the code, my strategy has been to refactor a part of the code when there is a defect to be fixed or a new feature needs to be added to a part. We then imagined how we would have liked to be if there was no code already and use that as basis for the redesign.
                                              >
                                              > At the end of a sprint you should still have a working product, including the refactorings you made. If you don't do this the risks of regression grows all the time. You can use the old developer to find out if it still does what it did. It is likely that he'll still know the nitty gritty details.
                                              >
                                              > Maurice.
                                              > [*] Yes, that actually happens.
                                              >
                                              > Op 24-8-2010 18:13, mojavescout schreef:
                                              >
                                              >
                                              > Hello and thank you for letting me join this group. Here is my story and my questions.
                                              >
                                              > BACKGROUND:
                                              >
                                              > I am the IT Director for a small IT shop of 2 developers and one Sys/Network Admin. We develop in house applications that drive our company's services. The main application, which we would stop all business if it died, was written by our senior developer by himself years before I or the others on my team started on with the company. He admits it is spaghetti code written in Visual FoxPro and right now our only methodology we follow, if you can call it one, is cowboy coding.
                                              >
                                              > I have taken on the daunting task of migrating those 100+ tables to SQL Server and doing away with the spaghetti code. Our other developer has not had the exposure to the logic or code so he will have to be immersed in this as well or we will have a lone developer forever on this application. We continue to have projects to add features to this application that dwill drive business development so you can see that a lone developer will hamper speed to market and competitive advantage.
                                              >
                                              > We have not had our Sprint planning meeting yet and are just talking about the requirements of Scrum.
                                              >
                                              > Goals:
                                              >
                                              > Move FoxPro tables to SQL Server
                                              > Eliminate Spaghetti Code
                                              > Create a means for multideveopers to code this application
                                              >
                                              > Challenges:
                                              > Senior developer claims no usable code can be created in a single Sprint. Says it will take months to swim through this code.
                                              >
                                              > Other developer must be trained on logic and immersed in current code to assist.
                                              >
                                              > Questions:
                                              >
                                              > The rules of Scrum require usable code at the end of a Sprint correct? Is it ever possible that this would not be the case? Maybe I do not know th definition of "usable code".
                                              >
                                              > Can you run effective Scrum teams with 1 or two team members only?
                                              >
                                              > This is the first, I am sure, of many inquiries and I thank you for you for any assistance.
                                              >
                                              >
                                              >
                                              >
                                              > --
                                              > http://www.scrummaster.nl / http://twitter.com/scrumnl
                                              >


                                            • George Dinwiddie
                                              John, ... You re outside my language expertise, but it should be possible to migrate tables in groups, if the DB doesn t have foreign key references tying them
                                              Message 22 of 27 , Aug 26, 2010
                                              • 0 Attachment
                                                John,

                                                On 8/26/10 1:36 AM, mojavescout wrote:
                                                > Thanks George! I have answered your questions below. I appreciate the help.
                                                >
                                                > John - MojaveScout
                                                >
                                                > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie<lists@...> wrote:
                                                >>
                                                >> Hi, Mojave Scout,
                                                >>
                                                >> It is a daunting task, indeed. But gradual refactoring of legacy code
                                                >> to a better foundation for the future is, in my experience, possible.
                                                >> Your migration task is orthogonal to Scrum.
                                                >>
                                                >> Take a look at the Strangler Pattern. Martin Fowler has a good writeup
                                                >> on the web.
                                                >>
                                                >> On 8/25/10 12:13 AM, mojavescout wrote:
                                                >>> Goals:
                                                >>>
                                                >>> Move FoxPro tables to SQL Server
                                                >>
                                                >> What language are you using for the code? Can it access both FoxPro and
                                                >> SQL Server? Or are you changing implementation languages, too?
                                                >
                                                > John Wrote: No, staying with VFP for now, Java in future and using
                                                > SQL Stored procedures. Looked at C Sharp and .Net but the capital
                                                > required seemed outside budget as well as the expertise.

                                                You're outside my language expertise, but it should be possible to
                                                migrate tables in groups, if the DB doesn't have foreign key references
                                                tying them all together.

                                                >>> Create a means for multideveopers to code this application
                                                >>>
                                                >>> Challenges:
                                                >>> Senior developer claims no usable code can be created in a single
                                                >>> Sprint. Says it will take months to swim through this code.
                                                >>
                                                >> I suspect he's under-estimating.
                                                >
                                                > John Wrote: Might be

                                                While I think it will take a long time to clean up the code, I'm quite
                                                convinced it can be done incrementally. I suggest Martin Fowler's book,
                                                Refactoring, and Michael Feathers' book Working Effectively With Legacy
                                                code. Be sure to resist the temptation to rewrite the system, and just
                                                slowly clean it up as you touch code.

                                                >>> Other developer must be trained on logic and immersed in current code
                                                >>> to assist.
                                                >>
                                                >> Trained? How about work with it, and have the original coder highly
                                                >> available to answer questions and demonstrate things?
                                                >
                                                > John Wrote: Yes that is the plan. I was not exactly clear but they
                                                > will develop features expected by Business Development in the same
                                                > application together. This is a new version rollout we have been
                                                > committed to and I will have both of them working on it. Both will
                                                > sit in the same room and be sequestered. I have the CEOs consent on
                                                > this as it will prolong the new version rollout.

                                                They could surprise you. There is synergy with multiple people working
                                                together. Once they get going, they could find some good ways of making
                                                it happen faster. Just don't let them sacrifice quality, as that will
                                                ultimately slow them down.

                                                - George

                                                --
                                                ----------------------------------------------------------------------
                                                * George Dinwiddie * http://blog.gdinwiddie.com
                                                Software Development http://www.idiacomputing.com
                                                Consultant and Coach http://www.agilemaryland.org
                                                ----------------------------------------------------------------------
                                              • Ron Jeffries
                                                Hello, Roy. On Thursday, August 26, 2010, at 1:45:35 AM, you ... Roy, there is a conversation going on on the XP list now that would benefit from these
                                                Message 23 of 27 , Aug 26, 2010
                                                • 0 Attachment
                                                  Hello, Roy. On Thursday, August 26, 2010, at 1:45:35 AM, you
                                                  wrote:

                                                  > I have a couple of interesting little stories (at least, I think
                                                  > they are interesting) about those 'standard programs' that I mentioned.

                                                  Roy, there is a conversation going on on the XP list now that would
                                                  benefit from these stories. May I repost your note there, please?

                                                  Ron Jeffries
                                                  www.XProgramming.com
                                                  www.xprogramming.com/blog
                                                  To gain knowledge, add something every day;
                                                  to gain wisdom, remove something every day.
                                                  -- Lao Tzu
                                                • Michael
                                                  In my current company, we use ScrumWorks Pro to track both Product Backlog, and Sprint Backlog. For ticketing, we use Bugzilla. Michael Abugow, CSM QA
                                                  Message 24 of 27 , Aug 26, 2010
                                                  • 0 Attachment
                                                    In my current company, we use ScrumWorks Pro to track both Product Backlog, and Sprint Backlog. For ticketing, we use Bugzilla.

                                                    Michael Abugow, CSM
                                                    QA Engineer and ScrumMaster
                                                    --- In scrumdevelopment@yahoogroups.com, Tim Bryan <tbryan@...> wrote:
                                                    >
                                                    > I am new to this group as well and excited about learning more about agile methodologies; in particular scrum. I am wondering what tools everyone is using to manage their scrum projects. I found Axosoft OnTime on the web and wondering if anyone has any comments about this product or others.
                                                    > Thanks
                                                    >
                                                    > Best Regards;
                                                    >
                                                    > Tim Bryan
                                                    > Vice President
                                                    > Senior Developer
                                                    > BT Systems
                                                    > Frankston, Texas
                                                    > Web: http://www.btsapps.com<http://www.btsapps.com/>
                                                    > The pursuit of happiness is the chase of a lifetime!
                                                    >
                                                  • Roy Morien
                                                    I would take issue (just a bit) with a couple of statements here: First, Be sure to resist the temptation to rewrite the system . Why? My experience is that
                                                    Message 25 of 27 , Aug 26, 2010
                                                    • 0 Attachment
                                                      I would take issue (just a bit) with a couple of statements here:
                                                       
                                                      First, "Be sure to resist the temptation to rewrite the system". Why? My experience is that it may well be a faster and better solution to rewrite the system than spend time fiddling around with existing code and trying to make it different, or better. I really do think reqriting the system is an option that should defnitiely be considered. Also, I recall that there was a limitation to the system written in VFP in the database total size. If this meant that VFP could no longer meet their purpose, then a rewrite was inevirable.
                                                       
                                                      Second, "it should be possible to migrate tables in groups, if the DB doesn't have foreign key references tying them all together.". This statement highlights my view of many years that having referential integrity rules structurally built into the database creates many problems; I recommend not doing it. One problem is exactly what has been stated here; foreign key references tying them all together. Go back to basics of Relational Databases; tables are associated logically by foreign key references. When you tie them together structurally you are essentially going back to the old network database style of having pointers and physical references, which always caused huge problems in schema modification. Also, tying tales together like that has significant restrictions. For example, what happens when you have multiple 'ties' between a table and many other tables, and, eg., the Delete RI rules vary from Restrict Delete to Cascade Delete to Null Delete depending on which table? Also, what about conditional rules, such as a conditional Cascade Delete that depends on which record you are deleting, and otherwise a Null delete for other records?   No, I say, do it in code! Maybe that code is in a Trigger (which then runs the risk of cascading trigers, which may be a problem), or do it in a hand-written function ... one way or the other the developers have control. Some may say that this is a problem in iteself, but I would dispute that.
                                                       
                                                      Just a couple of thoughts.
                                                       
                                                      Regards,
                                                      Roy Morien
                                                       

                                                      To: scrumdevelopment@yahoogroups.com
                                                      From: lists@...
                                                      Date: Thu, 26 Aug 2010 18:04:17 +0800
                                                      Subject: Re: [scrumdevelopment] Re: Cowboy Spaghetti coding

                                                       
                                                      John,

                                                      On 8/26/10 1:36 AM, mojavescout wrote:
                                                      > Thanks George! I have answered your questions below. I appreciate the help.
                                                      >
                                                      > John - MojaveScout
                                                      >
                                                      > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie<lists@...> wrote:
                                                      >>
                                                      >> Hi, Mojave Scout,
                                                      >>
                                                      >> It is a daunting task, indeed. But gradual refactoring of legacy code
                                                      >> to a better foundation for the future is, in my experience, possible.
                                                      >> Your migration task is orthogonal to Scrum.
                                                      >>
                                                      >> Take a look at the Strangler Pattern. Martin Fowler has a good writeup
                                                      >> on the web.
                                                      >>
                                                      >> On 8/25/10 12:13 AM, mojavescout wrote:
                                                      >>> Goals:
                                                      >>>
                                                      >>> Move FoxPro tables to SQL Server
                                                      >>
                                                      >> What language are you using for the code? Can it access both FoxPro and
                                                      >> SQL Server? Or are you changing implementation languages, too?
                                                      >
                                                      > John Wrote: No, staying with VFP for now, Java in future and using
                                                      > SQL Stored procedures. Looked at C Sharp and .Net but the capital
                                                      > required seemed outside budget as well as the expertise.

                                                      You're outside my language expertise, but it should be possible to
                                                      migrate tables in groups, if the DB doesn't have foreign key references
                                                      tying them all together.

                                                      >>> Create a means for multideveopers to code this application
                                                      >>>
                                                      >>> Challenges:
                                                      >>> Senior developer claims no usable code can be created in a single
                                                      >>> Sprint. Says it will take months to swim through this code.
                                                      >>
                                                      >> I suspect he's under-estimating.
                                                      >
                                                      > John Wrote: Might be

                                                      While I think it will take a long time to clean up the code, I'm quite
                                                      convinced it can be done incrementally. I suggest Martin Fowler's book,
                                                      Refactoring, and Michael Feathers' book Working Effectively With Legacy
                                                      code. Be sure to resist the temptation to rewrite the system, and just
                                                      slowly clean it up as you touch code.

                                                      >>> Other developer must be trained on logic and immersed in current code
                                                      >>> to assist.
                                                      >>
                                                      >> Trained? How about work with it, and have the original coder highly
                                                      >> available to answer questions and demonstrate things?
                                                      >
                                                      > John Wrote: Yes that is the plan. I was not exactly clear but they
                                                      > will develop features expected by Business Development in the same
                                                      > application together. This is a new version rollout we have been
                                                      > committed to and I will have both of them working on it. Both will
                                                      > sit in the same room and be sequestered. I have the CEOs consent on
                                                      > this as it will prolong the new version rollout.

                                                      They could surprise you. There is synergy with multiple people working
                                                      together. Once they get going, they could find some good ways of making
                                                      it happen faster. Just don't let them sacrifice quality, as that will
                                                      ultimately slow them down.

                                                      - George

                                                      --
                                                      ----------------------------------------------------------
                                                      * George Dinwiddie * http://blog.gdinwiddie.com
                                                      Software Development http://www.idiacomputing.com
                                                      Consultant and Coach http://www.agilemaryland.org
                                                      ----------------------------------------------------------


                                                    • Roy Morien
                                                      You may indeed, Ron.
                                                      Message 26 of 27 , Aug 26, 2010
                                                      • 0 Attachment
                                                        You may indeed, Ron.
                                                         
                                                        > To: scrumdevelopment@yahoogroups.com
                                                        > From: ronjeffries@...
                                                        > Date: Thu, 26 Aug 2010 08:27:06 -0400
                                                        > Subject: Re: [scrumdevelopment] Re: Cowboy Spaghetti coding
                                                        >
                                                        > Hello, Roy. On Thursday, August 26, 2010, at 1:45:35 AM, you
                                                        > wrote:
                                                        >
                                                        > > I have a couple of interesting little stories (at least, I think
                                                        > > they are interesting) about those 'standard programs' that I mentioned.
                                                        >
                                                        > Roy, there is a conversation going on on the XP list now that would
                                                        > benefit from these stories. May I repost your note there, please?
                                                        >
                                                        > Ron Jeffries
                                                        > www.XProgramming.com
                                                        > www.xprogramming.com/blog
                                                        > To gain knowledge, add something every day;
                                                        > to gain wisdom, remove something every day.
                                                        > -- Lao Tzu
                                                        >
                                                        >
                                                        >
                                                        > ------------------------------------
                                                        >
                                                        > To Post a message, send it to: scrumdevelopment@...
                                                        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                                        >
                                                        > <*> To visit your group on the web, go to:
                                                        > http://groups.yahoo.com/group/scrumdevelopment/
                                                        >
                                                        > <*> Your email settings:
                                                        > Individual Email | Traditional
                                                        >
                                                        > <*> To change settings online go to:
                                                        > http://groups.yahoo.com/group/scrumdevelopment/join
                                                        > (Yahoo! ID required)
                                                        >
                                                        > <*> To change settings via email:
                                                        > scrumdevelopment-digest@yahoogroups.com
                                                        > scrumdevelopment-fullfeatured@yahoogroups.com
                                                        >
                                                        > <*> To unsubscribe from this group, send an email to:
                                                        > scrumdevelopment-unsubscribe@yahoogroups.com
                                                        >
                                                        > <*> Your use of Yahoo! Groups is subject to:
                                                        > http://docs.yahoo.com/info/terms/
                                                        >
                                                      • George Dinwiddie
                                                        Hi, Roy, ... OK. :-) ... I think that rewrites, unless they can be accomplished in a couple of weeks, or so, are incredibly risky. They always turn out to be
                                                        Message 27 of 27 , Aug 27, 2010
                                                        • 0 Attachment
                                                          Hi, Roy,

                                                          On 8/27/10 10:29 AM, Roy Morien wrote:
                                                          > I would take issue (just a bit) with a couple of statements here:

                                                          OK. :-)

                                                          > First, "Be sure to resist the temptation to rewrite the system". Why? My
                                                          > experience is that it may well be a faster and better solution to
                                                          > rewrite the system than spend time fiddling around with existing code
                                                          > and trying to make it different, or better. I really do think reqriting
                                                          > the system is an option that should defnitiely be considered. Also, I
                                                          > recall that there was a limitation to the system written in VFP in the
                                                          > database total size. If this meant that VFP could no longer meet their
                                                          > purpose, then a rewrite was inevirable.

                                                          I think that rewrites, unless they can be accomplished in a couple of
                                                          weeks, or so, are incredibly risky. They always turn out to be harder
                                                          than expected, as there's always unknown rules hidden in the previous
                                                          system. Way too often, going for the total rewrite kills companies.
                                                          Look at Netscape for an example.

                                                          It may be harder and less fun, but refactoring the system into the one
                                                          you want, bit by bit, has always proved to be a prudent choice, in my
                                                          experience.

                                                          > Second, "it should be possible to migrate tables in groups, if the DB
                                                          > doesn't have foreign key references tying them all together.". This
                                                          > statement highlights my view of many years that having referential
                                                          > integrity rules structurally built into the database creates many
                                                          > problems; I recommend not doing it. One problem is exactly what has been
                                                          > stated here; foreign key references tying them all together. Go back to
                                                          > basics of Relational Databases; tables are associated logically by
                                                          > foreign key references. When you tie them together structurally you are
                                                          > essentially going back to the old network database style of having
                                                          > pointers and physical references, which always caused huge problems in
                                                          > schema modification. Also, tying tales together like that has
                                                          > significant restrictions. For example, what happens when you have
                                                          > multiple 'ties' between a table and many other tables, and, eg., the
                                                          > Delete RI rules vary from Restrict Delete to Cascade Delete to Null
                                                          > Delete depending on which table? Also, what about conditional rules,
                                                          > such as a conditional Cascade Delete that depends on which record you
                                                          > are deleting, and otherwise a Null delete for other records? No, I say,
                                                          > do it in code! Maybe that code is in a Trigger (which then runs the risk
                                                          > of cascading trigers, which may be a problem), or do it in a
                                                          > hand-written function ... one way or the other the developers have
                                                          > control. Some may say that this is a problem in iteself, but I would
                                                          > dispute that.

                                                          I'll buy that. In fact, I'm happy when referential integrity checks are
                                                          built into small clumps of tables, said clumps being somewhat
                                                          independent of other clumps.

                                                          All of these rules built into databases to prevent data corruption seem
                                                          to rarely avoid the problem of garbage data, in my opinion. Rather than
                                                          work to make errors impossible, I find it more productive to work to
                                                          make doing the right thing easy.

                                                          - George

                                                          --
                                                          ----------------------------------------------------------------------
                                                          * George Dinwiddie * http://blog.gdinwiddie.com
                                                          Software Development http://www.idiacomputing.com
                                                          Consultant and Coach http://www.agilemaryland.org
                                                          ----------------------------------------------------------------------
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.