Harder, Better, Faster, Stronger

On the train ride to work today I was listening to “Daft Punk” on my iPhone while reading my blogs, my usual morning activity. And as my mind wandered, the song “Harder, Better, Faster, Stronger” came on; it’s one of my favourites, as I’m an avid electronic music fan. But since I was reading Ajaxian and several other software industry business blogs at the time, the song seemed strangely appropriate. Everyone is trying to find ways of working harder, developing better software, releasing to market faster, and having a much stronger market position (honestly, this is what was running through my head). This made me think more about what I do to fulfill those 4 business goals, so well voiced by Daft Punk.

“Work it harder”

Personally, I like having a life. I have a wife, hobbies, Open Source projects I like to contribute to. And of course I have my day job where I do more than I’m asked to do, always trying to come up with creative side projects to help make more sales, improve the product, or visualize our usage data in a way to help us build a better product.

So given the cliché that we all have 24 hours in a day, and you have sleep, meals, and commute time involved, how do you optimize your daily work habits to maximize that time?

The way we do this at work is through Extreme Programming or Agile Software Development, both are complementary techniques to eliminate waste from the traditional development cycle. Planning documents, requirements analysis, task assignment and many other wasteful planning processes are typically eliminated.

Coming up with a comprehensive specification before the project is even started is dreadfully wasteful. They typically become a hindrance because no developer can possibly foresee what problems they’ll encounter part-way through. These development practices allow a team as a whole to be flexible, to adapt to changes mid-way through the development cycle, and develop the important bits first. If you haven’t heard about or tried Extreme Programming, I highly recommend you go read up on it. Extreme Programming Explained is a great introduction for people used to more conventional development practices.

The important thing I’ve found is that these practices can even be adapted to single-person teams. You have to alter a few things in order to get it to work for a solo team, but adhering to the principles of “Build the simplest thing that works end-to-end first, then refactor later” is perhaps the most important practice I can suggest. For myself, it’s hard to get lost in developing “Teh Bestest Softwares Evar!” Sometimes you have to take a step back, and question yourself as to what is truly important to your project? Go build that, and don’t waste your time with unnecessary frills.

“Make it better”

Cutting out what isn’t necessary, or building the simplest possible thing doesn’t mean eliminating best practices. Quite the contrary, Extreme Programming pushes very heavily on test-driven development. The ultimate goal is to write your tests before you write a single piece of code. It doesn’t have to be a difficult test, but when you first run it, the test should fail. Once you get a failing test, you write the corresponding code for your project to make the test pass. Then you move on to the next task, rinse and repeat. One of the books on our bookshelf here at work is Test Driven Development, and it’s a great book on learning how using tests to drive your development can really help. I actually need to re-read it again, since my test-writing skills are getting a bit rusty.

By stepping through your project one bit at a time, writing tests as you go, you ensure that any regression in your code is caught by your test coverage. If you’re developing applications that a user will interact with, either through a GUI or a web interface, then automated tests are needed to be able to programatically exercise your interface.

We use Selenium within a series of Windows VMWare instances. Our test runner machine spawns VM instances on our VMWare server, as well as installs fresh copies of our software on our test servers. It then runs our tests using a test harness I developed called Test::A8N to be able to execute our tests, remote-controlling the browsers from within Windows.

Along with all these tests, you need visibility into how your tests are performing. There’s no point in writing all those tests, if you never run them. So we have a nightly process that runs all of our tests in parallel across several servers (so that they can complete in a single night), and then renders an HTML “Dashboard” showing which tests passed and failed, summed up as Red, Yellow or Green. A wide-screen LCD display is easily visible by the entire team, and shows us at a glance just how we’re doing. If you see large patches of red, then you know you’ve got some bug fixing to get to today.

There are other philosophies behind both Extreme and Agile programming, but I won’t get into them here. I highly suggest you read one of these books, as they’re really eye-opening into how you can develop better software without the traditional pain and bureaucracy found in more traditional methods.

“Do it faster”

With all this attention to detail and automated tests, it’s important that your development is still faster than the traditional ways of writing code. Sometimes you have to throw out what isn’t working, and this includes your preciously-written code. If something that served your purposes a year, 6 months, or even 2 weeks ago isn’t serving you anymore, then it’s time for it to go!

Refactoring is the process of taking something that worked before, and altering or culling what doesn’t fit anymore, and writing fresh code to replace it. Many times this means throwing entire chunks of code away. It’s important to not be married to your software. It’s just work, you’ve got plenty more where that came from. Just write what is needed, and nothing more. Don’t over-engineer, since that future “Maybe” feature you’re coding for most likely won’t be needed or used anyway.

Case in point: here at work, a former employee had written a UI framework that all our UI pages were built upon. It handled navigation, Ajax code execution, and so forth. It served its purposes very well at its time, but as features were added it became more and more brittle. Finally, shortly before I was hired, they added localization support, and it broke the camel’s back. Developing new pages was tedious, time consuming, and was littered with unused features that no one knew how or even if they worked.

After a short time of dealing with this, I cut it all out and replaced it with something smaller, lighter, and custom-fit to what it was we needed to do. It cleaned up our URIs so they were easy to understand, sped up development significantly, and gave us a stable platform to continue our subsequent refactoring on top of. All of this, and we eliminated approximately 3,000 lines of code. We’ve settled on the MooTools JavaScript framework for our code, and extend it liberally to build our client-side Ajax UI.

The framework is still holding up a year later, though I know it will have to go through some growing pains later. It’s currently Apache2/mod_perl based, and we’ll eventually be ripping this out and replacing it with a lighter FastCGI wrapper. But the important thing to take from this is that we weren’t so tied to our code that we weren’t afraid to throw it away when it started to smell.

“Makes us stronger”

The end result of all of this is to improve everyone’s lives. The developers have more fun at work, the project gets completed faster, more value is delivered to the customer in a timely fashion, the shareholders make more money, and the business improves.

Therefore I like to find areas in which I can help the company. Partly because there are many more interesting problems than just what I work with in my day job. So I write tools to help the salespeople sell more software. I write tools to help the product managers identify what our customers need and use. I’m currently working with our documentation team to find new ways to represent our documentation to make it more visible to our customers when they need help.

Ultimately, if you think outside the box and thing about your project from your customer’s perspective, it opens up a much bigger world for you to find your niche. Forget about what your job title is or what you’re being tasked to do. What problems do your customers have? If you had to use the software you’re developing on a day-to-day basis, would you enjoy yourself? Or would you pick up the phone and try to find a new vendor?

There’s a great rant over on Seth Godin’s blog titled “Just doing my job.” Don’t hide behind your job title as an excuse to justify your company’s actions, and don’t use it as an excuse to be lazy. Expand your skills, help your customers solve real problems, and don’t write bad software.

“More then ever after, our work is never over”

Most importantly than anything, never blindly accept that what you’re doing now is the best there can be. Newer technologies are developed, better strategies for developing or planning software can be invented, and people become complacent. Always read, always learn. Attend conferences, teach others what you know so you can understand your craft better.

So it’s very fitting that the last phrase in Daft Punk’s “Harder, Better, Faster, Stronger” is this: “Our work is never over”.

Mootools Fx.Index v1.0

At work I needed to perform an animation on a sprite-based image (e.g. one large image containing multiple stages within an animation, pre-rendered). Since there was no easy way within Mootools to iterate over an array of class names, I created one. I called it “Fx.Index”, but if you have a better name for it, please leave me a comment.

Fx.Index = Fx.Base.extend({
initialize: function(el, css_classes, options) {
this.element = $(el);
this.css_classes = css_classes;
this.parent(options);
this.previous_index = null;
},
increase: function() {
var index = this.now.toInt();
if (this.previous_index == index)
return;
this.previous_index = index;
var klass = this.css_classes[index];
if ($chk(this.options.classBase))
klass += " " + this.options.classBase;

this.element.className = klass;
}
});

This code is taken straight from our product, which uses Mootools 1.11. So I’ll post an update once I port it to Mootools 1.2, at which point I’ll submit it to be added in the not-yet-created plugin directory.

GM Bailout PR fumble

Apparently buying a GM car 8 years ago entitles me to recieve a wonderful little email from GM about the proposed bailout. It seems they’re trying to stem the flood of people abandoning them in the wake of the US bailout.

Dear Michael Nachbaur,

You made the right choice when you put your confidence in General Motors, and we appreciate your past support. I want to assure you that we are making our best vehicles ever, and we have exciting plans for the future. But we need your help now. Simply put, we need you to join us to let Congress know that a bridge loan to help U.S. automakers also helps strengthen the U.S. economy and preserve millions of American jobs.

Despite what you may be hearing, we are not asking Congress for a bailout but rather a loan that will be repaid.

The U.S. economy is at a crossroads due to the worldwide credit crisis, and all Americans are feeling the effects of the worst economic downturn in 75 years. Despite our successful efforts to restructure, reduce costs and enhance liquidity, U.S. auto sales rely on access to credit, which is all but frozen through traditional channels.

The consequences of the domestic auto industry collapsing would far exceed the $25 billion loan needed to bridge the current crisis. According to a recent study by the Center for Automotive Research:

• One in 10 American jobs depends on U.S. automakers
• Nearly 3 million jobs are at immediate risk
• U.S. personal income could be reduced by $150 billion
• The tax revenue lost over 3 years would be more than $156 billion

Discussions are now underway in Washington, D.C., concerning loans to support U.S. carmakers. I am asking for your support in this vital effort by contacting your state representatives.

Please take a few minutes to go to www.gmfactsandfiction.com, where we have made it easy for you to contact your U.S. senators and representatives. Just click on the “I’m a Concerned American” link under the “Mobilize Now” section, and enter your name and ZIP code to send a personalized e-mail stating your support for the U.S. automotive industry.

Let me assure you that General Motors has made dramatic improvements over the last 10 years. In fact, we are leading the industry with award-winning vehicles like the Chevrolet Malibu, Cadillac CTS, Buick Enclave, Pontiac G8, GMC Acadia, Chevy Tahoe Hybrid, Saturn AURA and more. We offer 18 models with an EPA estimated 30 MPG highway or better — more than Toyota or Honda. GM has 6 hybrids in market and 3 more by mid-2009. GM has closed the quality gap with the imports, and today we are putting our best quality vehicles on the road.

Please share this information with friends and family using the link on the site.

Thank you for helping keep our economy viable.

Sincerely,

Troy Clarke

Things must be bad for their PR department right now. Remember, I last bought a GM 8 years ago, and only had it for 3 years before buying my Mustang, which I also no longer own. Public transit and a sport bike are all I need anymore. So they’re definitely casting a wide net on this one.

How do you name your business?

Yesterday at the Elephant & Castle Pub I was talking with a friend who’s decided to finally take the leap and move into doing business as a free agent. He’s filing all the business applications, getting consulting jobs (he already has 2 long-term gigs lined up), and is going through the motions of becoming his own business entity. All that’s left is a name.

Web businesses aren’t bound by the same requirements of conventional businesses to have a relevant name, but we have different problems. Do we pick a name from a bag of industry buzzwords, and sound like we’re the company from Office Space? Do we create a name that accurately reflects what you do as a business, and sound like a group of pocket-protector-wearing dweebs? Or do you go to an extreme and invent a unique name that means absolutely nothing, and gives the customer no inkling of whether or not you’re a business or a toilet scrubber? That last one feels like the DotCom days all over again, and while it may have worked then, I doubt it would lend much credibility these days.

We do have a lot more leeway when it comes to naming technology businesses though. We can stray a bit towards the “Funky Widget” sounding names from the DotCom era, but too comical and you sound, well, like a joke.

Domain names are also an issue. Once you have a name, you have to check and see if it’s available. I’ve always been too cheap to bid on a squatter-owned domain, and have always preferred to change my business name rather than buy an already registered domain.

When I was discussing this with my friend however, I realized it’s been a while since I tried to pick a business name. My last business I just gave up, and named it after myself. “Michael Nachbaur Consulting” sounds really bland, but when you know your customers on a first-name basis, and you’re a one-man shop, there isn’t much need to get too crafty.

If you’re reading this, what would you use as a business name, and how would you pick one? Do you take words describing things you love and combine them? Or do you pick, for instance, a colour and something from nature? (BlueWave immediately comes to mind). How would you come by your business name?