"Switching customers to annual billing radically decreases churn, one of the key risks to SaaS businesses long-term."
Where I can I read more about annual billing decreasing churn? I've read your blog post (or email?) about switching to annual billing to free up revenue to acquire new customers, but I don't remember reading about how it decreases churn as well.
Dharmesh Shah has talked about it extensively -- basically, of people on monthly billing, at any given time approximately 100% are at risk of churn. Of people on annual billing, < 10% are at risk of churn at any given time. They also have less opportunities to hit involuntary churn like, e.g., getting a CC declined or expired.
One additional point: Customers that commit to annual billing generally tend to churn less often overall -- because they've made a more "considered" purchase and committed more time to the purchasing decision.
When I was teaching myself how to program in VBA, I remember thinking "there's got to be some syntax to take a list of things and iterate over each of them." I was of course looking for a for loop (or for each). Without knowing to even google "for loop in VBA", it was a pretty big deal to finally discover, "Hey, programming languages have loops!"
Later, after coding for a couple of years and picking up .NET, I eventually learned LINQ syntax and really started to appreciate the expressiveness of chaining methods together to iterate over collections. It was a nice addition to my tool box, but it still took some practice more me to grok it. If that had been my first exposure to loops, it likely would have been a stumbling block to my learning.
Chapter 12 was 'looping'. I'm not claiming I was some programming genius, but to have been given a computer with a manual that, in < 100 pages spelled out the basic constructs of programming logic... that was magical. And useful. And empowering.
I know we've all got the google at our fingertips today, but I suspect that many people don't even know how to express what they want to do in basic enough terms to search - thedailywtf has examples of that (sadly). I don't know if there's a way to reverse this, but it struck me that we've definitely lost something (or perhaps 'we' never all had it) when you state: 'Without knowing to even google "for loop in VBA"'.
"Becoming a good Visual Basic 6 programmer took much less time than becoming a good C++ programmer."
I love this line because it implies that you can actually become a good VB6 programmer. Sure, you may not be able to sort a linked list, but you can still learn about encapsulation and ... actually, just start with encapsulation; that's going to make your code SO much easier to read :-)
You either mean that it implies that you can become a good programmer while writing VB6, or that you can become someone good at writing VB6 programs, or that you can become someone who writes VB6 programs that are good.
Regardless of which of those meanings were intended, I disagree. I find denying any of the three to be dismissive and just plain wrong. I should be clear: I hate VB6. I really do. But I'd stop far short of the arrogant suggestion that it's not possible to do good work in it, or that it's not possible to learn an enormous amount about what it takes to make great software while writing it.
Sorry if my comments were confusing. I intended no sarcasm nor arrogance.
I started off in VBA hacking recorded macros. I would then write hundreds of lines of code into a single function (usually named "DoSomething" or something equally vague) and then I would live and die by the VBA debugger, tweaking the function when it broke. Over time, I learned the value of encapsulation and how much easier it was to debug my code if used smaller, well-named, functions.
When I started a different job and ended up doing a lot of VB6 programming, I ended up reading a lot of others' code. I would stare at functions that were literally 1000+ lines of code an painfully difficult to debug. The purpose of the VB6 code was to print barcoded shipping labels in a specified format, but the ZPL print instructions were heavily mixed with business logic. It was a nasty mess. The single greatest thing that would have helped me would have been encapsulation. Even if the developer hadn't separated the business logic from the ZPL code (which would have been very nice), small, well-named functions would have made the program so much easier to follow.
The reason I mention encapsulation specifically is because of how much you gain as a developer. If you learn nothing more than basic encapsulation as a VBA/VB6 developer, you'll do wonders for the readability and maintainability of your code.
That's probably because a good VB6 programmer would still be a terrible C++ programmer. There are too many ideas VB programmers will never encounter. In order to be a good C++ programmer you'd be a VB god (rolling out your own DLLs and OCXs).
I have done more than my fair share of VB programming from version 2 when it was new up until 98 or so. I even got my MCP certification on VB3... It was the quickest tool to build a Windows application at the time.
In fact, at least here in Brazil, the rise of Windows as a corporate OS coincides with a rapid adoption of VB for in-company development and the fall of Clipper under DOS. I saw it first hand because it happened while I was helping write a huge console-based app in Dataflex. The app is still used by more than a hundred municipalities in Brazil and I learned the master thesis of a colleague was about automatically porting it to something more modern (the project more or less failed).
> the rise of Windows as a corporate OS coincides with a rapid adoption of VB for in-company development
Also true of at least one place in the USA. A few thousand Macs went into the dumpster so they could roll-out shiny new VB client-server applications to replace terminal stuff. (Ironically, they were rolling out Netscape 1.1 at the same time.)
There's plenty of "VB Gods" around then. I suspect many C/C++ programmers one way or another found themselves working in a business that had VB as the shop standard? I know I did. I wrote good solid, readable, maintainable, stable code, including DLLs and OCXs - they're nothing special. Some of the projects I did are _still_ in use 10 years later at one location.
Was VB my tool of choice? Certainly not, but it was what I was required to use, with few exceptions. A good craftsman can succeed with an inferior tool. Just watch - The well crafted VB apps will have a half life similar to COBOL.
Most of the languages that have caught the public's imagination support and don't actively discourage developers writing really horrible code but then provide the facilities for people to use as they get better. Python, Ruby, PHP (especially), VB, JavaScript and C++ all come to mind in this regard.
I'd contrast this with languages that enforce a certain style or paradigm in an effort to improve reliability: Erlang, Haskell, Prolog, F#, Smalltalk (to a point). All fine languages but none have quite caught the imagination of the mass of developers.
I still have a soft spot for VBA, especially in Excel. I wrote a supply-chain management application in Excel+VBA that's still in production today. As comfortable as I am with VBA, I wouldn't mind in the least ditching it for Python, which makes writing routine methods trivial. Great work!
The site looks nice. Whether or not their methods are the best, I've worked for quite a few folks who would find their presentation very appealing. Because they've been burned by companies who wrote code for them that didn't meet their expectations, they're excited about a company that will actually listen to their expectations thoroughly before the process begins.
Professor Christensen gave this talk (or one very similar) at Business of Software this year. He was phenomenal.
One thing I like a lot about the culture in younger companies, especially in tech, is that while we are conscious of the appropriate financial ratios, we're not driven by them. For example, Fog Creek, while profitable, isn't driven only by profit, and happens to be passionate about giving developers a great place to work and helping developers create better software (among other things).
I will argue that establishing such a reputation, even at the expense of short-term profits, likely is profit maximizing. So, you are profit driven -- just in a way which also happens ot feel good ;)
This seems like a relatively simple business proposition to a client. "X% of users on the internet today use IE6. I will be happy to provide pixel perfect support for Y dollars." Adjust Y up and down based on your ability and desire to continue to support web applications that use IE6.
Where I can I read more about annual billing decreasing churn? I've read your blog post (or email?) about switching to annual billing to free up revenue to acquire new customers, but I don't remember reading about how it decreases churn as well.