The Illusion of Code Quality

Code quality is something that I believe every developer strives for.  We want code to be the best it can be and there are tons of opinions on things developers can do to make quality high. Over the years as teams have moved to Agile from Waterfall, and as build and test automation has become better, a lot of the code quality metrics that experts have developed are becoming less helpful, or, dare I say, counter-productive.

The larger a team gets, but more importantly, the higher turnover gets (developers leaving the team/company and new developers without context come on to the team/are hired), the harder it is for code to remain high quality over time. We’re all human, we can’t keep everything in our head, we can’t mind-read the original developer who left the company and wrote this code. The worst part is that we don’t know what we don’t know. We duplicate effort because we didn’t know there was a design document on Box, or we don’t go update it.  There’s also setup information on the Wiki that should be changed, but we’ve not asked anyone where it is yet, because we didn’t know to, so our sweeping changes to the project aren’t reflected there.  We’re also on a deadline, and there were already existing comments that StyleCop saw, and it can’t automatically tell me that something in my code is now out of sync with the comments, so now developers can’t make any assumptions about the comments being right.  Any of this sound familiar?

That’s ok, though! That’s human nature! We aren’t computers (I’m glad we’re not) and we’re not good at keeping documentation in sync, especially when most teams now use Agile (I say that loosely), but still carry assumptions over from the Waterfall days that are literally duplicated with automation today.  So what should we do to help keep down the illusion of quality and actually introduce REAL quality into our code? (more…)

Synchronize Node.JS Install Version with Visual Studio 2015

Visual Studio 2015 is out for download now (and free for individual use)!  It’s been so great to have integrated Grunt and Gulp support, and ES6+ features.  In addition, Visual Studio 2015’s installer has an option to install Node.JS as part of its regular install in order to support the Gulp and Grunt task runners that are built in.  However I ran into an issue today in which I updated Node.JS outside of Visual Studio, but since VS uses its own install that is separate from any outside installation, you can potentially run into a node_modules package dependency issue where one version of npm installs a package (which makes it rely on that version of Node/npm), and then you can’t run commands in the other version (they break).  Specifically, I had an issue with node-sass and windows bindings.  The solution was to point Visual Studio to the version of Node.JS that I had already set up externally to Visual Studio.  Here’s how to synchronize them: (more…)