Five Minute Refactoring

  • Comments posted to this topic are about the item Five Minute Refactoring

  • While I agree with the concept, I don't think this would work in reality. I have seen a lot of arguments where one side is arguing for the solution they "like" more, rather than what is best. They prefer that one because it is typically the what they are used to doing, easiest, or quickest to build, rather than the best.

    If we are debating whether it is best to include a column in an index or not, something like this may work fine. But I believe there are many more examples of people arguing the lazy way versus the right way.

    In my opinion, the exception would be when this method works, rather than the other way around.

    Dave

  • I don't argue with people about things in code. I let the code do the talking. If they come up with better code (performs better, more scalable, easier to read, easier to maintain, all factor in), then so be it. The code speaks!

    For arguments about supposed best practices, I can usually come up with code for that, as well.

    When people are trying to justify their junk code based on a supposed limited number of rows, that's when I drop the Company Standards that I wrote in their lap and flip it open to the "code reuse" section.

    For design decisions, I can also present a code-case about 90% of the time.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I wonder if the coding world doesn't need a paradigm shift from pursuing correctness to pursuing excellence. Those are two very different things.

    Pursuing correctness often devolves into "The Gospel According to Some Guy With a Blog (or Book)".

    Pursuing excellence means that while I may not use the "best" solution at any given point in time, I strive to code well and am never afraid to look at previous work and say, "I can do that better." It also means that as time passes and circumstances, technology and skills evolve I can honestly evaluate how - and even whether - to re-work my previous efforts according to the new reality.

    Jeff sort of touched on it with "letting the code speak." He has well thought-out and tested code, but leaves the door open should someone come up with demonstrable improvements.

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

  • I tend to look at an approach to a pronblem with a few questions in mind (in no particular order of consideration or of importance):

    a) how likely is the aproach to deliver software that meets the requirements (and has it been determined which parts of the requirements it will meet in an acceptable timescale for an affordable spend)?

    b) how easy will the approach make it to start meaningful testing on components when not much of the software is available?

    c) are the interfaces between major components of the proposed solution going to be narrow and simple, or will they be broad and complex?

    d) how much testing will ne needed and how much rework is likely (c above is an essential prliminary to answering this question).

    e) how much can be re-used in other projects

    f) how much work is it

    g) what are the likely support and maintenance costs

    Most of these questions will take rather more than 5 minutes discussion to answer, unless the requirement is for something that's been done many times and has become a standard hadle-churning job or perhaps if the requirement is very simple and clear and doesn't require anything other than very obvious coding.

    Frankly, I think the sugested five minute rule is nonsense, and can come only from someone who has been involved neither in software development with a serious research element nor in any development of something with a nontrivially complex requirement. One of the biggest and most comment management faults is to build plans with insufficient time for design, and for getting to understand the requirements, and for determining how adequate testing will be achieved. Many design discussions, discussions of testing methods, and discussions of interpretation/clarification of requirements need far longer than five minutes. One important point is that it will very often require more than 5 minutes (a lot more than 5 minutes) to get a reasonable guess as to which approach will be the easiest to implement

    Dogmatic arguments about methods based on personal preference/prejudice are of course a different kettle of fish; they shouldn't happen at all. A five minute rule is unacceptable there too - a 30 second rule might be acceptable but a 10 second rule would be better.

    Tom

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply