Marc Bevand

> The problem comes when we are so focused on proven stuff...

I sympathize with your overall point, but there's a really good reason why the focus should be on proven stuff: because it's been proven.

You are building an application which will be responsible for safeguarding some of its users' information. You should typically want to do that using a proven approach. If nothing else, it's a cover-your-ass situation: if it turns out that the proven approach has a flaw, you can at least say that you followed standard practices. If your invention has a flaw, you hold all the responsibility.

I hate to fall back to argument-by-analogy (but I have to, since I'm not a cryptographer), but you're somewhat in the situation of installing a fire suppression system for someone, and you're saying, "Well, I don't want to use halon for this, even though it's what all the experts say I should use, because I don't want to deal with the company selling the halon equipment. So let's just use lots and lots of kitchen fire extinguishers instead. They do the same job, and if I use lots of them, it will work just as well."

Maybe. Maybe it will. But, if it doesn't, you will be responsible for having made a decision that flies in the face of lots of advice from lots of very smart people, and the consequences of that decision will affect not just you but also anyone that uses your system.

edit: On the more technical side of things, maybe nobody has yet pointed you to Bruce Schneier's 2005 article…

Yet you can do a few simple thought experiments.

What would those fast-dev do in a vacuum? Or with only clone of themselves coworkers.

What happens when one of those fast-dev quit?

--

If everything is/would be fine, then yes, they are truly rockstars (in all the good meanings of that word and none of the bad). Or maybe merely decent among mediocre ones.

Otherwise, there is a free-rider aspect in their approach.

--

Also it can work only depending on the criticality level of the industry.

Ship broken crap quickly (but fix it quickly too)? Good if you are creating yet another social website maybe. Less good for e.g. medical devices.

--

One more point: the business value approach is not necessarily the only one to apply esp. if there are tech infrastructure components in what you ship. You can easily be stuck in local optimums too far from global ones, and fossilize some aspects of your product. See for example the classical http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/ that includes some example of death by thousands cut.

What I mean is that moving fast is partly in the eye of the evaluator. Maybe you implement what PM wants quickly, and that's cool, but maybe also doing only what PM wants is not the best thing for the project.

--

If you are easily able to plan things, have a good data model, and can develop quickly, probably you don't have a real code quality problem to begin with. At least not in the parts you…

Reminds me of the 'I contribute to the windows kernel. We are slower than other operating systems.' article:

http://blog.zorinaq.com/?e=74

"Another reason for the quality gap is that that we've been having trouble keeping talented people. Google and other large Seattle-area companies keep poaching our best, most experienced developers, and we hire youths straight from college to replace them. You find SDEs and SDE IIs maintaining hugely import systems. These developers mean well and are usually adequately intelligent, but they don't understand why certain decisions were made, don't have a thorough understanding of the intricate details of how their systems work, and most importantly, don't want to change anything that already works.

These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones.

(That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.)"

Wow, I see.

I must admit, I do very much wonder what kind of environment Microsoft would be if teams were less segregated. I found http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/ in the comments, which seems to hint at the same sort of theme somewhat - particularly the bit about contributing to teams other than your own. There's a strong notion of isolation.

This is just thinking out loud, a response is not required. Everywhere has pros and cons. I'm (even with all this moping) actually less hesitant about MS as a whole than the rest of FAANG (except for N, which I also don't see a problem with) - not because of the whole "new MS" thing, or GH, but because everyone else seems to have fewer scruples than I consider to be a viable baseline. So there's that. :)

It's just kind of sad to see these kinds of inefficiencies, and it would be cool to eliminate them. Of course, it'd unleash organizational chaos for a while, but of course it would be totally worth it.

The original kernel from which Windows evolved was written in assembler by Dave Cutler for the VAX architecture. After his DECWest team was hired by Microsoft, they reimplemented it in C. The MIPS architecture was the first fully complete port, I believe.

This is documented in Zachary's Showstoppers book:

https://www.flyingpigbooks.com/book/9780759285781

It appears that performance and architecture improvements are very hard to get accepted (and the kernel suffers for it):

https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/

It is a great piece of engineering, but it is likely for a developer that is more comfortable making small changes within the hierarchy than for any revolutionary ideas (unfortunately).

If Cutler hadn't found his way to Microsoft, then they probably would have ended up on a BSD kernel, as Apple did. As it was, Microsoft sold their Xenix business around the time of Cutler's arrival.

We are at 2 TX/sec because, well, people simply don't transact more than that.

Bitcoin CAN support a much higher transaction rate with ZERO increase in mining resources. All we need is (1) more transactions and (2) a block size increase. Let it be clear: the only "dumb" thing is not the system itself, but Bitcoin developers who have not yet agreed on increasing the block size.

Secondly, seeing the mining resources as spent only validating transactions is failing to see the whole picture. Miners sustain a system that is already a net benefit to the economy. Venture capitalists invested more than $1 billion into at least 729 Bitcoin companies which created thousands of jobs. Is all this worth the 150+ megawatt of (practically all) clean energy used by miners? Hell yes! This argument (and others) is explained in detail in:

http://blog.zorinaq.com/?e=82