Post reply

Architecture Principles

  • December 21, 2009 at 8:21 pm

    #1095221

    Heh... Wright's house reminds me of the way that a lot of developers write code... guaranteed water in the basement. 😛

    and the foundation on which you build systems can change

    "You can change the wrapper but it's still the same great Ritz."

    There are certain fundamental "principles" to all great code... "touch" only the data that's absolutely necessary, execute only the code that needs to be executed, keep the code that needs to be executed on track (as little CPU time as possible).

    With the blazing speed of today's processors and databusses, a lot of that has been forgotten and bloatware prevails. Most people have forgotten the fundamental "principles" of great code and as clever as they seem, they've still built a house that has water running through the basement. 😉

    --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)

  • December 22, 2009 at 9:29 am

    #1095462

    Heh... Wright's house reminds me of the way that a lot of developers write code... guaranteed water in the basement. [Tongue]

    LOL, actually the water doesn't run through the basement, it runs alongside the house. There's a series of steps down from the living room to a landing next to the water.

    If I remember right, you could make a great parallel to this. The guy that commissioned the work I think ran short of money (like today's corporate cost cutting) and they cut a few corners on the construction (developers not having the tools or knowing how to use them) and ended up with some concrete issues later. I think there was also a lack of maintenance for some years after it was built until it was restored.

    It's an amazing piece of architecture, but like lots of software, it wasn't necessarily well executed.

  • January 8, 2010 at 2:26 am

    #1100751

    The Open-Closed principle is key on all levels of abstraction coupled with only doing as much as you need at the time. The number of times I have worked on systems that had "really cool" features yet missed essential features for the business and was not architected, designed nor implemented with change in mind.

    The other essential task is leaving a project in a state so that in can be picked up by anyone. This means documentation. To me documentation includes the following: requirements, analysis, designs, code, tests and much more besides. I don't restrict the format of documentation as in some cases a diagram might be all that you need to understand what it is trying to say or a small script might be enough to both document and execute deployment. Also, I also do not specify how much documentation (the old "as much you need but no more" subversion of an Einstein quotation applies here).

    With working freelance it is difficult to demand or enforce a set of principles but most people are reasonable and, if they see you want to make things better for everyone, will consider suggestions made.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • February 6, 2010 at 7:16 pm

    #1115125

    Jeff Moden (12/21/2009)

    There are certain fundamental "principles" to all great code... "touch" only the data that's absolutely necessary, execute only the code that needs to be executed, keep the code that needs to be executed on track (as little CPU time as possible).

    You missed out an important one here:do the sizing before you choose the platform. I've seen several projects crash and burn because this simple rule was forgotten, and I've shifted some platform requirement estimates by three orders of magnitude because the people who first looked at it didn't even try to estimate what would be needed. And there's another one that goes along with your "execute only the code that needs to be executed": write only the code that needs to be written (but write all of it).

    With the blazing speed of today's processors and databusses, a lot of that has been forgotten and bloatware prevails. Most people have forgotten the fundamental "principles" of great code and as clever as they seem, they've still built a house that has water running through the basement. 😉

    Maybe the prevalence of bloatware today means that we need another principal: provide only features that people will use?

    Tom

  • February 6, 2010 at 9:18 pm

    #1115139

    Heh... no, I didn't miss a thing when I said "execute only the code that needs to be executed." One of the guys at my old job decided it would be better to execute all "get" code no matter which screen was to be displayed so they would display faster. He called it an "aggressive get". Needless to say, it didn't work quite as he planned.

    I agree very much on the bloatware thing... seems like a lot of users are impressed by visual effects rather than speed or correct content. I went to a meeting on a new release of some internal software and people were greatly impressed with being able to move one window on the screen and the other window would move to the original window's position automatically with great fluidity. None of them noticed that the data the windows contained was incorrect.

    --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)

  • February 7, 2010 at 11:14 am

    #1115216

    I think a lot of the bloatware is that we keep thinking that adding more more thing appeals to a new person, rather than perhaps removing something else that might gain some advantages.

    Don't discount the visual effects, Jeff. The appearance is important to a lot of people, and I think can increase their rate of work.

    Or their rate of mistakes if the data is incorrect :w00t:

  • February 7, 2010 at 4:35 pm

    #1115271

    When I worked for McCann-Erikson they classified people into 4 segments analogous to the part of a printed advert. It was exactly the same thing as the Introvert/Extrovert Vs Verbalisers/Visualisers thing only McCann-Erikson named the quadrants Logo, Headline, Illustration and Body Copy.

    There are people who couldn't give a stuff about fancy floating boxes and pretty visual displays. Frankly a fast working green screen would be their idea of heaven. At the other end of the spectrum you have people who believe that life is unbearable without flashy transparent dialogue boxes and strange progress dials.

    Doesn't matter which camp you fall into, underneath the hood there still has to be boring old well written code if the app is to survive.

    LinkedIn Profile

Viewing 7 posts - 16 through 21 (of 21 total)

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