A Primer on Why the Chronic Suffering of the VB.NET Community is neither Necessary nor a Matter of Expense or Practicality

I’d originally planned to write on this particular topic in response to increasing outreach to me personally, through my blog and other places, unsolicited, and independently from multiple community members expressing concerns about the health of VB.NET but also their passionate and heartfelt desire and commitment to contributing to its success. I too had been thinking about this, spurred on by comments on the vblang repo, social communities like forums, Facebook and Twitter, but also my own experiences and limitations. Due to recent announcements I’ve had to edit this post somewhat but fundamentally it still makes the point I always wanted to make; what’s changed is the context. It’s not a hastily written result of a last-minute brainstorming exercise or an emotional outburst but the culmination of my thoughts and observations over the last 10 years, 8 of which were spent working on VB.NET at Microsoft. It’s not at all my complete take on the current state of affairs but it is critical for the entire VB.NET community and everyone else watching to be armed with this context when discussing or socializing about anything else, so, I’ll try to provide that first and roll out any further points separately.

Time and time again I see the discussion of Microsoft’s level of investment in VB.NET framed around the same faulty assumption: it’s just too darned expensive and impractical for Microsoft to support two .NET languages (ignoring the fact that they actually make three); it would take an army of developers and content writers at great expense nearly duplicating all effort across the ecosystem at worst or perhaps 10-30% of the (Developer Tools) division resources at best. Today I want to put that misconception to rest.

The difference between where we are now, a position of continual disappointment, dissatisfaction, lost trust, stagnation, frustration, and humiliation; and a place of continual progress and increasing developer satisfaction for the VB.NET community IS NOT AN ARMY of redundant, reluctant, overworked, overcommitted Microsoft employees. Everyone needs to get that out of their heads that that is what this is about—that it’s fundamentally a choice between purgatorial misery for an entire community and hamstringing 5, 10, or 30 of the .NET organization or DevDiv and tens of millions of dollars in salaries. The difference between where we are now and a mostly HAPPY sustainable VB.NET community is…

3-5 developers.


That’s all. Not an army. Not a percentage. Not millions of dollars. Less than a handful of folks in a team room is enough to *radically* invert the delays, shortfalls, perception, and “forced tough decisions” narrative many of you have observed in the last few years. We know this to be true because we’ve seen it working for 10 years and I’m going to explain it and how we got here so that we all have the facts for thinking about our own next choices and Microsoft’s choices. None of this suffering, depression, and contention is necessary AT ALL. Nothing that’s happened (or not happened) in the last 5 years is about cost or practicality; and malice is not required to explain any of it either. So, let me walk you through the rude Q&A.

How could 3-5 devs make any real difference?

I’ve said that a wildly different reality could easily be achieved with a small autonomous dedicated team of 3-5 people. I know this because we’ve all been watching it work significantly better for TEN YEARS on the F# team. I’ve seen in arguments people say “C# and F# are clearly the priority because…” when for the better part of the last 10 years—it’s entire productized life—F# has had on average 2-4 devs working on in at any given time (and a few times a little as 1) as a whole across the entirety of the company. Full stop. And what has that gotten them?

All of this value in just 3 years, update after update, release after release, continuously, and transparently delivered by a small agile team of usually less than 5 people. Have they had setbacks? Absolutely. At times they’ve been outright excluded from certain technologies and at other times they’ve been perilously understaffed due to attrition but on the whole their users have seen steady progress, leadership, and accountability. They love the product, they love the team, and they’re happy to roll up their sleeves.

VB.NET is an order of magnitude larger than F# but externally people have a wildly disproportionate perspective on it because of the results it can produce because it operates as a separate team from the broader C#/VB/.NET org. At times F# hasn’t even been in the same org as C# at all. Yes, open source is a significant part of that success so I’ll get into that next.

And beyond open source, as a point of comparison, all the tooling support for VB.NET for Windows Phone 7 was implemented and tested by 1 engineer, on the side. The OmniSharp work that lights up C# experiences in VSCode: for quite a long time was just 1 engineer. All of the Windows 8.x samples: 1 engineer. Don’t underestimate the impact 3 developers could have.

“But F# can achieve so much because of its engaged open source community; VB.NET doesn’t have and likely can’t have so vibrant an open source community because… <stereotype>”

F# absolutely leverages its open source community. But a few things to keep in mind. Fostering that community is and has been a top priority of the F# team and that’s something that they’ve been able to do because of their autonomy and they started doing it long before it became popular and VB and C# open sourced. And, I can tell you, having been in the sprintly status meetings where we discuss open source commits and contributions that they would consistently put Roslyn to shame despite the C# and VB communities both being significantly larger (in fact I think VB support in .NET Standard/Core 2.0 was done by an F# community member).

And this is usually when some dudebro in the back stands up and says “But the average VB.NET developer isn’t going to contribute to open source—they <condescending stereotype>!”. Well, yeah. The average C# developer isn’t going to contribute a compiler feature or any feature. The average F# developer isn’t contributing. Open source communities aren’t about average users. VB.NET has more than enough above average folks who want to contribute and have tried to contribute but that desire has to be grown and supported by a group of folks who treat it as a priority. For quite a while (felt like years) I watched the just 2 folks on F# at the time: Kevin Ransom and Lincoln Atkinson where most days all they did was work with their community on PRs and keep the lights on with basic infrastructure or platform work for F#.

“But who would really contribute?”

We’ve already had engaged potential and actual contributing VB.NET community members:

  • Adam Speight was one of the first community contributors has made contributions in the compiler and the IDE and prototyped new features.
  • Paul1956 took on work to enable comments after line continuation.
  • Eric Mutta has tried to make contributions in a number of areas.
  • And others have reached our repeatedly both while I was at Microsoft and since about contributions not only in the compiler but the IDE and in documentation and in tests and in partner tools like the EFCore code generator or just templates and samples.
  • Current and Former VB MVPs (some now Microsoft employees) have gotten their hands in the code and produced or started to pursue viable ideas.
  • Former VB team members who have moved on from Microsoft are out there in the wild, including…
  • Me. I am literally a VB community member who has actually written features and product code that ships in the VB.NET product today. VB String interpolation is a feature `$”Written by: {Me}”`. I implemented the initial parsing of `Async` and `Await`. I’ve written Roslyn APIs that power IDE experiences. I implemented the `TypeOf … Is|IsNot`, I’ve prototyped features in the product like multi-line string literals, readonly auto props, byte literals, year first date-literals, and others. Last year I literally prototyped and demonstrated several feature ideas including writing VB code that runs on Android and in the browser without any extra support from the Xamarin tools or ASP.NET Core teams. I am a PURE VB.NET developer. I have never used any other language full-time for any significant portion of my education or career—a client project here or there but nothing that somehow made me NOT a VB developer. How am I supposed to engage?

But a culture of contribution doesn’t succeed in a vacuum. As one VB.NET community member noted to me (last month, I think): (paraphrased) “I normally contribute to making the docs better but seeing the stagnation in the vblang repo makes me not even want to bother doing that”. It’s not a set of individual dials but an ecosystem and the impact of failing in one category discourages all the others.

F# has between 5-15 BIG contributors and a long tail of smaller contributors. I think there are more than enough VB.NET willing and capabledevelopers in the world who could meaningfully contribute to the VB.NET ecosystem if they had 2-3 engaged team members inside Microsoft treating both VB.NET and open source as their first priorities. It doesn’t mean we’d get “everything”; it doesn’t mean that “everything” has to be accepted, but there would mean more blog posts rich with content like what F# has when a new release comes out and less radio silence and excuses.

F# wasn’t born flying with open source, they had to crawl. And supporting their community is a great example of a priority they can make because they’re autonomous and I’ll explain why autonomy matters next.

Why what we’ve been doing stopped working and why you don’t have to assume it’s because Microsoft is anti-VB.NET

The thing about Microsoft—a large international trillion-dollar mega corporation made up of over 100,000 people, many of them quite smart, and quite busy is…

There is bureaucracy there that does not sleep

I’m going to tell a few stories, buckle up.

First story. In 2005 (I think), the VB team, in response to community feedback that the solution explorer was overcrowded with items and visuals which weren’t directly user-created, decided to hide the References node. VB has its own reference management property page (which also manages project-level import directives) so this was technically safe to do. But over time many people grew to find that node useful for various reasons. I joined the company in 2010 and for years when various members of the team (myself included) would go to events or talk to VB developers we’d consistently get feedback “I wish you’d show the References node”). We were pretty confident on the feedback and that we wanted to unhide it in the next release.

It’s a one- or two-line change but the code that hid the node belonged to another team at the time. That team was responsible for a lot that release including a big part of the story for building Windows 8 apps and I politely asked them to unhide the node to make my customers happy and they politely stonewalled me using every mechanism in the book.

  • They said, “Well, we shouldn’t just change this thing we didn’t know anything about… if only there was feedback”
  • I said, “There was feedback”
  • They said, “Yeah, but if only there were a UserVoice request”
  • I said, “There is a UserVoice request”
  • They said, “Yeah, but does it have votes?”
  • I said, “It does”
  • They said, “Oh, but the vote count isn’t very high”
  • I said, “It’s high for the VB category and we’ve consistently gotten this feedback verbally at conferences for years”

This went back and forth for a while with the goal post moving about. They wanted reports, focus groups, user surveys, UserVoice requests, high vote counts, telemetry, revenue statements and tax receipts from the companies the customers asking worked for. There’s a bit of an adversarial system there for collaboration and the truth is that team was buried in critical work and it was cheaper to burn down my willpower than to have an engineer remove the offending line of code.

A few years later, sometime between 2013 and 2015 the Roslyn team took ownership of the code that caused the references node to be hidden (for unrelated reasons). I went into the office of an old VB IDE team member to find he’d already deleted it. Apparently, it took like 5 minutes. No muss, no fuss, no red tape.

The point of the story is that 5 minutes of real work took 5 YEARS to actually implement not because of any intrinsic complexity or risk to the work or because anybody had malice toward VB.NET users. But because the organizational structure made it very time consuming. Yes, there are mechanisms (escalation) for resolving these disputes but that doesn’t reduce the effort of doing a thing it grossly increases it at a cost of precious political capital and the people who suffered for that (again, sans malice) were the VB customers in those intervening 5 years who couldn’t access that value. Once it reached a state where it could be solved autonomously it was.

I once had a PM argue that VB.NET developers were probably outside of their scenario because “the target for this feature is really large legacy code bases”. (eye roll) It’s not that he was malicious. He was just willing to say anything to defend his team from any more work from anybody. I could tell you other impressively illegitimate pushbacks (like how maybe compiling was outside of the scenario of building projects) but we don’t have time.

I’ve seen features with universal agreement across an org (all teams and managers) still fail to be implemented for years and others implemented only to fail to be checked-in and shipped because of analysis paralysis and a reluctance for anyone to take responsibility or to simply feel empowered to provide that customer value (I originally wrote out those stories but have cut them for pacing).

And on top of that re-orgs, manager changes, and office moves were frequent enough at Microsoft and any of them can reset an entire effort requiring re-discussion, re-validation, and re-approval, and rescheduling. I’ve seen customer value that was only delivered because some courageous principle level developer literally went rogue and “just checked it in”.

Last story (on this topic). For the 2015 release of Visual Studio we’d began with the idea that after a long break without any new features in either language (remember that no new features came in VS2013), we would do what we called “just do it” features. Small, harmless productivity enhancers, many of them long requested from community members, that were low cost so we could get a number of them in the release. And, as had been the case for almost all of the Roslyn project, VB and C# were handled by a single unified team (more on this later). So, here’s what happened: VB design meeting put together a list of great small features. C# design meeting put together a list of great small features. The VB features were fairly low risk (but not necessarily low value) and the C# features started out similarly (some were just analogs) but certain differences in the design philosophy of what was enough or “a little more” or “properly generalized” on the features meant that the C# versions of those features became more complex over time and riskier. So, we (I was on that unified team) tactfully decided to front load the C# features because we could get earlier feedback and uncover more risk and since the VB features were all pretty straightforward, we could circle back to them a little later in the product cycle. But the C# features just kept growing and growing and getting more complex. Then an asteroid hit campus or something and there was an unexpected schedule contraction and now instead of having a year to wrap up we had like 3 months. Ultimately the C# versions of the features grew to such complexity and some of them actually grew out of being useful entirely and most were cut AND almost all of the planned VB features had to be cut and there I was starting VB String Interpolation after officially we were “feature complete” just to ensure VB customers would get any big value that release. To be clear, another team member was writing C# string interpolation in the same timeframe. It wasn’t that C# was in a good place either. Multiplexing the team, combined with the C# natural progression of the design approach had eaten so much of the schedule that when disruption happened it negatively impacted BOTH languages. I’m not complaining about the C# design approach, to be clear. I absolutely get why they design how they design—it creates a consistent language philosophy for C# users. I’m just stating that multiplexing the same team to manage two languages failed hard. Maybe I could have anticipated that, or the inevitable schedule disruption. Maybe I could have been more contentious about it in the beginning or the middle but I shouldn’t have had to be. That same set of circumstances had no real impact on what F# delivered in VS2015.

So, there was a chaotic system and an organizational structure on top of that system that could not react to disruption and the wheels ground to a halt. Whether it’s because of thread starvation or context switching or deadlocking or whatever processing analogy you want to come up with that approach repeatedly failed for reasons completely devoid of malicious intent.

“Well it sounds like there’s some dysfunction. There’s the problem! Shouldn’t Microsoft fix that so that they can get the current model to work for VB too; isn’t that the ideal?”


C# and VB have worked under what I call the distributed model, where there’s some experience scattered across multiple teams. And for C# that generally works for a number of reasons—usually getting C# to work is essential to drafting the infrastructure and design of whole systems and platforms. But there are plenty of times where taking the same approach for VB.NET isn’t needed, doesn’t work, or does more harm than good.

For example, samples and templates. It’s not enough for another team to create a template. The “VB owners” have to review and modify all of those templates with VB specific knowledge. For example:

  • Should this project use VBCore?
  • What should the default project-level imports be for this project type?
  • Do the default items and item templates for this project make use of or work correctly with a project root namespace?
  • Does this project enable or disable the prescribed set of VB recommended warnings?
  • Does this project template correctly exclude an explicit setting for project-level Option directives? This is essential in order to respect each user’s VS wide project default settings which are synced to the cloud: if there’s an explicit setting in the file VS won’t override it with the user’s stated preferences.
  • Are certain items appropriately nested (or not) under the My Project node?
  • Etc.

This list of checks is even larger for samples because there’s usually more code. Some are functional but others are stylistic like:

  • Did the person who wrote this sample use `Object.ReferenceEquals` because C# doesn’t have a reference equality operator and these uses must be now be updated to use VB’s `Is` operator?

For actual functional changes they have to be tested for working with the VB tooling and experience. Even with automated tooling there’s still a manual process that has to take place and it has to be done by people who actually understand VB and its features and how to leverage them best. And it often has to happen multiple times when samples or templates are updated pre-release. No one really benefits from the other team “owning” any of that work (or front-loading it) and just getting a bunch of bugs filed on them. It’s an unknown quantity that they may not have the capacity or capability of completing. And even in the event that that work is prioritized through escalation that creates a culture of tension and adversarial defensive hyper-vigilance rather than collaboration because these ticking time-bomb work items have the potential to seriously disrupt partner teams. It’s not a just a symptom of collaborative dysfunction; it causes collaborative dysfunction.

That’s for external teams but for the C# language this is especially untenable for all involved because C# advances the .NET platform. I’m not begrudging or envying them that role but recognizing that that’s what the language has always done where VB is traditionally focused on innovation in experience. It’s not that you can’t write a library or a framework in VB (and people have) but the .NET platform is not and will never be dependent on the VB language (or F#) to make leaps. But if C# is late developing generics, .NET 2.0 doesn’t ship. If C# hasn’t figured out the shape and behavior of nullable value types those types can’t appear in any new APIs. If it’s late on LINQ, .NET 3.5 doesn’t ship. If async isn’t complete, .NET 4.5 can’t ship with new asynchronous APIs. If C# language design can’t converge on ref returns or nullable annotations the platform teams (like mscorlib) that depend on those features literally cannot ship their platforms for anyone. And for what it’s worth, C# is ALWAYS late on those things (a fact I learned too late) because getting it right takes all the time in the world. Which is why it’s insane (in hindsight) to envision an “ideal” world where you couple or serialize a language which does not fulfill that mission critical role with so many downstream dependencies and its customers’ productivity with one that does and expect good things for both of them.

And no one is trying to move F# to this model.

In the past when Microsoft was more closed source and teams were a lot more possessive about their code maybe this was the only way to do it but the culture has changed there. It’s a lot easier to just submit a PR (even internally) from the team that owns VB and have that team review and sign-off as needed. Things have changed and there’s room to change for the better because of it.

“But a small dedicated team doesn’t scale!”

Is the status quo scaling? Are we tired of scaling yet?

I’ve had the same # of cores in my desktop for the last 8 years; they’ve scaled to everything my computer has done in that time. Nothing didn’t happen because the # of cores was fixed. The current model for VB.NET has literally “scaled” to 0.

Which brings me to…

How did we get here?

In any situation it’s easy to imagine that things have “always been like that” or that they “must be like that for a reason”. There usually are reasons and sometimes those reasons were valid once and are no longer and need to be re-examined. Let me take you on a trip through time…

  • In the beginning (VS2002-VS2008), VB was its own product unit. You could actually buy VB.NET as a standalone product and it had its own budget, staff, marketing team and everything. C#, I believe, started out as a part of the C++ PU until it got big and moved out. Everything that happened in VB.NET up until around 2008 (LINQ) was from the VB PU, and everything in C# from the C# PU. There’s a picture from that time of Anders and like 50-100 people working just on C# (wearing C# T-Shirts) so I guess they had a lot of people and VB had a similar number of people. As many of you will recall, this split led to lots of good stuff but different good stuff and there was some wailing and gnashing of teeth.
  • After VS2008 co-evolution came and VB & C# were merged into a single PU: Visual Studio (Managed) Languages or VSL. Eventually F# and the Dynamic Languages IronRuby and IronPython, were part of this org.
  • When I joined VSL in 2010 here’s what the layout of VB (approximately):
    • VB Compiler Dev: 5+ devs + 1 lead
    • VB Compiler Test: 4+ testers + 1 lead
    • VB IDE Dev: 5+ devs + 1 lead
    • VB IDE Test: 4+ testers + 1 lead
    • VB Compiler PM (Me)
    • VB Language PM (Lucian)
    • VB IDE PM (Dustin)
    • VB Community PM (Beth/Lisa)
    • C# had the same layout so both VB and C# had ~25+ people working on each language them across their IDE and Compiler & 4 full-time PMs each.
    • F# always had a single PM who owned everything and their compiler and IDE teams were merged but they still had dev and test separated out so it was probably a third the size of either VB or C#. Let’s say ~9 people, not including Don Syme.
    • There were a couple extra layers of management for each discipline and each layer but it was a little lopsided.
  • After VS2010 we started working on VS2012 and Roslyn (which we thought would ship in VS2013 but ended up shipping in VS2015) in parallel. The team split with some folk working on VS2012 and some working on Roslyn. A combination of diminished scope and the usual staff reshuffle after a release as people move on to other teams really shrunk down the VB and C# hierarchies a bit. Completely accidentally every “team” on either version was missing one person in either a leadership role or a particular language so we consolidated some for efficiency reasons (at first).
    • The Compiler C# PM/VB Dev Lead/C# Test lead ended up owning both languages and eventually the IDE experience for VS2012.
      • Compiler has maybe 8 devs (at first) and 6 testers.
    • F# stayed pretty much the same, a separate team with one PM working toward its next release in VS2012 but it eventually consolidated its dev lead and test lead roles.
    • The Compiler VB PM/C# Dev Lead/VB Test lead ended up owning both compilers for Roslyn.
    • The IDE VB PM/C# Dev Lead ended up owning the IDE for both languages for Roslyn.
    • There were these cool extra “architect” people on Roslyn.
    • The VB Community PM ended up owning both languages.
    • VB and C# Language PMs remained separate.
    • The VS2012 team decides to do async in both languages and grows significantly.
  • The Roslyn IDE might have set out to be unified across both languages pretty early but the compilers were originally designed differently and implemented separately. That’s what drove unification. Their designs were a little different and we observed strengths and weaknesses and different valuable optimizations that each language had come up with in their compilers or interesting tradeoffs that had been traded in opposite directions. And as we were trying to get the performance of the data structures right, we ended up trying both approaches and hybridizing them and eventually it just made more sense to unify the dev teams (they already shared a single dev lead) to get a consistent uber architecture going forward (there are still some differences but they’re very much intrinsic to the languages).
  • Compiler test was also unified and this was AMAZINGLY valuable because the test team found so many consistency issues with the APIs between the two languages that drove the design to be better and many differences between the actual language semantics that simply drove understanding of the differences between them.
  • Post VS2012
    • The VS2012 team does a little work on VS2013, same structure as in VS2012.
    • F# gets spun out to another org entirely.
  • Post VS2013
    • The VS2013 VB/C# experience team joins the “Roslyn” org.
    • The VS2013 VB/C# experience team DOES NOT join the Roslyn compiler or IDE teams and becomes something else entirely eventually working on .NET Analyzers.
    • Eventually F# rejoins the Roslyn team reforming Managed Languages. At this point they have like 4 engineers total (I think) and no PM (an engineer owned PM tasks). Their numbers shrink and grow and they go through several PMs.
    • Eventually Dev and Test are unified across the entire company. For multiple reasons, by this point the unified engineering team (which owns both dev and test functions) is maxed out at maybe 10 non-managers. This is less than the combined size of dev and test before.
    • Somewhere in this dedicated community PMs disappear. VB language PM takes over community for both languages.
  • Post VS2015
    • I own … VB & C# compiler, debugging (EnC, EEs), eventually language, Analyzers, the Roslyn compiler APIs, scripting, interactive (REPL), part of .NET native, part of VSCode, debugging again, analyzers again, and some set of community engagement (not always all of this at once).
    • Mads is the C# language PM still, owns a piece of community.
    • F# has a PM again.
    • There was an IDE PM and then there wasn’t technically and then there was but it was a different view of the IDE
    • Part of the IDE also split off to own something else.
    • The “Compiler” team which was the doubly unified VB and C# engineer (dev and test) team (still ~8-11 people) also began to take over some bits of what the IDE team used to do while the IDE team was taking over everything else in creation.
    • Oh, we open sourced everything and that added to what had to be done across the board.

The point of this very long outline is that no divine being ever said “VB and C# ought to be organized this way because it’s good and right and true and best and it would be immoral to organize them differently”. Consolidations mostly just happened in reaction to needs and limitations in the moment and persisted due to inertia. At specific times and in specific areas there was value in the organization but by late in the VS2015 cycle it wasn’t working anymore but we didn’t seriously question it (even me—I thought it was a one-off; I was wrong).

Further, there were like 30 reorganizations and changes to company culture and management at every single level of the hierarchy and across multiple disciplines over this time period with each new manager inheriting this structure from the last probably thinking “That’s how they’re organized because that’s the way they figured they should be”. It’s a historical artifact and nothing more. If it isn’t working anymore (and it hasn’t been) then that structure should have been dumped long ago for something that works.

Meanwhile F# continued to be an autonomous team also mostly because of inertia. They may have reported up through the same managers as the VB/C# compiler team (sometimes) or IDE team (other times) but they remained separate functionally (no pun intended) which meant that no amount of stress on C# specifically could impact F# at all.

“It’s a zero-sum game. Divesting in VB would make C# happen twice as fast!”

This is demonstrably untrue for several reasons. You can certainly organize them in a way that forces them to be a zero-sum game but it’s not essentially the case.

The first reason is…


It’s not the case that if you have a developer (or other role) that works on one (or two) languages that they can just slide, or more importantly be slid over to another language. I’ve seen this attempted many many times between VB, C#, Python, Ruby, JavaScript, F# in various combinations and in both directions. More often than not that person just leaves the team or the company. It’s not a win for the company because that person isn’t simply replaced with an equally good but more fungible person because HUMAN BEINGS ARE NOT FUNGIBLE RESOURCES. That idea is fantasy. On rare occasion it works but overall, the broader organization just gets smaller and weaker for it because you lose that person’s uniqueness.

The second reason this isn’t true might shock you…

There is a maximum effective team size for any language/layer/component. If you look back at my outline of the history of the team structure, you’ll note that after VS2013 we (the Roslyn VB & C# compiler team) didn’t just absorb the members of the VS2013 VB & C# compiler team. I remember discussing it and the feeling was “the team’s already large enough!”. Even though we had massive scope for where we were in the project adding more people wouldn’t have double the speed or anything and would have slowed things down. Teams grow in scope, not in size. You can get more people by creating a more complex hierarchy but that complexity also reduces efficiency.

And as a personal example, sometime around the middle of 2016 I sincerely tried to leave the PM discipline to become an engineer. There were big changes going on in the PM org. I was in the beginnings of my current nervous breakdown. My depression was spiking. I was super unhappy where I was, I said as much, and I tried to move over to the team that most aligned with my skillset and knowledge to try to manage my stress. I talked to engineering management and I asked several of the Principal-level engineers on the compiler team, with whom I’d worked at that point for 6 years and who had by that point seen many of my check-ins to sign-off on it. All of them were comfortable with me joining the engineering team but I was told by management that the compiler team (then at 10 or 11) was simply too big. The goal for team size is like 6-8. It could not take another person until it attrited 2-3 people and that was it.  

My point is, there is a MAXIMUM number of people who can work on the C# compiler effectively and efficiently. Not having people assigned to VB or F# just means having fewer people assigned to those languages and/or fewer people working at Microsoft, it does not produce any automatic boost to the speed at which C# language features can be delivered. If that weren’t the case Microsoft could just hire 50 more compiler majors from Waterloo and everything would be golden. If you want to put 3 people on VB you don’t take them from C# compiler you just add space for 3 new people to the org and fill those positions. Multiple times has someone tried to force people to work on one language or another and they’ve usually failed, and multiple times has the team responsible for the C# compiler rejected new engineers on account of team size. So, this idea that anything has to be done to VB to protect the velocity of the C# language isn’t borne out by the history.

And forcing one team to own scope that was previously owned by 5 teams: [(compiler + ide) * (dev + test) + PM] or even two separate product units is precisely what creates an artificial zero-sum game.

And just importantly, not having a distinct VB team means…

Accountability is impossible

When I came back to Chicago in 2018, I had a huge issue with getting gigabit internet in my apartment. I was extremely angry with Comcast and to this day have not pursued their gigabit internet. I almost took to Twitter I was so mad. But through my incalculable rage I tried to find some productive understanding of what took place and I realized that I was, or at least shouldn’t be enraged with their customer service department. They couldn’t call up the service tech who never showed up. Days later they couldn’t find out if he ever showed up for work again or if he’d had a heart attack in his truck. They couldn’t prioritize sending out a new tech sooner than 2-3 weeks out. They couldn’t waive the requirement for a tech to do the installation to allow me to attempt a self-install. They couldn’t escalate to call in an unscheduled tech for overtime to correct their mistake. All things they should be empowered to do but they couldn’t actually do. And I was mad because I didn’t know that and human beings expect that when they reach out to other human beings for help that those other human beings will visibly try. But they were disempowered customer service. And it caused massive negative sentiment from me toward their customer service and this non-living corporate entity. But I realized my issue wasn’t with the customer service but the organizational decisions which put those people in the position of being disempowered but ostensibly accountable.

A VB.NET community member reached out to me early last year and, frustrated, asked “Why can’t … just say ‘the plan is to do x’ or ‘we’re working on y’ but they can only say this vague aspirational statement?”. They were furious. But when almost every experience, every value-add that you want to provide to your community is distributed across 2 or more teams none of which is a dedicated VB.NET team, you can’t actually be accountable to the community. You can’t have plans. You can’t have roadmaps. You can’t have schedules. You can’t truthfully state that “you’re” working on it or towards it because 3 or 4 nodes in the system have it on a list but you don’t have the influence and specifically the authority to predict the outcome. You don’t have the agility to make adjustments based on feedback on functionality or priorities. You just put inputs into the system and have to hope that the answer that comes out in a few months’ time is one that pleases the community. And if there’s enough stress on the system nothing happens. Everyone team involved gets veto power or every partner team has a management hierarchy which has their own conflicting priorities or their director who needs to sign off on it is out on vacation this week or they just left and we’re waiting for the new person or they need to align with their bosses commitments that just came in or “we’re buried right now because BUILD is coming up” or “Ignite is coming up” or “VS1X.Y update is coming in hot” and these things are always coming up.

And because no one owns the work, no one can rightly account for it to the community. No one can own the story or the message on it because no one controls the story. There’s no story to own. It’s similar to that old saying about parallelism, 9 women can’t have a baby in 1 month. You can’t just average “20% focus on VB.NET” over an organization of hundreds and expect to get much. Except problems.

A few examples:

Some VB developers wanted to use Azure Functions and there weren’t any Azure Function templates in the box so some VB MVP stepped up and made a template. Sounds like a win for VB, Azure, and open source, right? But the process breaks down because the Functions team rightly asks: “Who’s on the hook for maintaining this template moving forward? What if it needs to be changed? What if these static text files that never change need to be converted into a right-to-left YAML format!? We don’t have budget on the schedule!”. So, I say, fine: let’s create a templates repo for community templates similar to what F# has done. But now the question is “Who’s on the hook for maintaining and operating this repo?”. An open source contribution and a sustainable model for open templating going forward dies in committee. And there have been other templates and open source contributions who died similarly.

A developer wants to contribute code to VB.NET: “Who has the time to review his PR, to give him feedback, to work with him to fix the feedback! No time!”. Dies in committee.

We had translated and reviewed samples for Windows 10/UWP ready: “Who’s on the hook for maintaining these 140 samples!? They’re likely going to change and we can’t absorb those costs”. UWP samples die in committee.

The community has repeatedly expressed interest in mobile development using Xamarin. I understand the desire and that the Xamarin team, newly integrated into Microsoft, is doing a lot of stuff. The work for Xamarin.Forms support is not “nothing” but it’s also not insane (it’s mostly just a code generator). So, the Xamarin team kindly offers us access to their repo to simply investigate getting it working (similar to what was done for WP7). But without a dev to start the work and MORE importantly a team that can commit to potentially owning any bug tail or ongoing support costs for that component however small they’re expected to be that very reasonable approach to solving a community pain point can’t move forward even if a tactical strike is possible in the short-term.  And no one can fully account for that breakdown.

Ignoring whether that’s actually the best solution for VB developers wanting to explore mobile development, the problem is that no one can rightfully account for that investigation even happening: “Sorry, we decided … well, didn’t decide, but couldn’t do the thing no one could actually committed to doing because there was no one to commit to it in the first place so we couldn’t tell you about it beforehand so now I’m letting you know it didn’t happen because there was no logistical reason for it to happen or way of knowing if it was even possible to begin with. This sentence does not exist.”

And I could cite example after example of language features, tooling features, platform features, open source contributions, samples, templates which aren’t expensive in raw engineering effort but are prohibitively expensive due to the bureaucratic gymnastics necessitated by the lack of an empowered, dedicated, small, agile VB.NET team accountable to the community. And that is how we get where we are today. Not cost. Not practicality. Not philosophy. Not necessity. But failure to adapt. Neglect. Which doesn’t require conspiratorial malice; but that doesn’t matter because at a certain point—the point we’re at right now—any sufficiently advanced negligence is indistinguishable from malice.

In Conclusion

As I said in the beginning, this is not a reaction post or a response to a particular event. It’s something I’ve been working on for a while now in response to a progression. I am posting it now so that as conversations take place about where we are, everyone understands that the current situation is entirely and easily avoidable. If you’re not a VB.NET developer who’s just curious or observing this, understand that nothing reasonable is forcing these negative outcomes. It doesn’t take an army or millions of dollars; it just takes Microsoft getting out of its own way. If you’re a VB.NET community member, know that a better, sustainable, proven alternative is possible and do not be distracted by the addition or absence or promise or request for any particular feature, large or small, any template, any sample, or concession of support. The F# community, a much smaller community than that of VB.NET has (and has always had) a dedicated team working and advocating on their behalf throughout the .NET ecosystem as their main jobtheir first priority—every day. There is no reason that after 18 years of loyalty, the VB.NET community doesn’t deserve at least that much. Focus your intentions on this goal because regardless of what anyone says the support of a small 3-5 person, agile, empowered, autonomous, passionate, and dedicated VB.NET Team, separate from C#, is the only support that means anything.

-Anthony D. Green

38 thoughts on “A Primer on Why the Chronic Suffering of the VB.NET Community is neither Necessary nor a Matter of Expense or Practicality

  1. Thanks for another brilliant article.

    “the support of a small 3-5 person, agile, empowered, autonomous, passionate, and dedicated VB.NET Team” — I’m assuming this team must be within Microsoft? What can I, as a member of the VB.NET community, do to push Microsoft in this direction? What steps can be taken by the VB.NET community as a whole?


  2. Anthony,

    What an incredible post. Thank you for sharing what are detailed, personal, meaningful and well stated insights and opinion.

    It is clear that there is has been no “VB TEAM” for a long time and I think you hit the nail on the head in identifying the single most influential reason why VB.NET is in the situation that it now is – there is no dedicated team to OWN the issues – to be accountable.

    There is no stronger advocate for VB.NET than yourself and it was a sad day when the VB.NET community lost someone of your caliber working on the “inside”. I think I speak for many in saying that admiration for you amongst the community runs deep.

    Obviously this is not a post you could have made whilst working at Microsoft – this post however provides the deepest insight into why VB.NET that the community has ever had so again; Thank you for sharing!

    Liked by 1 person

  3. So what do you recommend? Now even if you want to contribute all PR’s are just closed or moved to a black hole. Things are changing rapidly to consolidate code between VB and C# (generally good idea because VB gets new stuff) but it is becoming harder to know what to change to add a feature. Even where help is wanted on the VB side, what needs to be changed is not clear and may not be in VB code and Roslyn is not well documented internally, there is no checklist for all the things that need to change, it is more tribal knowledge.


  4. So, as an “average VB.NET developer”, what can I do to help the situation?


  5. Great post, Anthony—thank you very much.

    Do you have a reference to that VB Azure Functions template? I dug around a bit but didn’t come up with anything.


  6. Thanks for laying this out Anthony. Given that the issues are easily addressed as you proposed it should be possible to get your perspective/recommendations to decision makers within Microsoft. How can this be done?


  7. Let’s look forward. I advice you to write a book:
    Compilers Anatomy: VB.NET as a study case
    based on 10 years of your experience in the field.
    This will give VB.NET community a strong bush and I think you will earn a good money from printing it.
    You also can lead the community to advance the language in a bureaucracy-free fashion. You can ask for little funds from hundreds of companies that has VB.NET running apps and with the help of the book you will get code contributors which will save you a lot of time to do your own work. The fist step is to push VB.NET into Xamarin and ASP.NET to get attraction and enthusiasm. You already had the xml approach prototype , and also we have the ASP.NET 4 VB razor which can be built on to create ASP.NET Core VB.NET Razor. I don’t know much about Xamarin but you mentioned something about it can be altered to use VB.NET.


  8. I have two practical advices to you:
    1- Try put your 10 years experience with VB.NET compiler in a book, say:
    Compilers Anatomy: VB.NET AS A Study Case.
    This can gain you some money and give a push to VB community contributors. F# started small, but VB.NET started with a million lines of code which is impossible to work with without guidance.

    2. You can contribute a small portion of your time to lead VB.NET Community to help you evolve your VB.NET fork. I advice to concentrate on taking VB.NET to Xamarin and ASP.NET Core. You already have the XML approach prototype. We can also look into eveolving VB.NET Razor syntax from ASP.NET 4 to ASP.NET Core if necessary. You also mentioned something about altering Xamarin to work with VB.NET. With first betas you can ask hundreds of companies that have VB.NET running apps for small money contributions to complete the work, promising the product will be totally free!
    If you did (1) you will also have many code contributors in your aid (me included), and this will save you a lot of time and effort.


    • Great idea, if every Vb.net developer understands what is happening I am sure they will contribute monthly even if it is a dollar.

      In Brazil it will certainly have a great contribution, the community just needs to show what it is intended to do with VB.net and where it will go.

      We need to create a teaching environment on the web aggressively like that with Python, we need to publicize, have a website where you can learn and contribute, 1 dollar a month for the community and 1 dollar a month for courses and an environment to exchange experiences

      VB.net lovers should publicize the community and courses heavily on social networks.

      We need to give back the pride of wearing the Vb.net shirt

      Let’s take the dialect to the first place and show the strength of its users.

      Texto original em português Brasil – tradução por aplicativo

      Ótima ideia, se cada desenvolvedor de Vb.net entender o Que está acontecendo tenho certeza que irão contribuir mensalmente mesmo que seja com um dólar.

      No Brasil com certeza terá uma grande contribuição, basta a comunidade mostrar o que se pretende fazer com VB.net e aonde ele irá chegar.

      Precisamos criar um ambiente de ensino na web de forma agressiva assim com Python, precisamos divulgar, ter um site onde se pode aprender e contribuir, 1 dólar por mês para a comunidade e 1 dólar por mês pelos cursos e ambiente para troca de experiências

      Os amantes do VB.net deve divulgar a comunidade e cursos fortemente nas redes sociais.

      Precisamos devolver o orgulho de usar a camisa Vb.net

      Vamos levar o dialeto ao primeiro lugar é mostrar a força de seus usuários, vamos vamos vamos.


  9. Thanks, Anthony, for a deep and fascinating insight into the rather tragic VB.NET situation.

    Is there anything that we can do – as working Visual Studio users with an investment in VB.NET – to affect the situation?

    The cost of your implementing your suggested solution would be a tiny fraction of the business value realised to the world at large. Is there some way in which we could just go back to paying for a properly supported product, as we used to in the late 90’s with the old VB?

    Liked by 1 person

  10. I just wanted to say a REALLY BIG THANK YOU Anthony for taking the time and effort of posting this. Even more so, simply having the courage to do it. I think it’s a bit sad that it had to come from you instead of the PM of VB but then again, since you no longer work there you may have more freedom to tell the truth without worrying about political consequences. I think it will be very helpful to the community in deciding what actions we may want to take. I also think it would be very helpful if the community had “someone” that intimately understands the issues and has a solution (or options) they could rally around.

    On a personal note, I’m sorry to hear about the stress, depression and the consequences of those that you’re dealing with. Although I don’t know your particular circumstances, I do know how miserable it is. I hope it’s not due to a health issue, and if it’s not, I will pass on the advice an older gentlemen gave me many years ago. “Don’t let the bastards get you down! Things always change, and this too shall pass”. From my personal experience I found he was right… in the long run. Like an injury, healing is a matter of time.

    Thanx again,
    Randy Agnew
    (WolvenRA on github)


  11. My “References node” story is to do with F# evangelism and case studies. During 2008-2012 I collected many case studies on F# usage. People would come with new ones and ask if Microsoft could publish them as an official case study. I discovered that each official case study would cost $20K internally. There was no way we could publish more than a couple and from the outside people had no idea how many people were using F#.

    Roll forward to 2015, and we created https://fsharp.org/testimonials. It now took 5 minutes for anyone in the community to add a new testimonial. Sure, they were’nt on the official Microsoft site but that actually made them *more* compelling since they weren’t dismissed as meaningless marketing and could be read by people without all the baggage that comes with a corporate brand.

    So the VB community should be 100% responsible for their own evangelism, including a vb.org/testimonials or equivalent.

    Liked by 1 person

  12. Hi Anthony,

    Really a great look at the issues regarding VB.Net in the last 20 years. I really appreciate your open, honest and first-hand account of the situation.

    I have always felt that the fundamental issues relating to VB.Net were management related and I think you have basically confirmed that. Not that management was trying to do harm, but they just didn’t have a good sense of what the outcomes of their decision were having on various communities.

    When I was active in the VB community and writing textbooks, a good friend (and former student of mine), who was working in one of the teams you describe, suggested I change my focus to C#. Being a wise and perceptive fellow, he could see how management decisions were impacting the development environment within Microsoft.

    In business schools, we often use “case studies” to help educate future managers. Your experience and historical overview would (unfortunately) make an excellent case study.



  13. Can Microsoft be trusted? Is my time investment in anything they create safe? Maybe Rust,PHP, Python, Ruby,Go are safer investments for future projects. I have this question each time i need to spin up visual studio to start a fresh project. I see myself potentially dumping every Microsoft language one day.

    Liked by 1 person

    • esse é um pensamento que merece atenção!
      A microsoft é segura?
      Talvez o crescimento forte dos idiomas abertos não seja apenas porque eles são abertos, mas também porque existe uma curva de existência maios e pouquíssimos pensamentos em descontinuidade.
      O mundo “DEV” está cansado do modismo nos Idiomas, a cada dia temos que pular de dialeto, isso é realmente estressante.
      Python está conquistando o mundo, existem programadores de 30 de carreira em Python e provavelmente iremos ver programdores em Python por mais 60 anos, essa curva é atrativa pois dá uma garantia de existência de maior vida.

      VB.net tem tudo para ser assim também, mas precisa se separar da Microsoft onde o importante é o ROI.
      Se uma comunidade ativa e amorosa assumir o VB você nunca irá precisar mudar de dialeto.

      Vamos torcer e rezar para o nascimento de uma Linda, Duradoura, Amorosa e com compromisso destacado em sua primeira pagina dizendo que o VB.net agora é perpétuo .


      • Obrigado por escrever! Para o benefício de outros estou fornecendo esta tradução automatizada (por Bing) do seu comentário. Se você for capaz, deixe-me saber se você sentir que esta tradução não reflete com precisão sua intenção original:

        Thanks for writing! For the benefit of others I’m providing this automated translation (by Bing) of your comment. If you are able, let me know if you feel this translation does not accurately reflect your original intent:

        this is a thought that deserves attention!
        Is microsoft secure?
        Perhaps the strong growth of open languages is not only because they are opened, but also because there is a curve of existence mays and very few thoughts in discontinuity.
        The world “DEV” is tired of the fad in the Languages, every day we have to jump dialect, this is really stressful.
        Python is conquering the world, there are 30 career programmers in Python and we will probably see Python programmers for another 60 years, this curve is attractive because it gives a guarantee of existence of greater life.
        VB.net has everything to be so too, but needs to separate from Microsoft where the important thing is ROI.
        If an active and loving community takes over VB you will never need to change dialect.
        Let’s hope and pray for the birth of a Beautiful, Enduring, Loving and with commitment highlighted on its first page saying that the VB.net is now perpetual .


  14. Pingback: New top story on Hacker News: The chronic suffering of the VB.NET community is not necessary – The Pakistani News Corner

  15. Hi Anthony,
    A lot of what you wrote I’ve already seen from a former Microsoft Employee who was, before that he had real seen it, very sceptical against VB. After real using it, he wrote “I love VB” and was going with that over the world to promote Linq and used promotion material with that “I love VB” text on it.


    Liked by 1 person

  16. Thanks for posting this. As a long time VB.NET developer for several different companies, I have always wondered why VB seemed to be losing it’s support at Microsoft.

    Having worked for a dysfunctional corporation for a short time, I can understand your observations.


  17. “In the beginning (VS2002-VS2008)” – In the beginning, VB.NET existed before C#. You had VB.NET and J# during the beta I started working with 20 years ago. When MS lost its court case with Sun, J# morphed into C#, and J# was left where it was, more or less, because newer Java versions could not be used.

    Initially in the VS.NET lifetime, VB was Bill Gates’ baby. As time has gone on, Bill Gates became less and less involved (now not even on the board), MS hired a much larger percentage of non-American developers and product/program managers, and in recent years, the bulk of MS’s developers have no memory of just how successful VB was, and how Rapid Application Development (RAD) ensured MS’s success in development tools (made possible by the VB team).

    So nearly 30 years later, we have great tools with Xamarin Forms, Blazor, etc., but no great designers as the foundation to make VS a RAD development environment again.

    VB gave us more than just a language (I use mostly C#, but started in VB, then VB.NET) – it gave us a truly RAD tool in the VB IDE and the VS.NET IDE. Now we are back to hand coding UI, like it was the 1980s again,


  18. Really thoughtful, informative and an important insight. Thank you for taking the time and trouble to write this down for the benefit of the rest of us.


  19. Wow, what a great writeup! And so universally applicable. As a longtime VB’r (started with MS Basic Compiler 1.0 on floppies) turned C#-er turned dev manager/consultant, I’ve seen this happen in a lot of situations/organizations. And not always software-related. People make a difference.


  20. Excellent article forged in the real world of experience.

    I hope that some good comes from you airing these thoughts. It strikes me that your analysis is accurate – it’s certainly convincing. It’s always been a bit sad that VB.Net struggles to overcome the notion of not being a proper language, which has a whole lot to do with the word “Basic”,and very little else.

    I’m not one to argue the finer points of why language X is better than language Y. It tends to assume that because one is “better”, the other is rubbish, as opposed to “slightly less good” – or even more likely, just different and fit for purpose. I have argued with usually intelligent peers that End If End For End If End While has a higher information content than }}}}. It does. The reply I typically get is – nah, it’s too much typing, not compact. The truth is simply that it does have a higher information content and it is more typing, but an amazing logical disconnect occurs. This example is not designed to demonstrate why VB is better than C# (I don’t do that). It is designed to demonstrate that bias often leads to a failure in logical reasoning and argument. I hope VB.Net continues on, but it will always be a struggle because of the word “Basic”. Forming a dedicated autonomous team within Microsoft as you advocate would certainly give it a fighting chance.


  21. I have been using Microsoft Basic development environments since QuickBasic 4.5, and up to visual studio 2005 and a little 2012. But for the last 4-5 years, I have been mainly using Basic4x (b4x.com) to write native Android and iOS apps in Basic.

    However, a new app I am working on needs a backend that can properly scale if there is huge demand from user’s of the app. So I was thinking about really getting to know how Azure works because from what I understand, it auto-scales.

    So, I wanted to find out which version of Visual Studio I should get to write some Azure database functions in VB.NET and could not find many official VB samples. Which lead me to this article.

    So, does anyone have any suggestions of which version of visual studio I should get and what would be the best vb.net “community” I should visit that would be the best help in finding azure samples in VB?

    Any help would be greatly appreciated!

    Keep safe and healthy – John


  22. Se cada usuário do VB.net doar mensalmente 1 dólar para a comunidade e 1 dólar para o ambiente de ensino da comunidade teremos em pouco tempo uma IDE VB.net


  23. Anthony,

    Beautiful text, Congratulations.
    Create the VB.net community, under the financial assistance of 1 dollar a month, which will see that we have a much larger team than the C # team from MS.


  24. If MS wants to abandon VB, then that’s their loss.

    MS failed me when I wanted to develop mobile apps in VB, so I switched to a great VB RAD tool and community that allows you to create *native* Android and iOS app without any “frameworks” like phonegap or xamarin using nothing but a Visual Basic like language!

    What is this magical development tool…….B4X.COM and it’s NOW free to write Android apps!



    • Surely the B4X.COM Community has to be part of this worldwide turn of VB.net which for me should be called VB Eterno! or VB # would also be nice!


Comments are closed.