"Defects occurring in the boot or test phase must be corrected before the build is "released" for stress testing"
Currently having issues with this at works. Teams are pressured by their PM to release at certain time, and breaking thr pipleline and sending back bad code creates you lots of enemies from top to bottom.
Sometimes you just know the project is doomed by looking at how the organisation handles failure.
> Currently having issues with this at works. Teams are pressured by their PM to release at certain time, and breaking thr pipleline and sending back bad code creates you lots of enemies from top to bottom.
I really had to think deeply to actually "get" your point because my experience differs a lot:
Recently I reimplemented some convoluted feature, which is somewhat critical for some business processes. The tester found a (surprising) bug in my implementation - I indeed did something subtly wrong. After this, a next round of testing came - it looks like another class of errors was found.
Honestly, I am very thankful for these errors that were found. The test cases that the testers provided help me to make my code much better and robust.
(just to be clear: of course, normally I write code that is mostly free of errors, but this feature is, as mentioned, quite convoluted with a complicated history behind; I already warned the testers beforehand that they better test very comprehensively).
Back to topic: Sending code back to me with a clear indication where it fails will for sure not make me an enemy, because this nearly always leads to improvement in my code, which is what I actually want (on the other hand: office politics might easily make me an enemy ... ;-) ).
The reason you don't make enemies with QA is because you have been able to express your earnestness. If you instead, however, sent bad code on purpose, or carelessness, because of a deadline. Then you would make enemies.
It's fascinating how the Windows kernel is the only mainstream desktop or server kernel that stood the test of time without being either a Unix system or derived from a Unix clone.
That alone makes it a great case study. Of course it stood on the shoulders of giants too. But today it stands alone with many design decisions. Some turned out great, some less so. But the design philosophy and quality of the kernel is very solid (something I wouldn't say about the userland work Microsoft did over the last two decades)
Interesting how staff numbers climbed at a 50% to 140% rates between kernels. I wonder how many devs Win 10 and 11 had. How do you even coordinate projects with thousands of people working on the same code?
Product Devs Testers
======= ==== =======
NT 3.1 200 140
NT 3.5 300 230
NT 3.51 450 325
NT 4.0 800 700
Win 2K 1400 1700
NT was in fact all new code written from the ground up - there is no code from VMS (or the later MICA project at DEC which more closely resembled NT than VMS). Any serious study of VMS' architecture will show that there are considerable differences between NT and VMS.
While Microsoft may have been "dragged kicking and screaming" to the specific $105 million figure mentioned in this article, a co-marketing arrangement that resulted in DEC endorsing Windows NT as a migration path for its significant but declining install base of UNIX and VMS server and workstation customers sounds like a win for Microsoft, not DEC.
It also reminds me of the settlement of the DEC v. Intel lawsuit the next year that resulted in Intel buying out DEC's semiconductor operations and DEC endorsing IA-64.
If nothing else, the DEC/Microsoft alliance eventually resulted in a promotional copy of OpenVMS and Windows NT Integration for Dummies[1] showing up in my mailbox, which as I recall was both amusing (the book's name) and informative (its contents) at the time.
Both can be true. The design is clearly VMS influenced, but that doesn’t mean they took code from VMS, which DEC clearly would have had a say about. I think Mark’s point in the slide is to emphasize they didn’t take code from older versions of Windows.
There are similarities commensurate with the fact that Cutler and other former DEC engineers designed NT. Overall, they are quite different operating systems. The idea that NT is some kind of rewrite of VMS is seriously overstated.
I agree, and while I only will use it when an employer supplies it, I think its still worthwhile learning the old history, you know, about when Windows was far more interesting than today.
My kingdom for a version of Windows for pro consumers that can be stripped down to remove all the nonsense we never asked for.
There are now many alternatives, looking at office culture today there is really no need for Windows anymore. Many even do their job a lot better with a tablet and a keyboard. The big problem is IT. Zealots that has to use Microsoft/Linux/MacOS/iOS/Android. I say this with decades of experience, different settings will always mean different choices usually it is not the best solution for the organization that wins.
In my case I went from Windows 11 to POP_OS! (I hope they rename this ridiculous to google name) though I kinda want something more bleeding edge just unsure which one hits the sweet spot.
Currently having issues with this at works. Teams are pressured by their PM to release at certain time, and breaking thr pipleline and sending back bad code creates you lots of enemies from top to bottom.
Sometimes you just know the project is doomed by looking at how the organisation handles failure.