Building Quality In

  • Comments posted to this topic are about the item Building Quality In

  • Nicely put, Steve.

    I like to think of it as craftsmanship. I think we all want to do a "good job". I admit I'm a bit of a perfectionist, wanting to get everything just right so no one has to follow behind me to "fix" things I did wrong, didn't do or didn't know to do. I've also realized that despite these days of Covid-19 lockdowns the speed of business demands has not slowed down, so I often have to adopt the 80-20 rule.

    In this case, that's doing the 80% perfect and hopefully ensuring that the other 20% isn't going to be the problem I fear it may be.

     

    Richard

  • From the article:


    However, that should be a learning and teaching moment. We don't expect continuous quality issues, certainly not of the same type. A big part of the DevOps movement, and other modern software development methodologies is learning from our mistakes. Getting better. Improving the quality of our software.

    Don't just get work done. Don't just close tickets or move a sticky note. Learn to do better each time you make a mistake. Learn to write better code or implement better processes. Learn to build in quality.

    This is one of the reasons why I hate what DevOps seems to be defined as, especially when they talk about "developing fast" and "continuous integration" and "continuous deployment" and "automation".  All of that is good but the focus always seems to be on speed rather than quality, which should include questions like does it function correctly (meets or exceeds requirements), is it intuitive to the user and easy to use, does it run quickly, does it run efficiently, is it scalable, and is it maintainable (code formatting, comments, revision history, etc).

    In other words, "Make it work, make it fast, make it pretty... and it's not done 'til it's pretty".

    In a whole lot of cases, people just want to "get things off their plate", especially since the company doesn't encourage anything other than "we have a schedule to meet".  There's little to encourage people to take the time to discover a better way of doing things that won't require rework downstream and rework can cost not only a half-dozen times more expense to the company but it has "hidden" costs.  If the need for the rework is found by the customer, it's another mark against the company that actually may cause a customer to go somewhere else or at least result in bad referrals that will keep new customers from coming on board.

    Of course, there are also folks that think they shouldn't take any time to learn anything better unless it's on company and/or the company pays for their "education".  I think this industry is one of the very few that has so many with that type of DILIGAF attitude.

    --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".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I worked in QA at one of the BUNCH companies (Borroughs, Univac, NCR, CDC, and Honeywell) in the 70's to mid 80's. Engineering would say "We met our  deadline." and throw it over the wall to QA. Quite a lot, QA would have to reject the hardware or software because it was not ready for prime time.

    As a developer, I want to get it right the first time. Why? Because I don't want to do it a second time and I take pride in my work and craftsmanship. This is a book about Quality, Robert Pirsig's Zen and the Art of Motorcycle Maintenance.

  • Ralph Hightower wrote:

    I worked in QA at one of the BUNCH companies (Borroughs, Univac, NCR, CDC, and Honeywell) in the 70's to mid 80's. Engineering would say "We met our  deadline." and throw it over the wall to QA. Quite a lot, QA would have to reject the hardware or software because it was not ready for prime time.

    As a developer, I want to get it right the first time. Why? Because I don't want to do it a second time and I take pride in my work and craftsmanship. This is a book about Quality, Robert Pirsig's Zen and the Art of Motorcycle Maintenance.

    Should be compulsory reading for everyone! I read that, aged about 20, shortly after entering the world of work, I honestly can say it changed my outlook on things more than any other single thing.  I started out in manufacturing/production, and switched to IT about 20 years ago, the philosophy still applies.

    "Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. When we enquire into any subject, the first thing we have to do is to know what books have treated of it. This leads us to look at catalogues, and at the backs of books in libraries."
    — Samuel Johnson

  • Jeff Moden wrote:

    In other words, "Make it work, make it fast, make it pretty... and it's not done 'til it's pretty".

    Couldn't help be reminded of the old saying: "You can have it done well, you can have it done fast, you can have it done politely..... Choose two" 🙂

    "Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. When we enquire into any subject, the first thing we have to do is to know what books have treated of it. This leads us to look at catalogues, and at the backs of books in libraries."
    — Samuel Johnson

  • Quality is often pushed aside for time constraint.  The trade-off is "good enough."

    Often mgmt will take the stance of "good enough" even though the quality code that "could have been written" was not allowed to be written due to time-to-production.

    I certainly agree that quality should not be passed off; but all too often it is merely passed off to the next iteration of product evolution - to the same team.  It's frustrating to no end.

  • Very good, Steve! I've written my share of bad code. I try to learn from my mistakes when I realize them. I hope to continue to learn and impress myself, especially when I make a mistake. The hard part is not being too embarrassed by it. I do struggle with that, rather than look at it as an opportunity to learn. That approach is coming, slowly.

    Rod

  • david.edwards 76768 wrote:

    Jeff Moden wrote:

    In other words, "Make it work, make it fast, make it pretty... and it's not done 'til it's pretty".

    Couldn't help be reminded of the old saying: "You can have it done well, you can have it done fast, you can have it done politely..... Choose two" 🙂

    Whenever someone tells me that, I remind them that there's really only 1 choice... always do it well and then be amazed that the other two followed.

    We did that at one company I worked at and the results were remarkable.  Yes... it took slightly longer than the old way but only until people got the hang of the new process of "don't move it 'til you're positive it's right (works, is fast, and it's "pretty"), schedule be damned".

    It was totally the opposite of what most folks expected would happen, especially during the first several months.  A little more care and time up front caused throughput to start increasing because we had eliminated a serious amount of rework and seriously reduced the time it took to research what needed to be done for requested changes and additional/new functionality.  It was all due to simply  spending the little extra time to do it all right the first time.  And, even more totally unexpected by all except those of us that had proposed it all, it was self perpetuating and self-fueling.  The more time we saved on rework and research time, the more time we had to spend up front on doing it right up front which further reduced rework and research time, wash, rinse, repeat.

    After a little bit more than a year, we got to the point of almost zero defects and, because of the high quality "pretty" part of the code, it took less and less time to do the research to fix them as it also did with adding new features.

     

    --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".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I think not passing quality issues on to others is more than just learning from our mistakes though. It's also about actually doing something about them in our day-to-day work, as opposed to "If it's not broken, don't fix it".

    It doesn't help anyone if we've learned how to fix things, if we never put it in practice.

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

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