February 2013 Blog Posts
Delivery vs Quality

I realize that just about anybody reading this will immediately think “but we can have both.”  I understand that.  This is just an example.

At a client once, I came aboard with a bunch of other consultants around the same time (sometimes organizations do these weird things like letting entire groups of consultants go, along with their gained knowledge, and then have to pay the cost of having that knowledge needing to be relearned.  There are ways that organizations can learn to do such things better, but I digress).  With a large installed base of applications, various consultants were given various of these applications.

It’s always fun to think that your inherited application is the worst written application of all time.  It isn’t always the case, but there are certain things that always jump out at you.  I wonder if there is a term out there for an application that appears to want to violate Separation of Concerns in as many ways as possible.  Let’s posit that some of these applications we inherited followed that ‘pattern.’

One developer decided that, in order to promote the long-term health of their application, it needed to be significantly refactored, in the usual sense of the phrase: Adding little to no new functionality while fixing the broken internals to increase its maintainability (in some sense of the word).  Since I don’t want to debate their refactoring ability, let’s go ahead and accept that what they did was a significant improvement.  There were actual ‘metrics’ available, such as a reduction of the size of the code base by something amazing like 90%, a consolidation of the various random technologies used to a consistent few, and other things that from most perspectives can only be viewed as positive.

Another developer focused on the ‘business state’ of the application.  In particular, he knew that the business users were very frustrated at what they viewed as a lack of progress in the progression of the application.  Business requests were stagnating.  This developer decided to focus on identifying the highest priority business requests and implementing them, even though the ‘nasty’ state of the application made that, well, difficult, to say the least.  Can anyone say ‘copy and paste?”

Now, everyone knows where I’m going with this.  In six months time, the refactored application had zero releases, while the nasty application had three. 

One of the things that has always struck me is that ‘unmaintainable’ applications actually are.  It sucks to high hell to have to do it, but it is remarkable how much bad code is fairly supportable.

Delivering high-quality code often is an admirable goal to strive for.  When starting ‘from scratch’ it is much much easier to achieve this.  When supporting a ‘legacy’ app (meaning, any app I didn’t create), sometimes you may find yourself making choices you wouldn’t otherwise make, and justifiably so.

posted @ Thursday, February 21, 2013 11:44 AM | Feedback (0)
Turns out, NPM kinda sucks as well

So, for some project, it turns out that I’ve gotten to take a look at all of that Node.JS love.  That in itself is another story.

As it turns out, I needed some specific modules that sat on Github.  Being total newbie, I figured you could just download stuff from Github and it would work, but of course, it generally almost never works that way.  You do some “npm –install <module name>” magic and everything goes swimmingly.

Or not.  I’m at a location that has whatever port npm needs blocked at some firewall, so I need to use my own laptop and figure out how to get it to work later.

So, in my case, I try to do that, but there’s a build step in the middle of it, which fails because it requires Python.  Okay, so I go download Python, that should fix it.  No, wrong version of Python, can’t use 3.x, have to use 2.7.x.  Uninstall wrong version, install right version, that should work right.  Right?  No, I don’t have Visual Studio 2010 build tools installed on my machine.  Ok, that’s great.  But, installing Visual 2010 C++ 2010 Express is a valid option, let’s go ahead and install that, that should work, right?  No, I have a 64-bit OS, and the solution file expects 32-bit.

Sigh.  It should not be this hard.

Wait!  Out of frustration, I find someone else online who has had similar issues, and he has compiled binaries!  Fantastic!  And it comes with a test.js file, awesome!  Download, run node…..nope, throws an error.  Trace the error online, I need to build it myself.

I think I’ll go have a drink.

posted @ Friday, February 01, 2013 5:09 PM | Feedback (4)