October 29, 2020 at 12:00 am
Comments posted to this topic are about the item Building Quality In
October 29, 2020 at 11:44 am
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
October 29, 2020 at 2:52 pm
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
Change is inevitable... Change for the better is not.
October 29, 2020 at 5:06 pm
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.
October 29, 2020 at 5:45 pm
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
I wonder, would the great Samuel Johnson have replaced that with "GIYF" now?
October 29, 2020 at 5:48 pm
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
I wonder, would the great Samuel Johnson have replaced that with "GIYF" now?
October 29, 2020 at 10:42 pm
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.
October 30, 2020 at 12:26 am
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
October 30, 2020 at 2:09 am
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
Change is inevitable... Change for the better is not.
October 30, 2020 at 7:35 am
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 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply