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”.