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.
is pronounced "ree-bar
" and is a "Modenism
" for R
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!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)