When is code good enough?

-
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, as 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 some of that "cleaning up for the sake of cleaning up" and let the testing continue as necessary, but I'm finding it difficult to do. 
With the bugs that I do find, in most cases, I have *not* included tests (shame on me) due to the complex nature of the code and little time to refactor something of that magnitude. You see, we're getting down to the last few weeks of testing before pushing this beast to production, so I'm doing my best not to tweak code. 
During this time, I am finding my OCD tendencies are difficult to repress. The thing about the post from jQuery, however, makes me feel a little bit better about not getting the codebase to complete bug-free as that's a Utopian place that might never be found. Anyway, I'm feeling a bit more relieved about the current state of affairs with regard to the code I've been working on for the last year or so. However, that doesn't make me any less nervous about pushing this thing to production...

Comments

Post a Comment

Popular posts from this blog

Using Bogus to create Hierarchical Data Structures

-
I was recently asked to create an API for retrieving multitenant data. The actual implementation requires a LOT more work than I have time to complete, so I thought I would create an API with some faked data. Now, at first, I was tempted to grab some data from one tenant and serialize it into a fake service that essentially hijacks the process, returning pseudo-random data. THEN I remembered working with a class library called Bogus . This is a cool library that "generates" random data of all sorts using a fluent interface. You configure the rules using lambdas and then call methods to generate the classes. This is very straight forward for simple POCOs and works great. However, I was trying to create an object graph, essentially, with hierarchical data. Objects at the second layer need to have a valid reference to objects at the first layer. Third to second, fourth to third. That way, you can query down the chain or get objects at the next-level-lower that have references to...
Read more

Adventures in Getting a Site Hosted

-
A couple years, I decided that was the year I was going to finally get a website setup. Fast forward to a couple days ago and that's how long it took me to begin executing on that plan. I tend to be afflicted with Paralysis By Analysis when it comes to something that I don't know how to start. Rather than just try, I think of all the ways it could fail. I know this about me and I also know that it's debilitating. Sometimes the debilitation wins. Sometimes I roll up my sleeves and get my hands dirty and break shit. The latter is almost always more rewarding than the former, yet the internal struggle remains.  But enough with the meta-crap, this post is meant to explain my approach to getting my domain name hosted with something. I've had this Blogger account for several years. It's free. It's easy. It's a little too easy to ignore, so I'm thinking I may resurrect it a little bit and start writing about my goings on as a mechanism for growth and learnin...
Read more

Design Patterns: An Introduction

-
I'm refreshing my memory about software design patterns by watching some videos and taking some notes. I thought I would document them here for future posterity. These are the design patterns as defined by the Gang Of Four (GoF) in their seminal book "Design Patterns: Elements of Reusable Object-Oriented Software" and can be found on Amazon (non-affiliated link) . Some of the things I'll be posting will be related to the various categories of design patterns (as defined by the GoF): Creational, Structural and Behavioral. They are broken down like so: Creational Abstract Factory Builder Factory Method Prototype Singleton Structural Adapter Bridge Composite Decorator Facade Flyweight Proxy Behavioral Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor I will try to break each of these patterns into sections: Intent, Structure, Example. For those following along, I'll have the code for these examples ...
Read more