1. Home
  2. Categories
  3. Side Bar WTF
  4. We'll need to refactor this later

We'll need to refactor this later

  • C

    @DescentJS said:

    I agree with that in general, the catch I think would be if one of the requirements was forcing a design that was incredibly terrible.

    Is that possible? I know it's possible to produce something of beauty using utterly awful code, and elegantly code something terrible... but I couldn't see a requirement shaping a design in this way.

    (an inexperienced developer, useless architect or incompetant BA, then yes - I understand.)

    0
  • D

    @Cassidy said:

    @DescentJS said:

    I agree with that in general, the catch I think would be if one of the requirements was forcing a design that was incredibly terrible.

    Is that possible? I know it's possible to produce something of beauty using utterly awful code, and elegantly code something terrible... but I couldn't see a requirement shaping a design in this way.

    (an inexperienced developer, useless architect or incompetant BA, then yes - I understand.)

     

    Well, i'm thinking of situations such as the requirements are forcing you to use some really unfit for purpose language "because it's what our users know", or "every record accessed in the multi-trillion row database must be logged separately to 4 different audit tables regardless of what operation is being performed".

    0
  • C

    Mmmm... okay, I concede defeat on that one. I suppose I can give valid arguments against those decisions but... customer pays and all that.

    0
  • locallunatic

    @DescentJS said:

    @Cassidy said:

    @DescentJS said:

    I agree with that in general, the catch I think would be if one of the requirements was forcing a design that was incredibly terrible.

    Is that possible? I know it's possible to produce something of beauty using utterly awful code, and elegantly code something terrible... but I couldn't see a requirement shaping a design in this way.

    (an inexperienced developer, useless architect or incompetant BA, then yes - I understand.)

     

    Well, i'm thinking of situations such as the requirements are forcing you to use some really unfit for purpose language "because it's what our users know", or "every record accessed in the multi-trillion row database must be logged separately to 4 different audit tables regardless of what operation is being performed".

    It's so much easier than that, "put a submit button after every field on the form".  Yes I've had specs requiring that, but at least the customer accepted when I refused to follow that requirement of theirs.

    0
  • dhromed

    I have a client where their default knee-jerk response to any sort of decision-making about the functionalty and interaction is "Can you make it an option?"

    I can make everything an option, but that's not the point, is it?

    Luckily I was able to counter a comment of "the fonts seem different somehow..."  with "Your guy wrote the CSS which I did not touch, and there are about 15,000 text-rendering and antialias methods out there. Hell yes they look different."

    0
  • E

    @token_woman said:

    A discussion ensued, and he said that the reason we don't charge them for it is that the time we spend on it is avoidable - it is self-inflicted wastage of time, due to "getting the code wrong" that we "should have gotten right in the first place".

    Similar thing where I work now, unless a customer complains about it "If it ain't broke don't fix it". Thing is it even stretches as far as improvements sometimes, a few weeks back I tried to convince people I'd come up with a system to improve a weak point in an existing product. I said something along the lines of "Using this method we can get that 5% tolerance we need to get the <CUSTOMER> order and according to my projections perhaps even cut it down to 2.5%."

    I got told something along the lines of "We can't go making it better now because we already told them its perfect, fixing it would be admitting its not."

     

    0
  • C

    @EncoreSpod said:

    "If it ain't broke don't fix it".

    For anyone who says that to me, I offer to take them out rock-climbing with a rpse that-s sawn partly-through, on the grounds that if it ain't broke I won't fix it.

    Strangely, they never take me up on that offer.

    A better mantra is "if you don't fix it, it WILL break". Proactive being cheaper than reactive and all that.

    @EncoreSpod said:

    I got told something along the lines of "We can't go making it better now because we already lied to the customer, and this will expose our deceit."

    FTFY, but "managing expectations" and all that.  Don't like the outcome, but can't disagree that it's the safer choice given the circumstances.

    0
  • da_Doctah

    @EncoreSpod said:

    I got told something along the lines of "We can't go making it better now because we already told them its perfect, fixing it would be admitting its not."
     

    The only programming boss I ever had who had been a developer himself used to say (and I'm not entirely convinced he was joking) that "testing shows a lack of confidence in your work".

    Sometimes things work out just right.  He turned out not to have the temperament to manage people so he was demoted back to a developer.  Guess giving him the manager job was just a...er...test.

    0
  • C

    @da Doctah said:

    "testing shows a lack of confidence in your work".

    I think he was taking the piss. Hell, I hope so. Testing establishes confidence in the quality of your work - if anything, anyone frightened of testing would show a lack of confidence!

    @da Doctah said:

    Guess giving him the manager job was just a...er...test.

    Testing showed that... oh, hang on - that WAS the joke!

    0
Log in to reply