DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 25

Thread: Making Time to Refactor

  1. #1
    Lori Piquet Guest

    Making Time to Refactor

    Is refactoring getting the proper attention at your organization? How are
    you balancing the need to do new development with the ever-present demands
    of old application maintenance? Have you ever tried refactoring old code in
    tandem with new development efforts?

    Lori Piquet
    Editor-in-chief
    DevX




  2. #2
    MarkN Guest

    Re: Making Time to Refactor


    For the main org I do work for ...
    >Is refactoring getting the proper attention at your organization?


    Not 100% because we are sort of separated from main group but ...
    If they aren't using Java - it is patch, patch, ..., rewrite. (Mostly because
    it is difficult to refactor in those languages/tools [This doesn't include
    MS.Net but it doesn't have refactoring tools/concepts built in]).

    If they are using Java, then they might be but I doubt it is getting the
    proper attention because the thought is 'Why didn't you do it right?'. The
    difficulty is that while there are examples of how to do OO with things like
    customer and invoice (which still isn't that easy) there aren't many that
    show how to do abstract concepts. It is difficult to think abstractly about
    abstract concepts.


    >How are
    >you balancing the need to do new development with the ever-present demands
    >of old application maintenance?


    Usually, as requirements change or bugs are found we do refactoring. The
    choice is making a bigger pile or straightening it out. And straightening
    it out is always worth the effort.

    >Have you ever tried refactoring old code in
    >tandem with new development efforts?


    Yes. It is a never ending process. Thankfully our tool has built in features
    that recognize this and really help out.

    Mark



  3. #3
    Keoki Guest

    Re: Making Time to Refactor


    "Lori Piquet" <piquet@devx.com> wrote:
    >Is refactoring getting the proper attention at your organization? How are
    >you balancing the need to do new development with the ever-present demands
    >of old application maintenance? Have you ever tried refactoring old code

    in
    >tandem with new development efforts?
    >
    >Lori Piquet
    >Editor-in-chief
    >DevX
    >
    >
    >


    We are not refactoring. We recently rolled out 5 years of development and
    are playing the game "I wish I had done it a different way." But no time
    or thought is being given to actually redoing it right. Instead we do quick
    and dirty fixes and are moving on to creating new things (sort of like Microsoft!).
    Quite frankly, I don't understand why. I just struggle to quickly fix the
    broken and create the new.


  4. #4
    MarkN Guest

    Re: Making Time to Refactor


    What toolset are you using? Some make it more difficult to do refactoring.
    When I read the article I was suprised the author was basing it on his SQL
    work. I'm refactoring SQL out my projects. Then again, maybe it is reductionism.


    Mark

  5. #5
    elliferg Guest

    Re: Making Time to Refactor


    "MarkN" <m@n.com> wrote:
    >
    >What toolset are you using? Some make it more difficult to do refactoring.
    > When I read the article I was suprised the author was basing it on his

    SQL
    >work. I'm refactoring SQL out my projects. Then again, maybe it is reductionism.
    >
    >
    >Mark


    We did refactoring here as part of our Y2K work in Cobol.
    We've also done in in c/s apps with VB. I wish we did more, but so often
    we can't get the buy-in from our business unit that it's worth the extra
    little bit of time that it would take so we have to sneak it in. They often
    wonder why we didn't do it right in the first place.




  6. #6
    MarkN Guest

    Re: Making Time to Refactor


    "elliferg" <selene73@charter.net> wrote:
    >
    >"MarkN" <m@n.com> wrote:
    >>
    >>What toolset are you using? Some make it more difficult to do refactoring.
    >> When I read the article I was suprised the author was basing it on his

    >SQL
    >>work. I'm refactoring SQL out my projects. Then again, maybe it is reductionism.
    >>
    >>
    >>Mark

    >
    >We did refactoring here as part of our Y2K work in Cobol.
    >We've also done in in c/s apps with VB. I wish we did more, but so often
    >we can't get the buy-in from our business unit that it's worth the extra
    >little bit of time that it would take so we have to sneak it in. They often
    >wonder why we didn't do it right in the first place.
    >
    >
    >


    Refactoring is much more difficult in these languages. Probably more so
    in COBOL. But obviously it can be done. It was such a pain in VB6 that
    I converted a major product to Java.

    >They often
    >wonder why we didn't do it right in the first place.


    Because specs change. Technology Changes. Techniques Changes. Skills are
    gained.

    I'm sure you tried to tell them.



  7. #7
    elliferg Guest

    Re: Making Time to Refactor


    >Refactoring is much more difficult in these languages. Probably more so
    >in COBOL. But obviously it can be done. It was such a pain in VB6 that
    >I converted a major product to Java.
    >


    agreed, but java is not the best development tool for every app for various
    reasons.
    >>They often
    >>wonder why we didn't do it right in the first place.

    >
    >Because specs change. Technology Changes. Techniques Changes. Skills

    are
    >gained.
    >
    >I'm sure you tried to tell them.
    >
    >


    Of course, but we're all over-paid, spoiled, computer geeks.

  8. #8
    MarkN Guest

    Re: Making Time to Refactor


    "elliferg" <selene73@charter.net> wrote:
    >
    >>Refactoring is much more difficult in these languages. Probably more so
    >>in COBOL. But obviously it can be done. It was such a pain in VB6 that
    >>I converted a major product to Java.
    >>

    >
    >agreed, but java is not the best development tool for every app for various
    >reasons.


    True. Didn't say it was. But I haven't found an app done in VB that couldn't
    be done in Java. And work just as well. Replace Java with C# if you want
    (although VS.Net doesn't currently seem to have refactoring tools built in).
    And as for COBOL, well, I've done enough of it to know alot of the crazy
    stuff done with it could be done better with an OO language.



  9. #9
    Steve Guest

    Re: Making Time to Refactor


    "MarkN" <m@n.com> wrote:
    >
    >"elliferg" <selene73@charter.net> wrote:
    >>
    >>>Refactoring is much more difficult in these languages. Probably more

    so
    >>>in COBOL. But obviously it can be done. It was such a pain in VB6 that
    >>>I converted a major product to Java.
    >>>

    >>
    >>agreed, but java is not the best development tool for every app for various
    >>reasons.

    >
    >True. Didn't say it was. But I haven't found an app done in VB that couldn't
    >be done in Java. And work just as well. Replace Java with C# if you want
    >(although VS.Net doesn't currently seem to have refactoring tools built

    in).

    Well I don't think there is an application written in any language that can't
    be done in any other language. Prior to JDK 1.4, Java suffered greatly in
    the "look & feel" department when it came to looking and feeling like a Windows
    application. Sure, with enough effort, you could/can get it close, but that's
    a bunch of extra work & $$. We can debate the importance of look and feel
    for an application, but IMO a good part of good software design is to re-use
    the existing knowledge of your client. That applies to business rules, as
    well as how the user interacts with your software. (An application that presents
    rich text to be viewed and edited by a user should look and feel like the
    word processor that the user uses.)

    As for re-factoring VB code, I can't say I've had any great difficulty doing
    it, provided you design the code correctly right off the bat. There are troubling
    areas within VB such as the need to copy and paste a heck of a lot without
    overloading and inheritance. Collection containers & recordset wrappers are
    a prime example. But I'd consider a bigger threat to be bad design. VB is
    can be a horrible tool for inexperienced developers, and evolving prototypes
    are pretty common-place. As for tools? I rarely use tools. I wish I was a
    spoiled, over-paid developer that I could afford to investigate and play
    with different tools, but my managers seem to think getting features and
    fixes in fast is more important.

    Steve.
    T-A-S-M! T-A-S-M!

    > And as for COBOL, well, I've done enough of it to know alot of the crazy
    >stuff done with it could be done better with an OO language.
    >



  10. #10
    MarkN Guest

    Re: Making Time to Refactor


    >Well I don't think there is an application written in any language that can't
    >be done in any other language.

    Maybe not, but it can be right next to impossible.

    Prior to JDK 1.4, Java suffered greatly in
    >the "look & feel" department when it came to looking and feeling like a

    Windows
    >application. Sure, with enough effort, you could/can get it close, but that's
    >a bunch of extra work & $$. We can debate the importance of look and feel
    >for an application, but IMO a good part of good software design is to re-use
    >the existing knowledge of your client. That applies to business rules, as
    >well as how the user interacts with your software. (An application that

    presents
    >rich text to be viewed and edited by a user should look and feel like the
    >word processor that the user uses.)


    I won't argue with you on this. No point, because your mind is made up.
    I will just say I don't agree and from my experience, most users can't tell
    the diff. And I wasn't trying to sell Java to anyone here. If you don't
    like it, don't use it. Use .Net. Just means more opportunities for me.


    >As for re-factoring VB code, I can't say I've had any great difficulty doing
    >it, provided you design the code correctly right off the bat. There are

    troubling
    >areas within VB such as the need to copy and paste a heck of a lot without
    >overloading and inheritance. Collection containers & recordset wrappers

    are
    >a prime example. But I'd consider a bigger threat to be bad design. VB is
    >can be a horrible tool for inexperienced developers, and evolving prototypes
    >are pretty common-place. As for tools? I rarely use tools. I wish I was

    a
    >spoiled, over-paid developer that I could afford to investigate and play
    >with different tools, but my managers seem to think getting features and
    >fixes in fast is more important.


    Count yourself lucky that you are able to 'refactor' your VB code. The more
    complicated the code, the more complicated the refactoring in VB. It can
    be done, but it is easier in other languages. I have used quite a few and
    I'm speaking from experience. And VB is the language I have the most experience
    in by far. Once experienced developers experience tools like Java and [cringe]
    C#, VB will become a horrible tool for them.

    As for 'playing' with tools, it is too bad you aren't allowed to learn anything
    new. I wasn't suggesting you play. But it is part of our job to learn and
    experience and grow. Technology changes fast. Some things are improvements
    and some are not. How will one know? Many times the new tools will actually
    make the job easier and thus help getting features and fixes in fast. And
    that is what I was talking about. There are many things we developers spend
    repeat time on - "monkey code" and new tools help eliminate this. I'm sorry
    you can't see this. If you want to keep on doing it the same old way, fine.
    I'm not satisfied with VB and that is why I seldom use it anymore. It was
    a fine pen knife, but makes a horrible sword. I'm not satisfied with Java
    either, but until something fills its shoes I will keep using it.

    Too bad the importance is placed on getting it done instead of done right.


    Mark




  11. #11
    Steve Guest

    Re: Making Time to Refactor


    Rofl... I work at a company with a group of Java developers that sound just
    like you. :P Infortunately with all of these cool tools and new features
    that are coming out all of the time for Java, they never seem to get anything
    actually *done*. I don't hold anything against Java, It's because of development
    performance like this, (Yeah, yeah, they're probably just incompetent, and
    you get your stuff done perfectly on-time and on-budget... I'll just save
    you the time to bother typing that statement out:} ) my managers are against
    looking at Java, or anything "new" for that matter. I've been pressing to
    get them to consider porting our project over to .NET over Java mainly because
    of the Interop functionality that will allow us to evolve the product over
    to C# while still showing progress. Utter the word "re-write" in this office
    and a hundred eyes will pierce your soul.

    IMO, good design will overcome any challenges encountered in a language,
    maily because your goal is to avoid weak areas in the language. VB has more
    than it's fair share of weaknesses, but it has many strengths over Java.
    (especially 2 years ago) Now with .NET, there is no way I am staying with
    VB.NET. VB's greatest strength was it's IDE and mechanism for working with
    Forms and Controls, and hiding much of the nitty-gritty. Now with .NET, all
    languages share the IDE capabilities, and VB has to get a bit dirtier. Mainly
    with the addition of overloading and inheritence, their decision to add keywords
    for this functionality, switching to the assembly model, and other general
    changes to the language made me think "Well, what's the point?" I attribute
    the general attitude take by developers that switch to Java (or other languages,
    Java just being one of the newer "buzz" ones) is it gives them an opportunity
    to take a fresh look at how they design and approach problem areas.

    C# may just be what you're looking for over Java, unless multi-platform is
    your immediate need. Though it wouldn't surprise me if you believe that something
    that fills Java's shoes could *never* come from MS. Then again, you are
    sitting in a ".NET" discussion group...

    "MarkN" <m@n.com> wrote:
    >
    >>Well I don't think there is an application written in any language that

    can't
    >>be done in any other language.

    >Maybe not, but it can be right next to impossible.
    >
    >Prior to JDK 1.4, Java suffered greatly in
    >>the "look & feel" department when it came to looking and feeling like a

    >Windows
    >>application. Sure, with enough effort, you could/can get it close, but

    that's
    >>a bunch of extra work & $$. We can debate the importance of look and feel
    >>for an application, but IMO a good part of good software design is to re-use
    >>the existing knowledge of your client. That applies to business rules,

    as
    >>well as how the user interacts with your software. (An application that

    >presents
    >>rich text to be viewed and edited by a user should look and feel like the
    >>word processor that the user uses.)

    >
    >I won't argue with you on this. No point, because your mind is made up.
    > I will just say I don't agree and from my experience, most users can't

    tell
    >the diff. And I wasn't trying to sell Java to anyone here. If you don't
    >like it, don't use it. Use .Net. Just means more opportunities for me.
    >
    >
    >>As for re-factoring VB code, I can't say I've had any great difficulty

    doing
    >>it, provided you design the code correctly right off the bat. There are

    >troubling
    >>areas within VB such as the need to copy and paste a heck of a lot without
    >>overloading and inheritance. Collection containers & recordset wrappers

    >are
    >>a prime example. But I'd consider a bigger threat to be bad design. VB

    is
    >>can be a horrible tool for inexperienced developers, and evolving prototypes
    >>are pretty common-place. As for tools? I rarely use tools. I wish I was

    >a
    >>spoiled, over-paid developer that I could afford to investigate and play
    >>with different tools, but my managers seem to think getting features and
    >>fixes in fast is more important.

    >
    >Count yourself lucky that you are able to 'refactor' your VB code. The

    more
    >complicated the code, the more complicated the refactoring in VB. It can
    >be done, but it is easier in other languages. I have used quite a few and
    >I'm speaking from experience. And VB is the language I have the most experience
    >in by far. Once experienced developers experience tools like Java and [cringe]
    >C#, VB will become a horrible tool for them.
    >
    >As for 'playing' with tools, it is too bad you aren't allowed to learn anything
    >new. I wasn't suggesting you play. But it is part of our job to learn

    and
    >experience and grow. Technology changes fast. Some things are improvements
    >and some are not. How will one know? Many times the new tools will actually
    >make the job easier and thus help getting features and fixes in fast. And
    >that is what I was talking about. There are many things we developers spend
    >repeat time on - "monkey code" and new tools help eliminate this. I'm sorry
    >you can't see this. If you want to keep on doing it the same old way, fine.
    > I'm not satisfied with VB and that is why I seldom use it anymore. It

    was
    >a fine pen knife, but makes a horrible sword. I'm not satisfied with Java
    >either, but until something fills its shoes I will keep using it.
    >
    >Too bad the importance is placed on getting it done instead of done right.
    >
    >
    >Mark
    >
    >
    >



  12. #12
    MarkN Guest

    Re: Making Time to Refactor


    Too bad your Java-ers can't make better use of it. It probably has more to
    do with OO and less Java (Oh, I see you already know that). We are doing
    fine with it. Trust me, try to do good OO/distributed programming with C#
    and you will have the same problem.

    As for C#, it is really nothing new (I've used it too). Java still has things
    it doesn't and it has some features Java doesn't. The biggest issue is,
    yes, I can only target Windows with MS.Net. I have nothing against MS and
    I continue to use their tools. But lock in is bad. And anything done to
    minimize that should be done.

    "good design will overcome any challenges encountered in a language"

    Ok. If you think so. Unfortunately the design is usually dictated by the
    pre-chosen tool. It may overcome some but not that many. How many languages
    and platforms have you programmed on/with? I've done more than enough to
    know. I can have stateless, transaction, server-side, pooled connection,
    domain objects in Java and turn around and use them on the client (no application
    server ie COM+) without modifying a line of code. Can't do that in VB or
    .Net.

    As for languages in .Net - they are basically the same only with different
    syntax. And do you know or have heard of anyone using anything but VB.Net
    and C#? Not me, not anywhere.

    And this is not a .Net discussion group - it is Design.Architecture. Which
    most MSers seldom seem to frequent.

    If you always plan to use Windows, your idea of slowly moving to C# is a
    good one. Converting isn't a good idea. And a major isn't either. It will
    take you awhile to really good use of OO in .Net


    Mark

  13. #13
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Making Time to Refactor

    "Steve" <rai_34@hotmail.com> wrote in message <news:3d08cc3c$1@10.1.10.29>...

    > Rofl... I work at a company with a group of Java developers that sound just
    > like you. :P Infortunately with all of these cool tools and new features
    > that are coming out all of the time for Java, they never seem to get anything
    > actually *done*. I don't hold anything against Java, It's because of development
    > performance like this, (Yeah, yeah, they're probably just incompetent, and
    > you get your stuff done perfectly on-time and on-budget... I'll just save


    Well, all too often it seems any time and effort saved by using a cool
    new tool is overwhelmed by the time and effort required to evaluate it
    and learn to use it effectively. Unfortunately, any payoff might not
    show up until everyone's using it for every project...

    > you the time to bother typing that statement out:} ) my managers are against
    > looking at Java, or anything "new" for that matter. I've been pressing to
    > get them to consider porting our project over to .NET over Java mainly because
    > of the Interop functionality that will allow us to evolve the product over
    > to C# while still showing progress. Utter the word "re-write" in this office
    > and a hundred eyes will pierce your soul.


    So what language are you using now? C# isn't C or C++, and B# isn't VB.
    Unless you're migrating to COBOL.NET or Fortran.NET from OO COBOL or
    "Visual" Fortran, you *are* in fact facing a "re-write".

    > IMO, good design will overcome any challenges encountered in a language,


    Even APL? Have you developed a scalable n-tier "enterprise" application
    solely in Forth lately? =)

    > maily because your goal is to avoid weak areas in the language. VB has more
    > than it's fair share of weaknesses, but it has many strengths over Java.


    Resource management, anyone?

    > (especially 2 years ago) Now with .NET, there is no way I am staying with
    > VB.NET. VB's greatest strength was it's IDE and mechanism for working with
    > Forms and Controls, and hiding much of the nitty-gritty. Now with .NET, all
    > languages share the IDE capabilities, and VB has to get a bit dirtier. Mainly
    > with the addition of overloading and inheritence, their decision to add keywords
    > for this functionality, switching to the assembly model, and other general
    > changes to the language made me think "Well, what's the point?" I attribute
    > the general attitude take by developers that switch to Java (or other languages,
    > Java just being one of the newer "buzz" ones) is it gives them an opportunity
    > to take a fresh look at how they design and approach problem areas.


    I thought it was primarily a matter of viewing the result of something
    like this:

    SELECT helpwanted.language, Count(Distinct helpwanted.ad) As adcount
    FROM dice.helpwanted
    GROUP BY helpwanted.language
    ORDER BY Count(helpwanted.ad) Desc

    After all, what's stopping anyone from revisiting their current "best
    practices" in their current tool(s)? Surely even developers are capable
    of changing their minds based on hindsight without having to do a
    DELETE FROM skillset !

    > C# may just be what you're looking for over Java, unless multi-platform is
    > your immediate need. Though it wouldn't surprise me if you believe that something
    > that fills Java's shoes could *never* come from MS. Then again, you are
    > sitting in a ".NET" discussion group...


    When was "design.architecture" aliased to "dotnet.design.architecture"?

    --
    Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  14. #14
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Making Time to Refactor

    "MarkN" <m@n.com> wrote in message <news:3d04addb@10.1.10.29>...

    > "elliferg" <selene73@charter.net> wrote:
    > >
    > >>Refactoring is much more difficult in these languages. Probably more so
    > >>in COBOL. But obviously it can be done. It was such a pain in VB6 that
    > >>I converted a major product to Java.


    Why? The transformations listed in _Refactoring_ apply to VB Classic,
    perhaps with the exception of converting delegation to inheritance.
    Or was it due to the lack (AFAIK) of a refactoring browser for VB? The
    incompatible add-in models for VB4, 5, and 6 did the third-party add-in
    market an awful lot of damage. Oh well, the baby has already drowned
    in the sewer under all that bathwater...

    > >agreed, but java is not the best development tool for every app for various
    > >reasons.

    >
    > True. Didn't say it was. But I haven't found an app done in VB that couldn't
    > be done in Java. And work just as well.


    What kind of apps are you talking about here?

    > Replace Java with C# if you want
    > (although VS.Net doesn't currently seem to have refactoring tools built in).
    > And as for COBOL, well, I've done enough of it to know alot of the crazy
    > stuff done with it could be done better with an OO language.


    Object Oriented COBOL: Believe It... Or Else!

    URL:http://infogoal.com/cbd/cbdobj.htm

    --
    Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  15. #15
    MarkN Guest

    Re: Making Time to Refactor


    "Well, all too often it seems any time and effort saved by using a cool
    new tool is overwhelmed by the time and effort required to evaluate it
    and learn to use it effectively. Unfortunately, any payoff might not
    show up until everyone's using it for every project..."

    That is why not everyone is cut out for this. Sure, there are a lot people
    who can program. But there aren't that many who can effectively and objectively
    evaluate tools and techniques, cutting through the BS, and determine their
    actual value and usage. Sometimes even they will be wrong. But many times
    the up front work will be worth it in the long run. When's the last time
    you coded in Assembly? COBOL? Fortran?

    BTW, there are just as few who are architectually minded too.

    Unfortunately most manager types think that good programmers can perform
    these other tasks. Which is why your statement rings true. Case in point
    - this thread.

    Mark


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center