• Man, you're on a roll with great topics and write-ups about those topics.

    In Jeff Attwood's article, he posted "what we do is craftsmanship, not engineering" and I have to take strong exception to that. A lot of folks practice what I call "crapmanship". 😉

    The mantra for many GUI programmers has become "If you have to write comments, your code isn't good enough" and then refuse to add even a simple header to explain the purpose of the class or even who wrote it and when. Crapmanship prevails and they've gotten real good at justifying it. Don't get me started on the use of Crapmanship tools like Hibernate and NHibernate... I love it when a GUI Developer justifies the performance problems of an "eager get" that has joins to 32 different tables with functions on the join criteria and also has the nerve to blame the performance problem on SQL Server. I also love the morons that designed the tables in such a fashion as to be a part of the reason the GUI Developer felt it necessary to do an "eager get".

    Shifting gears, let's also take a look at the Crapmanship that many writers of SQL practice whether they're GUI programmers or database programmers. Same problems occur there. No documentation, horribly formatted code, the use of all lower case or all upper case code, rampant use of RBAR, etc. I can't speak of programming technique in C# or Java, but if they practice the same Crapmanship there as what they do in T-SQL, the world is in big trouble.

    This editorial fits in with your last one... no one considers what will happen in the future even if they practice so called "best practices" because, IMHO, some of the best practices (like not including documentation in code) are wrong.

    Is code "experimental" in nature rather than "engineered"? I'd have to say it's certainly swung that way. No one really does any up-front planning at the code level anymore. No one says "Before we decide, can someone show us the impact on performance of these two different methods?" Nah... they say "here's what it should look like on the screen and what we want to see if you push this button." No one tells the developer "Look, dumbass, you can't use NHibernate here because it will crush performance."

    Getting back to people who write SQL... just go through this forum and look at the code that some folks offer as solutions to problems. It's quite indicative of what happens in the real world. Crappy to read and crappy performance.

    I strongly believe that code shouldn't actually be "engineered" because it stifles creativity and you may miss a wonderful new method of doing things if software design is draconian in nature. But I don't see much in the line of Craftmanship in this world of code. Not only is software engineering mostly dead, but so is the idea of Craftmanship in code because "good enough" will always be shippable in the eyes of management and in the minds of DILIGAF developers that simply want to get things off their plate or don't have the hair to say "No... and here's why".

    [font="Arial Black"]"In this order, make it work, make it fast, make it pretty... and it ain't done 'til it's pretty."[/font] --Jeff Moden, circa 1996

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