Quintessential Or Elegant

  • Comments posted to this topic are about the item Quintessential Or Elegant

  • I've worked with developers that over-engineer a solution just because they can. Excellent article!

  • Sometimes (always?) it just comes down to time and money. I can give it to you quick and dirty today or elegant tomorrow. If I go elegant then you will be able to maintain it next year. But there won't be a next year if I don't give it to you today. So quick and dirty it is.

  • Iwas Bornready (2/2/2015)


    Sometimes (always?) it just comes down to time and money. I can give it to you quick and dirty today or elegant tomorrow. If I go elegant then you will be able to maintain it next year. But there won't be a next year if I don't give it to you today. So quick and dirty it is.

    +1

  • I love management studio. It has been one of my favorite tools for a long time now. That said there are some downsides. The fact that SSMS makes a clustered primary key of some column when you click the key has lead to the common belief that it must always be that way. It's quick and dirty and the majority of the time turns out to be the right thing to do. Not always.

    We look for elegant solutions not so much for the purity of the code or the ideal coding to a particular problem but because the elegant solution typically turns out to be what you were talking about. No rust, bust, or dust.

    I have been working on a new tool It does a thankless task quickly and easily. I had coded in a tricky bit and got one of the controls to do something that was thought not to be possible. It's damn cool but is causing a problem and has backed the tool into violating one of my own design principles. Today I'm in the act of ripping out cool in favor of stable, reliable, and simple to train. The tool is still cool but in this case cool means that it does what it says that it does without the need for tricky crap.

    ATBCharles Kincaid

  • One of the primary tenets of my former team was supportability of the code, as there was no guarantee of code ownership six months+ down the line. Not only that, it is much easier to come back to support a project you do own after working on several others when you don't have to decode hip and cool code antics to remember what is going on.

    -=Janrith

  • It is easy to be simplistic and create simplistic solutions .

    It is harder to create a simple solution.

    The worst case was a 1600+ line script (including very cryptic comments) that only had the most most simplistic of statements, each 'where' clause never had more than 3 clauses. With a simply change in the schema, the use of case statements and a function, it could have been reduced to 5 inserts and 1 update. The usual politics, too many entrenched staff kept the old system in place.

    Strangely it was that team that got downsized first.

  • Sqlraider (2/2/2015)


    Iwas Bornready (2/2/2015)


    Sometimes (always?) it just comes down to time and money. I can give it to you quick and dirty today or elegant tomorrow. If I go elegant then you will be able to maintain it next year. But there won't be a next year if I don't give it to you today. So quick and dirty it is.

    +1

    +2

    I think there will always be cases where it's necessary to put a patch on something quickly, sometimes very quickly, and then go back and deal with the problem again properly. It's just making sure that you do go back and deal with it later. I've given people what they want in an hour in that hour. It's taken ten minutes to run but they've been happy because it's fixed their immediate need. A few days later I've given them another solution to the same problem that runs in five seconds and they've been doing back-flips because it then makes their day to day lives easier.


    On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    —Charles Babbage, Passages from the Life of a Philosopher

    How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537

  • Maximum effectiveness in minimum effort.....simplest.....

    If you look at well designed well implemented code it looks simple. You'd wonder why it took so long to deliver.

    If you try and develop well designed, well implemented code you'd sweat blood and tears refining it to the point where it looked easy to develop!

    Getting to the point where you make things look easy requires hard work.

  • David.Poole (2/4/2015)


    Maximum effectiveness in minimum effort.....simplest.....

    If you look at well designed well implemented code it looks simple. You'd wonder why it took so long to deliver.

    If you try and develop well designed, well implemented code you'd sweat blood and tears refining it to the point where it looked easy to develop!

    Getting to the point where you make things look easy requires hard work.

    So true.

    Gaz

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

  • Sometimes the rush to deliver something creates a maelstrom that ends up with poor code that is delivered at the same time or later than if it was done in a more planned, constructive manner.

    Gaz

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

Viewing 11 posts - 1 through 10 (of 10 total)

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