1/ In early 2004 we were heads down executing on Edit and Continue across a large contingent of teams. There had been several iterations of scoping, redesigns, and customer feedback.

2/ We had a weekly meeting every Thursday morning when representatives from each of the teams would get together and review progress. It was fairly heavy weight, but there were so many teams involved that it was necessary to have a regular sync.
3/ Regardless, E&C was coalescing, but teams were stretched thin working diligently to enable scenarios, improve performance, fix bugs, etc. It had been a month or so since we decided to add support for C# to the matrix as well, so folks were a bit stressed.
4/ That set the stage for the meeting that we had on the first Thursday in April. A debugger PM named Habib Heydarian ran the meeting and after a brief intro he gave me a ring to come in and present.
5/ I walked in and handed out a document that I had written up, titled DCR: C# Edit and Continue for Venus. DCR meant design change request, and Venus was the design-time code name for ASP .NET support.
6/ I explained that we had a recent review with leadership and that while the feedback was very positive, we had been asked to enable E&C for ASP .NET as well.
7/ The room was shocked - their teams were already over-extended and ASP .NET support was something that we had scoped out essentially day 1.
8/ We then proceeded to review the document which went through the customer rationale, scenarios, the user experience design, and suggested architecture. The first Thursday of April in 2004 happened to be April 1st - April Fool's Day.
9/ The 'spec' looked and read legitimately for the first sections, but was intended to get wilder and more ridiculous as we read through it.
10/ In the final section it had statements like "happily, most of the work for edit and continue has already been done for the Client, so extending it to support Venus should be relatively trivial" (absolute nonsense of course). as well as
11/ "however, it is also necessary to make Office development support EnC."
12/ It went on to suggest that the only reasonable way to get design time support for this scenario was to run the language service on the server, which, despite what we've been doing with Codespaces recently, was absolute crazy talk at the time.
13/ This was the 'architecture diagram' included:
14/ When we got to this point in the document, I expected folks to catch on that this wasn't serious, or at least, call out that perhaps some more thinking would be needed :) I tried to make it as ludicrous as possible, without any detail, with arrows just randomly drawn in…
15/ but... TBH, I think folks were in shock as no one said anything. In fact, a good number of folks were busy writing emails to their teams and management - once Habib and I realized that, we finally told people it was a prank.
16/ I'm not *exactly* sure how many folks in that room hate me to this day, but based on the reactions then, it maybe wasn't quite as funny as I had hoped :-)
17/ I'm sure it'd make folks feel better to know that I spent a good portion of the rest of the day answering emails from various levels of management who were still convinced it was real and were uh, nonplussed, when I told them it wasn't.
18/ Habib and I did a brief Channel 9 video a couple of years later where we talked about it which is still available here: https://t.co/nrzm1wGvpZ. Since the only comment on the video is "I missed what the prank is exactly…"
19/ we somehow managed to have perhaps the unfunniest prank in the history of computing, but we tried! FWIW, a few folks eventually got a laugh out of it, you know, after they stopped being enraged.

More from Software

Kubernetes vs Serverless offerings

Why would you need Kubernetes when there are offerings like Vercel, Netlify, or AWS Lambda/Amplify that basically manage everything for you and offer even more?

Well, let's try to look at both approaches and draw our own conclusions!

🧵⏬

1️⃣ A quick look at Kubernetes

Kubernetes is a container orchestrator and thus needs containers to begin with. It's a paradigm shift to more traditional software development, where components are developed, and then deployed to bare metal machines or VMs.

There are additional steps now: Making sure your application is suited to be containerized (12-factor apps, I look at you:
https://t.co/nuH4dmpUmf), containerizing the application, following some pretty well-proven standards, and then pushing the image to a registry.

After all that, you need to write specs which instruct Kubernetes what the desired state of your application is, and finally let Kubernetes do its work. It's certainly not a NoOps platform, as you'll still need people knowing what they do and how to handle Kubernetes.



2️⃣ A quick look at (some!) serverless offerings

The offer is pretty simple: You write the code, the platform handles everything else for you. It's basically leaning far to the NoOps side. There is not much to manage anymore.

Take your Next.js / Nuxt.js app, point the ...

You May Also Like

This is NONSENSE. The people who take photos with their books on instagram are known to be voracious readers who graciously take time to review books and recommend them to their followers. Part of their medium is to take elaborate, beautiful photos of books. Die mad, Guardian.


THEY DO READ THEM, YOU JUDGY, RACOON-PICKED TRASH BIN


If you come for Bookstagram, i will fight you.

In appreciation, here are some of my favourite bookstagrams of my books: (photos by lit_nerd37, mybookacademy, bookswrotemystory, and scorpio_books)