Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

Belated response....

Sorry - my box of crayons seems to be missing that colour ;-)

It's a sort of greeny pink :-)

Fault #1: all data was embedded in the code.

Of course that's not necessarily a fault in of itself. It's only a fault if it makes that data hard to change.

Fault #2: data that was logically similar was not consistantly grouped locally - it was usually strewn over many shell functions or even many modules.

Fault #3: while the absolutely most-changed data (multiple times per day) was locallised to only two logical locations, the next 4 top-most changed data types (every week through every couple of months) were not co-located in any sensical number of locations.

Fault #4: data that was changed entirely infrequently (every year or two) was more localised than the most frequently changed data.

That sounds like a lot of dodgy abstractions and duplication of responsibility to me. Time for some merciless refactoring.

As perrin said YANGI is all about avoiding doing stuff until you actually need it - not avoiding it once you need it.

Fault #5: it was shell script fer cryin' out loud. ;-) Seriously - shell script means "no local variables". Everything is always global. Which makes it very dangerous to use new variables as they may already be in use if they are common names, or they're very long if they aren't common names. Ok, that may be a bit exaggerated, but you get the idea. Imagine no "my", "our", or "local" keywords in perl, and then you have the concept.

There you might have me :-) Early architectural decisions like platform and development language are hard ones to change after the fact. If you're stuck with a language with little support for higher level abstraction you're potentially heading for a rewrite.

Of course there are strategies to help avoid this. For example:

  • Avoid developing in languages that will cripple you later on :-)
  • Address the problem early. I know when I've been in situations like this it's been obvious long before the political will was found that a move to another language was necessary.
  • Look for ways to move to another language incrementally while keeping things running. It can actually save time in the long term to add some code to the old system so you can decouple a few bits and change them incrementally.
At the time it was developed, long before I joined the company, the scope was incredibly small. So they did exactly what was needed at the time, no more. And it worked great. By the time I joined the team, it was already on the verge of bursting. But I didn't know that, so I kept using it.

Sounds like the classic Big Ball Of Mud. My sympathies.

After a couple of years at this, I gained enough experience to be able to see the larger design. (Note how I'm not claiming that it's the perfect design, just larger.) As I said above, the language, which may have been sufficient when we started, was part of the limitations of the existing system (imagine a complex data structure in shell - ewwww!). So a rewrite was necessary anyway.

Yeah, with a shell script you're pretty much stuffed :-)

That's the simplest way to get the long term unknowns accomplished, but not all of my management chain is enthused about paying for "possible future" enhancements when they get in the way of an upcoming shipment, despite the promise that changes required (whether before or after the upcoming shipment) will cost 50% to 300% more than if we spent an extra 10% now.

If you've not come across it already I've found the "Technical Debt" metaphor a really useful tool in helping management understand this sort of thing.

In reply to Re^5: On Quality by adrianh
in thread On Quality by Tanktalus

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    [Corion]: Whoops - more spam - I guess I'll have to collate a list and have them banned later today
    [Corion]: Maybe I should bring my Github credentials to $work some day, just to open issues for ;)

    How do I use this? | Other CB clients
    Other Users?
    Others chilling in the Monastery: (9)
    As of 2017-02-24 11:49 GMT
    Find Nodes?
      Voting Booth?
      Before electricity was invented, what was the Electric Eel called?

      Results (354 votes). Check out past polls.