Well, after digging into some IL, it turns out I wasn't wrong.
no, i'm not serious
Moral of the story, always make fun of your simple programming mistakes. If you get too caught up in being perfect, being a developer will stop being exciting.
By now you've hopefully heard about and understood the new features launched today by the Visual Studio team at the Visual Studio 2013 launch event. Among time savers like sync'd environment across machines, live preview scrolling (though, why is your class that big to begin with), and peek into definition, you probably heard the most about Visual Studio Online.
Getting light weight apps into the cloud is not a new trend. Google did it with their Google Apps, Microsoft did it with Office365 and now Visual Studio Online. With this move, Microsoft will be taking development shops to a whole new level, both with convenience and cost savings.
Have you ever found yourself with a production level issue on your site that required you to wake up in the middle of the night? Groggy and sleepy you head for your desktop computer, wait for it to power on, VPN into your corporate network, RDP into your work computer or Azure instance, check on some logs, hop into your Visual Studio, make the changes, and fire off a hot fix. We've been there... and there stinks.
In comes Visual Studio Online and the potential it brings. Let's take that same scenario. You're still groggy and sleep, but this time you lean over and grab your tablet which, if you're like me, is right next to the bed. A few logins later and you've got the problem and the fix all through your browser.
There is one thing about being a developer that I hate - the size of my laptop. It's not even a laptop anymore, it's a portable desktop. I need the power. I'm a spoiled little brat with the amazing dev desktop machines that I have and I expect nothing less than when I sit down at my laptop to write code.
The laptop is huge and heavy, and now that I travel more I hate it! You ever try to crack open a 17" laptop in an airplane? Don't.
One specific tool stood out to me from the VS2013 online announcement. Online IDE. This means that I don't need a powerhouse of a laptop for fast compile times anymore, because I'll just compile it in the cloud. If I want to pick up my tablet and start cracking away at some code, I can!
I went to school to get a bachelors degree in art. Every professor I had encouraged us to keep a sketchbook with us all the time because you'll never know when an idea will hit you, or a burst of creativity will consume you. Is software development really that much different? A cloud based IDE gives us the ability to keep our sketch pads light and always with us.
There's a general aura about testing in software development. The tests themselves can be arduous and painful. The people who create them can be stuffy and sometimes pompous. The results that they generate can be demeaning and bring you to your knees.
Very few software engineers would actually take bug fixing over being able to create new and exciting things. There's something to be said for the adrenaline that get's pumping as you are smashing keys to pump out something that no one has seen or done before... that moment when you throw your hands in the air and clench your jaw to hold back the "I'M A GENIUS" yell though the office. It's what we, as engineers, live for.
Testing forces you to put your arms down, tuck your tail between your legs, and, if you haven't bought on to TDD, start plunking out unit tests to prove you're a genius. Why should you have to prove it? It's right there in the code.
Then, if you're ever so unlucky, you've got to hand your code off to the tester who was just good enough to write code to cobble together some automated tests, but not as good as you, the almighty developer. At best you'll get a few bugs about a random race condition and at worse you'll get a handful of "bugs" which is really just the tester being an idiot.
I bet that's how some of the developers working on healthcare.gov thought.
If you've stayed on top of any of the news around the healthcare.gov failed launch, you'll see two reoccurring themes.
1. A lack of testing
2. Last minute design changes
There are a lot of moving pieces to this web app with multiple intregration points into a lot of archaic systems. No doubt thin access layers had to be built on top of these archaic systems to even get the site to be able to talk to them at all but then when you start trying to manipulate the data on those systems, you're just asking for trouble.
Of the two themes mentioned above, I'm a firm believer that last minute design changes should never be a reason for a lack of testing. Whenever you hear "we didn't get enough testing because of these last minute changes" it purely means that your testing strategy was flawed or non-existent to begin with. The private contractors knew what the overall goal of the site was supposed to be. A proper test strategy should have been agreed upon even before development work started. The governing body (HHS and CMS) who was overseeing this gargantuan effort should have been completely aware and comfortable on that strategy as viable and all inclusive to their goals.
When you have a well thought out test strategy, these "last minute design changes" become mere tweaks to the already implemented test strategy. Yes, there is some effort to tweak the strategy, but it certainly won't be to the level of avoiding testing all together.
I'm floored by the statements from the contractors that they started testing just days before the rollout and that "the HHS and CMS were responsible for end to end testing"
What?! Since when in the time of software development EVER has the client been responsible for end to end testing of the application YOU wrote? This is a clear sign that there was no test strategy created by the contractor... which is a clear oversight on their end. Unfortunately, instead of admitting that they botched testing from the start, they resorted to the blame game.
Would it have been different if the end to end test strategy was in place early? I'm convinced that October 1, 2013 would have been a much different launch date if it was. At least it could have handled more than 200 users.
I wrote my first web app as a 12 year old that handled more than 200 users.