Movember: End of Week #1 and a Client Launch

Well, it’s one week into Movember and three of our engineers, including myself, have joined the team.   It’s too late to join our team, however if you want you can still donate.  We’ll continue to provide an update each week.

Here we are this week.  Let us know which week you think will be the best mug shot and who has the best ‘stache:

daum jared ashish

On a side note, we’d like to congratulate DiscoverE on a successful launch earlier this week.  We helped the DiscoverE team build their entire site which aggregated a number of old sites they had.

Tips: Small Business IT Best Practices

I’ve worked with a number of start-ups and young companies over the years and one thing I’ve noticed is that it is quite common that a smaller company does not think much about their IT.   They are not insuring that it is properly structured, safe, and reliable.  The smaller companies can become so focused on their product/business that they forget to make sure their underlying infrastructure is solid. Companies place all their energies on their code and their code quality; however, often overlook equally important setups:  such as, the servers that run the code. Here are some of tips I frequently give companies.

Where is your code?

Small companies are often focused on making sure that their product is bug free, or doesn’t crash in certain browsers, etc. However, if tomorrow their outsourced developer disappeared or their server crashed, they might not have access to their code. I recommend that companies keep a hard copy document stating how to recover the code, which is in turn backed up across multiple company computers in which multiple people have access.

Knowing how to recover the code without outside help is critical. If the outsourced development firm/developer disappears, there is a conflict, or any other reason they are unreachable or will not cooperate, it is important to be able to have access to the code. Far too often outside contractors disappear and I’ve seen companies stuck being unable to get their own code.

Making sure there is always access to the up-to-date codebase, will save the headaches later. Also, the current developer won’t be needed to ask for the code if you want another developer to work on it or do a code review.

Where is your database?

Similar to above, what happens if for any reason (server crash, hackers, an act of God, etc.) your production database disappears? Do you and your colleagues know where to recover the information?

Often data is the most valuable possession of your business. Being able to recover it is critical. If you can’t recover any of your data, it is very possible that will be the end of your company. How often should you back your data up? That depends on your business. Some companies a daily backup will be plenty, however for others such as companies which pay people to take surveys, losing a day of data could equate to tens of thousands of dollars lost. This is something you’d need to discuss with your colleagues.

Another important part of database backups is making sure that they are stored for long enough. If you only keep one backup which happens at midnight each night what happens in the following situation? At 11:59 PM one night your database is compromised and most of the data is corrupted. That night when your backup runs, it will erase all your data.

Nowadays, data storage is very cheap (under 9 cents per month per GB), so keeping backups for plenty of time is well worth it. At a bare minimum you should make sure that your database backups are kept long enough that you’d notice any problem with the data before the oldest backup is removed. For example, for a forum you may want to keep at least 2 weeks of database backups. If someone deletes data from your forums, you’d most likely notice it within 2 weeks and can recover it. Again, data storage is cheap so keep backups for plenty of extra time (or forever).

Server Configurations

Using the cloud? Your own private hardware? Either way, an often overlooked backup is the backup of how your servers run. Without a server to run your code and serve your data, the other two become insignificant. Keeping up to date backups of your server configurations are critical. You need to make sure that you can always recover a failed server.

I’ve seen several Amazon EC2 instances fail. With the failure, sometimes companies are left scrambling to figure out how to get their site or product back online. How long can your company afford to be offline? If over an hour is too long, make sure that you always have up to date server images that you can immediately boot.

If you don’t have any documentation of how your server is setup, it’s likely that when it crashes you may not be able to get back online quickly. It’s even more likely you’ll forget different settings that will continue to cause the product or site to not fully function correctly.

Aside from keeping a backup of your server configuration, having access to the server permissioned correctly is equally important. An example of what I’ve seen: A company hires a new contractor who they want to work on a development version of the product while the main developer works on a different feature. The contractor mistakenly runs the wrong command on the server and wipes out the entire site. This happens all too often and is narrowly avoided at other times. Making sure that different users only have access to specific environments (such as the development environment above) on the server is very important. Everyone should have their own logins to the server so that you can remove any user without requiring everyone to know the latest password. I also recommend always using SSH Keys, they make weak passwords irrelevant and the server more secure.

Have a Written Disaster Plan

I’ve listed out some key tips above for how to keep your business running properly. However, all these should be summarized in one document. The document should be backed up itself and accessible to multiple people in your company which you trust. If something happens to you, you don’t want it to ruin your entire company, so distribution of the disaster recovery plan is critical.

Making sure you understand the plan and that the plan is effective is equally important. At least once a month it makes sense to go through the plan, make sure it is up to date, that all the different parts are actually working (you aren’t backing up a blank database due to a typo), and doing the steps to do a recovery.

While planning for disaster, failure, and unforeseen events takes time, it will pay for itself when something goes wrong.

Have any questions? Shoot me an email with any questions!

Happy Movember!

Happy Movember all! This year some of us are participating in Movember. Movember is where you grow a moustache to support men’s health. Each week we’ll be taking a picture as our moustaches grow and are shaped into beautiful sculptures.

Our team page show’s some updates, how much we’ve raised, and who has joined our team. Join up with us or donate to the cause!

Here are the three mugshots of us who are participating (smiles not allowed) so far:

ashish jared daum

Here’s to a great Movember!

Tech: Three reasons healthcare.gov failed all of us

Since going live early this month, Healthcare.gov has been universally panned for being unstable, unusable, and close to an outright disaster. As the publicity of the problems have intensified, it’s become clear that the project has was mismanaged and probably sloppily developed. The team certainly faced daunting challenges like going from 0 to full capacity overnight but with a reported budget of over $50 million dollars and three years to execute it’s hard to have too much sympathy. Anyway, without knowing the project guidelines, business constraints, and other considerations it would be irresponsible to armchair quarterback and predict technical decisions that would have performed any better. However, on the non-technical side there are some strategic and architectural decisions that are disappointing.

The Team

Like any large project, the success of the project is ultimately driven by the strength of the team behind it. The experience, structure, and mindset of the team building the project will be the key drivers for what tradeoffs are made, how things are architected, and of course how development is executed. Unfortunately for us, according to the Washington Post, CGI Federal the company that built healthcare.gov is both a relative newcomer to US government IT consulting and also has a spotty track record of building large, commercial web applications.

I’ll be the first to admit that I have no background in government procurement, but it strikes me as odd that the Obama administration didn’t handpick the team that was going to build the software for their watershed legislation. Most notably, since the sweeping democratic win in 2008 has largely been attributed to the Obama campaign’s exceptional technology resources. Brad Feld actually suggested bringing in Harper Reed who served as the CTO of the campaign to fix the problems, but why wasn’t he leading the project from the outset?

Transparency (or lack thereof)

For an administration that campaigned on transparency (lets ignore NSA/drones), the lack of transparency surrounding healthcare.gov has been severely dissapointing. The lack of information has left media outlets reporting outlandish claims like that the site is 500 million lines of code or that Verizon has been brought in to help triage the situation. Apart from technical details, the White House has also remained completely silent on visitor and enrollment statistics even though they clearly have them since the site is running a slew of analytics and monitoring services. Leaving the public in the dark has driven rampant speculation and left everyone wondering “What if they aren’t releasing data because its THAT bad”.

Another area where healthcare.gov has been dissapointingly secretive is the actual source code of the project. Although some people, including Fred Wilson, are recommending open sourcing the code as a potential triage measure the code really should of been available from the outset. Even if the proprietary licensed technology had remained private, tax payer dollars financed the site and open sourcing it from the outset would have added some much needed oversight and accountability. Looking at the site, its using several open source libraries anyway including Twitter Bootstrap, jQuery, BackboneJS, and apparently violating the OSS license for jQuery.Datatables.

No Plan B

One of the accepted truths in software engineering is that shit is going to break and that bugs will crop up in even the most heavily tested applications. Mix in things like legacy integrations and 3rd party APIs and issues almost become a guarantee. Despite this, looking at the rollout of healthcare.gov it’s clear that the team had no contingency plans for how to handle various error scenerios. As pieces of the application started to fail, they didn’t have any way to mitigate poor user experiences, losing data, or simply showing “fail whale” style error messages. And although bad at launch, the situation still seems just as bad 3 weeks later – with their band aid to simply boot users once they’ve reached their concurrent session limit.

Building a high traffic web app that interfaces with legacy systems, is highly available, and is also easy to use is undoubtedly still difficult but the failures of healthcare.gov haven’t just been technological but procedural and organizational as well. Hopefully someone has the experience and political clout to right the ship before the website’s troubled launch defines the healthcare law it was built to implement.

Microsoft & Nokia: Haters Gonna Hate

On the East Coast, most of us woke up from a long weekend to news that Microsoft had purchased Nokia’s mobile hardware manufacturing business. The news didn’t exactly come as a shock, given that the companies had announced a particularly Microsoft friendly operating agreement where Nokia Lumina phones would ship with Windows. What did surprise me was the general skepticism and outright negativity surrounding the deal. From Fred Wilson to the several threads on Hacker News, it seemed like everyone was happy to discount this deal as DOA and go back to arguing about Android and iOS. Personally, I wouldn’t immediately count a combined Microsoft & Nokia team out of the mobile fight for a couple of key reasons.

Consumers are fickle and upgrade cycles are short

This point was brought up on Hacker News and I think it’s one of the key points surrounding this discussion. Consumer attitudes and loyalty surrounding consumer electronics have historically been fairly transient. Six years ago, the iPhone was just hitting store shelves and every teenager was clicking away on a Blackberry. Contrast that with today, where RIM is largely an afterthought and Apple is clearly the dominant player. Discounting that a combined Microsoft/Nokia team could make significant inroads

Along with volatile loyalties, consumer electronics, especially mobile phones have a short upgrade cycle. Compared to desktops or laptops, most American consumers predictable replace their cell phones every 2 years because of free carrier upgrades. Because of this, the mobile phone ecosystem has the potential to change and evolve at a much faster pace than it’s predecessors. This tight upgrade cycle benefits Microsoft/Nokia since it gives them the opportunity to iterate and improve devices much faster than say in the console market where Microsoft has previously used this strategy.

Developers care about install base but it isn’t the only thing

Several comments around the web today pointed to the staggering number of iOS and Android devices already in the wild and made the contention that it doesn’t even make sense for Microsoft to compete. Their primary contention was that since users select a mobile OS based on available apps and developers will only build apps for the biggest platforms there’s a vicious cycle of the less popular platforms not garnering developer attention or user adoption.

The absolute number of available devices is obviously important to developers but it isn’t the only thing they care about. Resource constrained startups are still often building iOS first or iOS only and even larger companies also sometimes focus primarily on their iOS builds. Reasons for this range from everything from the lack of device fragmentation to the engagement and willingness to spend of iOS users.

A combined Microsoft/Nokia should be able to control device fragmentation and also have the software engineering chops to create a best in class toolchain. Visual Studio is generally regarded as a fantastic IDE and if Microsoft can parlay it into creating a true “mobile first” IDE I think they’ll be able to attract developer talent. Another interesting angle is what approach Microsoft takes with HTML5/JS, especially “crossbuild” tools like PhoneGap and Titanium. Playing from third place would give the combined Microsoft/Nokia ample reason to support these crossbuild tools to get more apps onto Windows.

The Living Room and Facebook

It’s becoming clear that the “battle” for consumer living room’s is far from over. With the proliferation of InternetTV devices like the Roku and AppleTV to the announcement of next generation consoles, it’s clear that companies are still very interested in “owning” the living room. The lay of the land is also constantly changing as companies move throughout the value chain. So where does that leave Microsoft? Well its not clear. There’s clearly a lot of XBoxes in living rooms and they’re years away from having any unified mobile + living room experience but that could ultimately serve as a key differentiator and bargaining chip with content owners.

Facebook has always wanted deeper integration on mobile and their Android Home app only solidifies that fact. Microsoft and Facebook also share close ties, Microsoft was a large, pre-IPO investor and Bing is currently powering Facebook’s web search. Given this close relationship, it seems obvious that the two companies would work to tightly integrate Facebook into a phone that was developed in-house. The results could obviously go either way, but there’s no denying that social has helped drive mobile adoption in the past.

However, despite their combined potential the two companies are still facing frighteningly large challenges. With Balmer’s announced departure, the biggest one is certainly who is qualified and willing to lead such a large, multifaceted, corporation down a path that will certainly involve uncomfortable if not downright impossible choices. In any case, consumers and developers shouldn’t count Microsoft out just yet, if nothing else to prevent a Goolge/Apple duopoly in the mobile space.