HN user
I agree very much with you that interruptions are death of productivity. Your suggestions for weekly rotations are great.
However, I argue that if the engineers are interrupted by QA issues, they will be motivated to find ways to not have those QA issues. In absence of that, we end up with the familiar “feature complete, let QA find bugs” situation.
SRE is an anti pattern that Google is unwilling to admit and is selling books on. Just like there should not be QA, release engineering, continuing engineering or DBA as separate departments/job titles, because these critical parts of software development should not be considered optional and thrown over the wall to take care of by someone with no stake in developing the product.
Wow first few top responses here reflect the upper-middle-class nerd myopia.
You don't understand what middle class is. Middle class is not a specific dollar figure. It's not owning a large TV. Middle class is when you don't have the set of anxieties that cloud your judgement and depress your day.
Middle class means you don't care if your paycheck gets delayed from Friday to Monday. Middle class is when you don't have to count how many times a week you go to the laundromat.
Sadly, middle class, as evidenced by these responses, also means that you don't see why other people would care if their paycheck gets delayed by a business day or two. It's no big deal, you are convinced. Yet, there's a woman that just started working, waiting for her first paycheck, which already had to be delayed due to starting date not aligning with payment schedules. And she has been planning to pay rent with this money, on the promised date. And yet, because some upper-middle-class manager with middle-class myopia forgot to submit everyone's timecards on time (as required by the similarly-myopic corporate policy), everyone's paychecks get delayed by a few days, including this woman's. Now she has to deal with missing paying rent. True story, in modern liberal bastion of Massachusetts.
All you have to do is understand why it's considerably more difficult for someone to improve their life, when starting from a much lower point, constantly being banged around by the ankles of the society.
It's the remnants of the late 90's early 2000's software development overengineering disease, so aptly captured in the mess that was J2EE.
Similar to "nobody got fired for buying IBM", the mindset was that "nobody got fired for building layers of abstraction just in case."
It's the culmination of the second system effect.[1] Without a pervasive unit testing culture, the big enterprise answer to "what if" is "let's add a point of flexibility here."
Obviously, people should be held responsible for building unnecessary abstraction layers like that. They waste time and are often wrongly abstracted, so when you do need to go in to refactor, you end up having to fight the pre-existing "what if" abstraction.
Atari basic in 1991 when I was 9 (remember simple FOR loops printing "trees"), BASIC with sprites on Yamaha MSX [1] consoles in 1993/1994, grew up on ZX Spectrum clones (Russian Hobbit [2]) since 1992 (including dabbling in Logo), GWBasic since 1993, QBasic a year later, Pascal since 1994 and dabbled in C in 1995. Clearly remember pointers sucking: having to figure out whether to pass in char * or char whether to stick an & in front of the string, etc.
ZX Spectrum was the shit though, as a kid. It had everything you wanted: BEEP command to make tones (so you could make music!) and user-definable 8x8 characters [3]. I remember sitting down with graph paper, drawing a grid of 8x8 spaces, outlining something neat like a helicopter, then tracing out the pixels. Then it was trivial to just "PRINT" your custom characters and make things move around.
1 - http://en.wikipedia.org/wiki/MSX 2 - http://www.interface1.net/zx/clones/hobbit.html 3 - http://www.worldofspectrum.org/ZXBasicManual/zxmanchap14.htm...