Process is the nemesis of a startup and the correct dosage of chaos is its nurturing mother. With all of that in mind, I’d like to propose some principles for startup hackers who find themselves too constrained by Agile practices:

Rule #1: Don’t Test (All) Your Code

Certainly don’t ever test drive it (it’s ok, no one does anything more than pay TDD lip service anyway).

Here’s the thing: tests require maintenance just as much as production code. Here’s an example: We recently restructured our data model at Niroka to allow multiple “sessions” for a course. This involved adding an abstraction between “courses” and “enrollments”, where if I had written unit tests I would have found myself essentially rewriting all of them to respect the new abstraction layer. It probably would have taken longer than implementing the damn feature.

Here’s what you do instead: write integration tests for the critical parts of your application. For Rails, this means a high-level cucumber test for things like, in our case, “signing up”, “creating a class”, and “enrolling in a class”. It’s still maintenance, but it’s a tradeoff we like because it’s tedious to manually test those and we really, really care if they break.

The point is, code evolves. It’s never “done”, so don’t write tests that presume it will be static and your interfaces won’t change.

Rule #2: Stop Being Such a Nerd

“Do you prefer git rebase or git merge?”

“Should my spec names be declarative?”

“Is this method supposed to be private or protected?”

Ask yourself: Do the answers to these questions provide any value to myself or my customers, or am I just dorking out hardcore? I don’t mean to be derisive, this is the rule I break most often and so I am guilty of dorking out hardcore.

I don’t know why this over-analyzation happens, There’s something about the programmer’s brain that wants to make everything more efficient, and then that brain gets tunnel vision and finds more and more minute ways to be efficient and loses the forest for the trees. We also work in an industry that is obsessed with methodologies and best practices, so it’s easy to get caught up in trivialities. Just build things, motherfucka.

Rule #3: Take Ownership of Your Features

Don’t worship the codebase. I had the tendency to treat code like a sacred scroll that should never be tarnished, and it gets in the way of me creating value to our users. A related effect is that coders tend to push off non-programming work in favor of the next feature to implement. We’re good at coding, so we try to find reasons to always have something to code. I think a lot of developers do this, but remember:

1. Finish Pivotal Tracker Queue
2. ???
3. Profit

doesn’t work.

Here’s how to get around this gotta-code-the-next-feature mentality: take ownership of the features you implement. Instead of spending time developing Feature B, figure out a way to track and quantify the success metrics for Feature A. Use A/B tests, funnels, or solicit user feedback and actually figure out what value Feature A brought to your app. You may be surprised how much work it is to answer a question as simple as “Did this feature bring any value?” The upside is: you own your feature, it’s like a little feature-baby that is all your own and all you want is to see your feature’s metrics go up and to the right. Through this process, you’ll become a more valuable developer by understanding your business and also gain an appreciation for the idea that “software is just a tool”.

Noteworthy: Facebook has a really interesting system for allowing developers to take ownership of their features even with as many devs as they have. From my understanding, it involves letting dev teams take ownership and implement whatever they want as long as they roll it out slowly and have the metrics to validate the feature.

Two notes to end on:

A healthy dosage of chaos can go far for your team. It may not optimize your productivity, but we’re not machines — we need some disruption in our environment to stay creative and excited.

Finally, software is a means to an end. Try not to lose sight of that end, or you’ll end up just treading water and never moving forward.

Pragmatic software entrepreneurship.

Last night on the season finale of Bloomberg's Techstars show, one of the founders said he spent the summer generating revenue rather than raising a round of financing.

No one in the audience applauded. But they did when Onswipe announced a $5 million round and Crowdtwist announced a $6 million round.

Techstars mentor and successful entrepreneur Gary Vaynerchuk took notice and made a good point.

"I'm concerned a little bit with the culture of celebrating the fundraise," he said. "My dad taught me that when you borrow money it's the worst day of your life. We didn't clap for Red Rover because they didn't raise $6 trillion, but I was sitting here like, 'Good stuff!'"

Instead, Vaynerchuk looks for other entrepreneurs who know how to make money.  "What I'm looking for are people who are not caught up in the excitement. Even though I'm a hype man myself, I like the practicality of it all. People who understand how to turn a profit. At the end of the day, this is still business so I'm looking for real practical knowledge of how to actually make money, not necessarily raise it."

Cheers to that.