Where are the Simpsons? My wife might have the solution

So my wife is probably one of the coolest geeks I know. Would you like to know why?

We were just watching the intro for a new episode of The Simpsons where Comic Book Guy ate a dinner, and finally was given the bill which showed, among other things, the tax. So, she pulled out a calculator, figured out the food service tax percentage, and went straight to Google to see which state Springfield is in.

Does anyone know which State has 8.24% food service tax?

When to refactor, and when to slash and burn it

Slash and burning in BrazilImage via Wikipedia

I’ve said it many times before, but as programmers we tend to spendthe bulk of our time working with broken software, and we try to endeavor to make it less broken. When it’s not broken enough to keep people from using it on a day-to-day basis, you release your software. Some places do this better than others, and at my day job we’re really good at it. We are very dilligent about our software releases, we have tons of unit tests, system test automation, a nightly test “dashboard” that shows us how well our tests passed, and so forth.

But even though we rock at our tests, regardless, there are things that we would like to have work better than they do now. That’s what differentiates players in the marketplace. You can have a product that works, but if it doesn’t work as well as your competitors, or it doesn’t solve problems your customers have, then you might as well not be in the game at all.

When to refactor?

So when do you refactor your code? When do you decide that what you have could be improved and you should change the way it functions? Usually this happens as a customer suggestion, request, or demand. Product management may decide that a feature should be added, or an existing feature should be improved. That’s when we programmers dive in, and change what’s there while trying not to break it. Hopefully, in the process, you’ll come out the other side with better test coverage, and will have or improved the code around the areas you were working.

Sometimes this isn’t enough though. What if fundamental design decisions about the section of code you’re working on isn’t up to the task of the refactor? Or perhaps the code has just outlived its usefulness, and needs to be thrown away with the bath water?

When to throw it all away?

Inevitably we just need to set fire to the whole thing and write something new in its place. Slash & burn. This is the decision I’m faced with now. We have a feature that hardly any of our customers use. Some people say it’s because other sections of our product work so well, that this troubleshooting interface just isn’t all that necessary after our customers gain confidence in how well our product works.

I personally think people don’t use it because, well, it’s slow and ugly. It works perfectly well, and all of our tests confirm that it works exactly as designed. But I think the design itself is flawed. Plus, there’s tons of additional features we could develop on top of this code if we re-wrote it.

Why haven’t people asked for this rewrite though? Well, because they frankly haven’t thought of it. As developers, we know more about what is possible and what is there, and it’s our duty to let our users and product management know what could be made possible.

I just had a long chat / discussion / argument with one of our product managers. In the end, I had him excited about what we could build…but it took a lot of convincing.

Frankly, I’m not happy if I just build the features fed to me through the management pipeline. I’m an inventor at heart, and I’m just not satisfied if I’m doing just I’m told. If you give me an established product, with a large customer base, and a sales force that is poised to strike when they get a feature with which they can hit the pavement running, I’ll come up with a ton of ideas to make that happen.

I suppose what I’m saying is it’s not always the right decision to do the obviously safe approach. Sometimes you just have to set fire to something that, on the surface, looks healthy and “good enough”. Learn from what you have, and replace it with something 10x better. From the ashes, hopefully you’ll build something that nobody else in the market place has. From that your company gets a competitive advantage, and as an inventor, I get personal satisfaction that I’m making our product better, and am earning my keep.

WebDev Links Of Interest, Issue 1

I keep finding amazingly good blog posts or links of interest that I end up bookmarking for my own uses, but I end up having to tell people on a case-by-case basis why one article is good for one reason or another. I end up bookmarking on my Delicious account and sharing blog articles I like via my Google Reader account, but it’s becoming increasingly obvious that this isn’t enough.

So instead, I’m going to write a weekly (hopefully) article on links I’ve come across and why they’re cool. So, without further ado, here’s the first installment of Links Of Interest.

Object-Oriented CSS

I came across a link from Ajaxian, which talks about Nicole Sullivan’s work on Object Oriented CSS. Here’s an excerpt:

How do you scale CSS for millions of visitors or thousands of pages? Nicole first presented Object Oriented CSS at Web Directions North in Denver. Since then, the response has been overwhelming. OOCSS allows you to write fast, maintainable, standards-based front end code. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

The idea is intriguing. I’m curious to see how it can be applied to mobile iPhone development. The important thing though is that most people get web development wrong. Either JavaScript, CSS, semantic markup, or all of the above. I even know people who still do their layout with tables!

Typically when you consistently find a problem with development across a series of projects, the problem is most likely you, or at least the way you’re doing things. Take a step back and re-think the problem, and re-educate yourself on best practices.

There have been articles across a number of respectible web development blogs talking about writing reusable code, and defining client-side logic in classes (even when you think you might never re-use that application logic again). But I’ve never seen that principle applied to CSS. I definitely recommend reading more on this topic.

Juicer: JavaScript and CSS Packaging

YUICompressor, and its friends, are great methods for compressing CSS and Javascript, but my biggest wins you can possibly make in optimizing the size of your script or style content is simply to not include the things you don’t need. This is why I perked up when I saw a post on Ajaxian on a project called Juicer, which is a tool to package JavaScript and CSS while applying best practices as it does its work.

When developers start a project, they’ll go to the site for their tool of choice. For me, I first go to MooTools and download a kitchen-sink build of MooTools-core and -more, and as I develop I’ll use more and more features of it.

However, when it comes time to ship, I need to scale back what my MooTools build includes since probably 75% of it won’t be needed by my project. But the question is, which 75%? This is mostly a trial-and-error process which is made all the more difficult to deal with because I’m used to Perl and CPAN resolving dependancies almost flawlessly.

So my hope is that Juicer can help me solve some of these problems, and I can use it at build-time so I not only can resolve dependancies and build the proper Perl modules to deploy my webapps, but that it can trim down my JavaScript libraries to include only the features I need.


This seems like quite a simple script, but it solves an important problem. In a nutshell, it creates a way of handling focus and blur events for fields and other sorts of widgets so you can make your web applications accessible. Ajaxian gives a little summary of QFocuser, but I had thought that this could be quite powerful for reasons other than accessibility.

At my day job, we style our text fields specially when they are disabled, selected, or just regular plain fields. Most of our legacy code manages this manually, by setting attributes and CSS properties independantly, and many places gets it wrong. I’ve been implementing some changes in our framework to eliminate this problem, and largely involved implementing much of what QFocuser does, but in a more specific way.

I’m curious to see how I can apply it here, and use it as a generic mechanism to make our UI behave more consistently.

Internet Marketer’s Checklist

Over at SEOmoz there’s this great post, titled “The Internet Marketer’s Checklist For Determining If a Business Idea is Worth Pursuing“. The title is a mouthful, but it’s a great discussion of the things that will make an online application succeed or fail. As programmers and technical types, we often lose site of the actual goal of doing what we do: building stuff that people will use.

I’m a terrible example of your average user. I use the keyboard primarily for navigation, even on my Mac (Quicksilver FTW!), I use the command-line almost exclusively. Most users wouldn’t be caught dead using their computers that way. This extends to other areas as well. Applications that would appeal to us techies won’t appeal to the nontechnical, teen-with-flashy-website crowd.

I’m fortunate that my wife not only is very technically savvy, but still is in touch with her non-technical roots, and has a psychology degree and her lab experience to know how people think. I use her as my litmus test to see if an idea is worth pursuing. But beyond knowing if someone will be able to relate to a website, this checklist looks like a great way seeing end-to-end if a site would be understood, would be marketable, and if it would actually stand a chance of being used by the general public.