I was sitting at an airport café last week while waiting for my flight to board. I noticed that my drink had a QR code on its packaging. Then I thought, “Wow, they’re still doing that?”. I hurriedly got my phone to scan it. Turns out I didn’t have a QR code reader on my phone. So, I had to go to the app store, download the app, launch it, and finally scan the code. It led me to a website that showed all the nutrition facts about my drink. This got me thinking, “Why did I have to go through all those steps to see that information?”

I recently finished reading The Phoenix Project by Gene Kim. It's a fantastic book discussing the challenges and foresight needed to survive in today's corporate IT world. The story is told from the perspective of Bill, a fictional character working as IT manager at Parts Unlimited.

Last July 21st, DigitalOcean started having a few issues with their New York based data center. They kept customers updated using their status page. They sent out an email to all their customers today explaining the issue in detail.

Software deployment requires a lot of moving parts, from source code repositories to automated testing to monitoring and much more. It is no longer the case that write build code and copy it into production. In this post I discuss five ways to improve your software release cycles.

$3 Billion is the confirmed price tag that Apple paid to Beats Electronics and Beats Music. It seems to be a purchase of contradictions. The iPhone design seems to clash with the flashy appeal of the Beats headphones, and the music streaming service of Beats is a fraction of the size of Spotify. But digging a little deeper, and the buyout starts to make sense.

The common mantra of open-source advocates, myself included, is that when the source code is available, the code is better. Transparency allows the code scrutiny. The nature of the open source community would, by definition, root out any bugs and security flaws which help improve the software. The recent Heartbleed bug of OpenSSL was a strong reminder of how wrong this assumption is.

It's been nearly two months since Satya Nadella became the CEO of Microsoft. Since then one of the major releases from Microsoft was OneNote for iOS and Mac, and Office 365 for the iPad. Microsoft actively building software for devices of the competition highlights a new strategy, removed far from Steve Ballmer's original roadmap. Here are the two strategies I believe are the future of Microsoft.

I currently mentor a small software development team composed of a project manager, one mid-level developer, a junior database administrator and a quality assurance specialist. For the last month I’ve been exploring methods to increase their productivity using RescueTime.

So I'm a little late to get on the Apple's latest operating system - Mavericks. It's got fantastic reviews, and it's been out for exactly 3 months. I got me thinking, why do I hesitate when upgrading software?

Trello is a free (with paid options) web application by Fog Creek Software released in mid September 2011. It has since gained a massive user base. The following guide is about how I manage team projects using Trello and Test List Software Development.

When developing software, the flow usually starts from a list of features. This features list gives the development team a general idea of what need to be coded. Testing is done after coding and the code is adjusted based on testing. This approach puts testing as an after-thought, often leading to bugs down the line.

Here's a popular motto: "Under Promise and Over Deliver!" It's said with a level of enthusiasm that encourages lower expectations yet yields higher output. Yet I consider this a terrible motto in the world of software architecture. The client world will immediately see this as the norm rather than an once off event.

Modern software development is a combination of structured code, databases spanning a large number of interrelated tables and deadlines due yesterday. Today I'm going to discuss the Model-View-Controller architecture of organizing code.

The corporate world always has one more thing they need from of your application. This usually begins in the planning stages where all the stake holders are brought together to help scope out the project. A small feature request here, another critical functional requirements there, coupled with the most demanding stakeholder rallying for a specific feature, and pretty soon this becomes an bloated project scope.