Developer Town

The three most important factors in creating a business? Risk, risk, risk.

If you try one, JUST ONE, thing that is “lean startup-ish”, try thinking about your startup purely in terms of risk. Sure, Eric Ries taught us about validated learning and Ash Maurya has shown us how to learn from problem interviews and solution interviews. There are lots of tools out there for the lean startup crowd. But the question remains, how can I get started?

By focusing on risk. The principle that both of these entrepreneurs share is that a startup must work hard to minimize risk. Validated learning, customer interviews, lean canvases, innovation accounting…in the end, these are all tools for reducing risk in a startup. Here’s why: the biggest risk in a startup scenario is that we’re DEAD WRONG about our idea and its place in the world. So tools are invented to keep ourselves accountable to the real world.

I’ve been recently pursuing an idea to help K-12 teachers communicate better with parents. I don’t have 40 hours a week to spend on this, and it’s a one man team until there’s validation of the idea. As a result, I need a simple, clean plan for testing my idea. Here’s the process I followed:

Brainstorm Risks

There are a couple facets to my app: it requires parents to sign-up, teachers must produce content, and schools need to pay. Based on these few facts, I came up with the following list of risks:

- Parents and teachers must find value in the app.
- Schools must be willing to pay for the app.
- Parents must voluntarily sign-up to receive communication.
- Teachers must be willing to try the app.
- Schools/teachers must populate the app with student data.

Prioritize the Risks

I then prioritized the risks based on two factores: the degree of risk and timing. The riskiest items must be worked on first. But just as important, I needed to account for timing: which risks do I have the resources to tackle NOW? Based on these two questions, here’s the prioritized list:

1. Parents must voluntarily sign-up to receive communication. (There’s no point to the app otherwise!)
2. Parents and teachers must find value in the app. (Who cares who pays or how many teachers try it if no one values it?)
3. Teachers must be willing to try the app. (I need teachers to voluntarily start using the app.)
4. Schools must be willing to pay for the app. (Extremely important! But I want to test the product before I have to wait 3 more months to get product feedback again.)
5. Schools/teachers must populate the app with student data. (Eventually, but not NOW, I need student data to be populated without me spending hours prodding teachers to do it.)

Often times, the greatest risks are that you’re building something people value and that people will pay for it. Or maybe you’re inventing new technology, and the risk is that it can be done affordably. Or it could be that you need to secure patent rights. But, SaaS products (software as a service) tend to see the same reasons for failure: a poor value proposition or insufficient revenue.

Create a Plan to Mitigate the Risks

In my most unemotional state, I can now view my business as a combination of those 5 risks. If I’m able to mitigate them, then the business should succeed and the money should roll in. But, how do I work towards eliminating these risks?

This is where your planning powers play a role. You must make predictions about what to expect if you’ve effectively mitigated a risk. For example,

If I can onboard 25% of parents for ONE class at ONE school, then I am confident enough to move on to the next risk.

Here’s the kicker: the first few months are more about instilling confidence in my idea rather than scaling a real business. That’s why the 25% number is fairly low and I’m only testing with ONE class. If I can’t meet this challenge, then I need to reset, find a new class, and/or improve my onboarding process.

My second risk is tested in this manner:

If teachers send 20 communications per week to parents, and parents read 75% of them, then I am confident enough to move on to the next risk.

And so the pattern continues, until I have enough confidence to take the business to the next level…

User Stories Suck for the Last Mile

Yeah, that’s right. I said it. User stories suck for the last mile. What’s the last mile you say? It’s a term borrowed from my telco days, when Sprint had a U-verse-like offering that was way ahead of its time and you could only get in Kansas City. It was awesome. But it died, because getting the last mile of networking was proving to be too expensive. The last mile, in this case, was the distance between Sprint’s closest network terminal and your house.

For user stories, the last mile is the distance between the story being functionally complete (i.e. everything works as expected) and accepted (i.e. and it looks the way I want it too). It is often a long list of layout and style changes like “left-justify X” and “make the margins line up between Y & Z”. These changes are often hard to communicate via written words, but more importantly the delay between feedback and development is too long and, since the changes tend to be small, the cost of switching tasks between all the stories that need tweaking can be pretty spendy.

Sprint Reviews Can Make This Worse

If most of your feedback collecting occurs at the sprint review, this only becomes worse because the person recording comments is frequently not the person giving feedback. Usually, one team member takes notes while the other team member demos stories and the product owner(s) discuss changes. As a result, you create this huge backlog of bugs, tweaks, chores, or whatever you call them that you do prior to the stories being accepted and you starting new ones.

Years ago I started a practice of implementing as many of the tweaks as I could immediately following the sprint review while they were fresh in my mind, but it’s still not optimal. Why?

Because the sprint isn’t finished. We walked out of the sprint review with more stuff to do prior to the stories being accepted. This is a bit discouraging, especially if even more problems are found after the initial round of tweaks go in. If you end up going through cycle after cycle of tweaks, discouragement turns into frustration.

“Peer” Programming Works

About two months ago I gave up on sprint reviews. Instead, when I finished a story I simply skyped at my product owners that I was done, even before I pushed my code or marked the story delivered. I shared my screen with them, gave a demo, then they would just type changes at me in Skype, which I would implement in real time. Because we were using IM and screensharing, they could keep doing other stuff while I made the changes. When I was done, I’d IM them back and we’d start over. After a while, the feature was done. I’d push the code, the CI server would update test, they’d give it a final run through and accept the story. Piece of cake.

I call this peer programming rather than pair programming just because only one of us is actually programming, but the peers are giving feedback in real time. It’s very, very efficient, and we haven’t had a sprint review since we started doing this.

Take It Up a Notch for the Big Event

Earlier this week I spent three days onsite “peer programming” with the product owners. We set up shop around a table in the Developer Town offices with my second monitor where everyone could see it and went through the application one feature at a time tweaking features prior to ‘soft’ launching the new product on Wednesday afternoon. It was exhausting, but the end product is totally awesome.

This kind of pre-launch peer programming is a perfect way to efficiently get all the little details right. It’s very effective communication because the feedback loop is super short and the people with questions and answers are together. It’s a lot better than a sprint review because, among other things, the story gets accepted at the end of the session.

Making it Productive

Here are some pointers for making peer programming work well:

1. Have the product owner verify that features are “functionally complete” prior to the peer programming session. They can make sure the workflow is working in a relatively bug-free manner so that the changes that are left are going to be primarily small changes to the design and layout.
2. Use developer-tools to make CSS changes in real time, then copy them into your code once the change you are making looks right. This minimizes the amount of time between code change and feedback (you don’t even have to refresh your browzah).
3. Peer program as soon as a story is functional. That way, your mind is still in the code and you don’t have to re-acclimate yourself. This has the added benefit of avoiding a deliver-reject-restart cycle, which is a bit demoralizing.
4. Take breaks when you need to. Peer programming is tiring, so step away from it every now and then if you are in a marathon session of it. If you get worn out you will also get stupid.
5. Crack some jokes and don’t get all mad. Peer programming can be hard for a certain type of person. You know who you are. You don’t like criticism and every little change is a personal attack. You’re in the wrong business. Okay, seriously, there aren’t many people like that and most of them work in corporate IT environments, but  it’s easy after really long peer programming sessions to start getting frustrated and worried that you’ll never get it right. Just take a deep breath and hang in there. Slog on through, and try to crack a joke or two if you start feeling defensive.

Peer programming throughout a sprint is definitely more effective than using a sprint review as a periodic feedback point. If you can’t get your product owner to review stories during the sprint, just replace the sprint review meeting with a peer programming session and get through as many of the stories as you can. When you run out of time, schedule some more time. Wait – we just said they didn’t have time during the sprint – why can we schedule it now? Because peer programming is something most product owners will really like. They get to see the site change in real time and find lots of value in this. Everybody can find time for the things that matter to them, and once product owners get it they will free up time.

Sprint Reviews without Demos

So, we just kicked sprint reviews to the curb, but should we really abandon them altogether?

Maybe. It’s very easy for demo-less sprint reviews to become meetings with high ceremony and low value. It’s probably better to not have them than to have those types of sprint reviews. I would only hold a sprint review if there are meaningful issues to be discussed, and then I would plan retrospective activities to help work through the issues. Rote sprint reviews are a waste of time. Make them meaningful or toss them.

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.