DeveloperTown

We’re making significant strides over here to improve our design process. And by design, we mean a lot of things: building a startup vision, creating the user interfaces, and presenting a beautiful look and feel for our clients.

My current work is primarily on a client project called TPG Marine Harbor Management System. Yes, long name, but the project boils down to helping barge servicers track their fleets and automate billing. Crazy stuff. I joined the project as the second developer, but I’ve since taken responsibility as the designer.

The way we’re doing design on TPG is this way: we figure out what problems we want to solve in the next several weeks, and we start designing solutions today. The challenge I’ve faced is knowing when I’ve completed a design task. Finishing design isn’t as clear-cut as completing implementation of a feature. Should I mock up every detail for the developer? Should I code all of the html/css and hand that over to the developer? And most importantly, am I done yet!?

I’ve come to realize that the most important aspect of design is CONFIDENCE. The ultimate question in my head is, am I confident in my approach to a solution? When confidence becomes the key to finishing a design, the less important details become, well, less important. No longer do I feel the need to write tons of html, css, and javascript to feel “done.” I write as much as it takes to feel confident. The design may appear half-baked, sometimes sloppy, and maybe even ugly. But that’s ok…because I’m not trying to perfect it yet, I’m just trying to convince myself that my approach will work.

Because we live in a world of scarce resources, we need to figure out what get’s us to completion the most efficiently. Here are some ways in which I’ve tackled finding confidence:

Wireframing

Wireframing seems to work well when an app is being built from scratch. It helps answer questions like, what content needs to exist? What actions can be taken? Who are the users? I haven’t used wireframing much since my project is far beyond the initial design phase.

Sketching

Sketching helps get design insights tangible quickly. Skteching can help you visualize a solution without committing much time. I’ve found that the ease of finding confidence or the lack thereof from a sketch depends on my level of experience with the project I’m on. The more experience I have, the better my intuition and thus  the more easily I can vet ideas in the sketching phase.

HTML / CSS / Javascript

Since my project has an existing codebase, I spend most of my design time working with these three tools. Using git, I checkout a design branch for each design task and start messing around, searching for what interface and interactions (clicking, entering data, etc.) give me confidence. For my last design task, I abruptly stopped working on my design and concluded I had confidence, long before the interface was polished and the interactions complete.  But that was OK, because I knew I could perfect everything after design is finished.

(For all Rails/Git folks out there, an extra tip: I will clone a second copy of my repository so that I can run two versions of my app, one for development and one for design. That way, I can see my design work in action in a browser window while implementing the design.)

The goal here of this design process is to think critically about designing solutions before implementing a solution. But it’s also to be lightweight as possible. Good developers on small teams don’t need to know every pixel of an interface. They need to know what the solution is. The deliverable from these design tasks is often nothing more than a series of implementation tasks for developers, a half-baked demo, and maybe some code to reference.

I would love to hear your thoughts on approaches to design. I’m sure the approaches will vary, given the needs of different clients, projects, and teams.

Last week, David Heinemeier Hansson (creator of Ruby on Rails and partner at 37Signals) attacked a popular version of test-driven development: the TSA-style. The overarching characteristic of TSA-style test writing is failing to ask why a needless security check test warrants a breath of life in an airport app’s codebase. His main point is that tests aren’t free: they have a long-term maintenance cost like every other feature. And if tests aren’t free, then you better pay close attention to the tests you choose to write, because they’re costly.

At the heart of his blog post is a scorn for hard-lined test-driven development. And for the most part, I couldn’t agree more with him. But the part missing from his essay, and the part of TDD that most resonates with me, is that TDD drives good coding patterns.

When the going gets complicated, the complicated gets…tested

DHH’s last point was: “Don’t force yourself to test-first every controller, model, and view (my ratio is typically 20% test-first, 80% test-after).”

The idea of writing tests first, coding second comes from the idea that “if you can’t test it, then it’s not good code.” While this may not always hold true, I’ve found that this approach guides me as I write code.

When a feature gets complicated, it helps to write out what you expect to happen before firing away on all cylinders to implement it. And, in the world of startup-land where we don’t have bountiful time to write tons of Cucumber and Selenium tests, this is called writing a spec of unit tests.

When it comes to features with complicated requirements in Rails models, I almost always test first. This is not to say that those tests won’t change as I write code. In fact, once I have my basic tests written, I start implementing to get a feeling if the pattern proposed by my tests work or not. I spend time refactoring both my tests and code until I’m satisfied. This approach helps me break my models down into healthy, maintainable parts.

Even in writing javascript, the “test first, code second” paradigm plays a role. While I don’t write unit tests for javascript apps, I do try to write my code in such a way that it could be unit tested. That means delegating responsibility through the javascript app to ensure I can “isolate” expected behaviors (i.e. avoiding “spaghetti” javascript).

Where to draw the line

I think DHH nailed the hammer on the head: it’s easy to waste our time writing unimportant tests while leaving less time to test the critical, risky parts of our app. But in the process of doing so, he tried to refute what, to me, seems to be one of the most rational reasons for test-driven development: driving good programming patterns. I would encourage any new programmer to keep this in mind when valuing testing.