There's no I in Interface

The most recent blog post about the newest release of jQuery got me thinking about some of the code I've been writing. In the post, they have this little gem: We don’t expect to get any bug reports on this release, since there have been several betas and a release candidate that everyone has had plenty of opportunities to thoroughly test. Ha ha, that joke never gets old. We know that far too many of you wait for a final release before even trying it with your code. So now there is really no reason to wait, and you can find out if there are any bugs you could have reported earlier. I've been searching high and low for any anomalies in the code and when I see some code that's not "up to code" I reformat and refactor as necessary. Which is to say, a s I find bugs, I've been getting them fixed, but at other times, I'm simply making changes to the codebase to adhere to a particular style that I've been working toward. I suspect I should probably stop so...

I've been working a lot with some copy and pasted legacy code. It's rife with poor coding conventions (read lack of ) and "let's get it working first, then we'll go back and do it right." Unfortunately, as everyone knows (except those who speak those words) those days never come. In Michael Feathers' book Working With Legacy Code , he calls legacy code "code without unit tests." The code I've been working on definitely falls in that category. Due to the nature of the code, I'm finding it very difficult to write unit tests for it. Combine that with the fact that I haven't read all of Michael Feathers' book, it makes for some pretty challenging days spent looking at this debacle. In refactoring some of the code in an effort to better understand what the code is doing, I've found ReSharper to be extremely valuable. I'm so glad I splurged for that software. Hopefully some of the minor changes I've made to the code will ...

The newest project at work is an MVC app and I can't wait to get off the web forms train! The separation of concerns, the testability, the simplicity of coding at the metal level (assembler programmers, please be kind). I've been reading up on some JavaScript and have come to believe it will be just as important in the future as my C# skills (which could also use some work!). Fortunately, the MVC app will allow me to do both JS and C# so I'm super excited about that. I'm also super excited to be working with Rex Morgan and Jason Harper . These two dudes have the mindset that I tend to believe is the "correct" one...whatever that means. In any event, I can't wait to get started. I just have to get my existing app out to production first...

So, the other day, I heard the phrase that code is expensive. Indeed, with the current state of our software that I have been tasked with maintaining and writing, I would definitely call it expensive. All the code we've written so far, and much to my chagrin, is pretty much procedural code. It's difficult to maintain, the code base keeps growing ever larger and any changes are not at all guaranteed to work if any additional features are added. This makes it increasingly (probably exponentially) more difficult to maintain and/or add more features. So, yes, I would definitely say the code base we have today is a liability. This past week, the powers that be arranged to have Uncle Bob come in and give a 3-day seminar on Clean Code. If you haven't read Clean Code, and you're a programmer, do yourself a favor and add it to your reading list. ( You DO have a reading list, right?? ) While Uncle Bob has some contentious views on how code should be approached, he backs it up wi...