Throwing the gauntlet down with Uncle Bob
This post is a follow on to an earlier post which was a response to a post by Uncle Bob Martin, author of Clean Code and other noteworthy books about software development. There were some tweets involved as well, but to make things easier and get you caught up if you haven’t been following along, just read these posts first:

• Bob Martin advocates for a use-case-centric architecture in “No DB”
• I ask for a working example in “Dear Uncle Bob: Please, please show me the code”
• Bob kindly gives me one in “Aldos Response“

Perhaps I Got It More than I Knew
About a year ago I embarked on a major re-design of TroopTrack. One of the changes I made was to group functionality in the five major uses cases of my software. This grouping is evident in the UI:

And in the code:

I show here the controllers folder, but if you looked in the views folder you would see something very similar – I’ve namespaced my application based on the major use cases of my system. Like FitNesse, there is plenty of cruft in there and, since it’s a rails app, things are pretty much glued to HTTP.

This may seem like a relatively small change, but it has had a dramatic improvement on TroopTrack overall. For one thing, TroopTrack’s “first glance” grade improves significantly. It’s a lot easier to see what TroopTrack does than pre-namespacing, when everything was just lumped in one sloppy bucket. For another thing, this improves separation of concerns at a higher level and lets me think about the same bits of data differently in different contexts.

Let’s Be Honest Here
Namespacing TroopTrack this way is nice, but let’s not call it a use-case-centric architecture. It’s not. It’s simply more use-case centric than it was. Whoop-dee-doo.

One of the frustrations I encountered in TroopTrack 3.0 was that I couldn’t namespace models. The “user” I deal with in Communicate is rather different than the “user” I deal with in Manage. Perhaps it would be more accurate to say that I wish they were different, in spite of the fact that underneath it all is a database structure that they share. You see, in Communicate I really only care about a few things related to the user:

• Their name (not the parts of it)
• Their email address
• Mailing lists they belong to
• Their privileges related to editing web sites, uploading documents, sending messages, and sharing links

In Manage, I have a much larger set of stuff I am interested in:

• First name
• Middle name
• Last name
• Household they belong to
• Birthday
• When they joined scouts
• What scouting unit they belong to
• Their avatar image
• Medical information about them
• All their privileges
• Their access level
• etc.

It bothered me that I couldn’t namespace my models the same way I namespaced my views and controllers. Why can’t I have a different set of validations, accessible attributes, methods, etc for a different high level use case?

Note: this is a rhetorical question. In rails, you can in fact accomplish at least some of these things by adding logic to your validations and adding :as => namespace to your accessible attributes. But it’s not what I would call clean and, since all this stuff would wind up being in the same model file as every other namespace it would murkify intent in significant ways.

What I’d Like to Have
At some point in the future, I’d like to bust open my source code and see something like this:

I’m not 100% sure what the controllers here would look like. It might be nice to un-marry them from HTTP, but the pragmatic part of me is not totally sold on that. I might just call them HTTP controllers or something, just so there is semantic congruence between what they are called and what they are.

I like the convention for naming views in a way that shows their action, format, and the language used to implement them, like so:

• show.html.haml
• show.pdf.haml
• show.json.erb
• etc

It would be important to be able to disconnect the views and controllers from HTTP if needed, so that I could continue to use them with other protocols. The pragmatist in me says “leave that step until you need it, just leave room for it for now”, and I agree with him at the mo. It would also be important to put some thought into keeping the views from being too married to models, but I think this might have more to do with the models than the views.

Neither of these things are a HUGE departure from things we’ve seen before. In fact, you could probably take different parts of Rails and bend them to your will to support an approach like this.

The problem is, you could go this far and still end up with an architecture that is fundamentally data-centric. In order to be truly use-case centric, you need to have models that reflect the use case as much as your views and controllers do.

The Models are the Big Deal
For the most part, models tend to be 1:1 matches to the way the data is stored. A model’s class usually represents a table and an instance is a row. The model you build just adds behavior on top of that data. This is convenient, especially in a framework like rails where active record adds some magic for all sorts of stuff, but the 1:1 mating of a model to a table is limiting.

Ultimately, it might be valuable to break both this 1:1 mapping and the tight database coupling to allow for a model to be “storable” in multiple ways. I can think of cool uses for this including an often-requested feature that TroopTrack currently doesn’t have – the ability for a scouting group to get/restore a csv or sql or json backup of all their data (TroopTrack is a multi-tenant application).

That’s all well and good, but I think there is a simpler advancement that is needed that is also more important. I mentioned it earlier in my example about how I care about different aspects of users depending on whether I am in the manage use case or the communicate use case. I think it boils down to something simple.

Models need to be a reflection of the use case rather than a reflection of the columns on a table plus a generalized set of behaviors.

At this point I can hear Bob Martin cackling ruthlessly. It’s what he’s been saying all along. Sometimes, you just gotta see some code to believe it.

Also, like the previous times I’ve been exposed to your mantra, I found myself wanting to try it. I want to build an application that is focused on the use case. I want to go to a source code folder, pop it open, and know immediately what the app is all about. Really. I think that would be AWESOME.

My Use Cases have My Process Wrapped Around Their Finger*
Use cases drive my development process. They are where we start and they are the core bits of our workflow. We don’t start development by defining a data model – we start off by asking “What do you want to do?”. Over and over and over. It’s the most fun you can possibly have on an untethered ferris wheel, like rolling down a hill inside a tractor tire.

This is perhaps THE reason why the idea of architecture and code revolving around a use case is very intriguing to me. It seems to work pretty well on the process side, wouldn’t it be cool if it also worked on the coding side?

Heck yes it would.

*As long as you are willing to include user stories as a form of use case this is true anyway.

This is Where the Party Ends
I won’t lie. As much a I want my architecture to revolve around my use case, I really can’t imagine up how to do it, and I’m no dummy. When you complain about the way rails apps are structured in a way that communicates only that they are a rails app, that the architecture doesn’t say anything about what the software REALLY is, I can’t help but wonder what it SHOULD look like. And I have no answers.

Seeing is Believing
Clean Code showed me how code can be. It’s an epic work, in large part because it SHOWS you how to write clean code. Seeing code go from crap to clean helps readers understand the principles behind clean code. It’s the best way to teach, and frankly, based on my limited exposure to the things you’ve written, it’s your best work.

The Gauntlet
You’ve been harping on about data-centric architectures sucking and how use-case-centric architectures are the hypothetical shizzle for a while now. I started paying attention to it about a year ago, but I’m pretty sure your lost-architecture thesis predates even that. I don’t have a problem with the idea, I just have a problem figuring out how to use the idea.

So, how about you show me? Show everyone, for that matter. Build a use-case-centric application so that next time SCNA rolls around you can follow up your picture of a rails app and its root directory structure with an example that doesn’t suck. Make it work on the web, and throw in an api for mobile for good measure. As you’ve mentioned in the past, these are trivial issues anyway and shouldn’t dictate architectures. But we still need apps that use these mediums, and we don’t have solutions that make the use case king.

So, there. That’s the gauntlet. I’m throwing it down. Please, please, please, put up.

Thanks,

Dave Christiansen

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:

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

TroopTrack conversion rates vary from month to month, but at a minimum, 10% of my trial customers convert to paying customers. I’ve been trying to figure out ways to improve that number over the years and some of my experiments have yielded fruit. For example, if I am able to reach a trial customer by phone early in the trial they are dramatically more likely to convert than those I never talk to. The conversion rate (anecdotally) is upwards of 70%. Basically, almost everyone I talk to ends up buying. They don’t forget the one product they tried where the owner actually called them.

I’m very interested in figuring out how to increase the likelihood a customer will convert, but I’m also very interested in predicting whether they will. To this end, I’ve been gradually developing a model for measuring their engagement.

It all started with login counts
A couple of years ago I started displaying how many times the person who signed up for an account has logged in. This was immediately insightful – at that time 90% of my trial customers were logging in once and then never logging in again. Of the 10% who were left, most of them bought a subscription.

This intrigued me and I started calling customers, as I mentioned above. I was really trying to figure out why they never logged back in after signing up, but I got distracted by the effect calling customers had on their purchasing decision and stopped asking about why they hadn’t logged back in. My logic then was simple – calling them had created an incentive to look more thoughtfully at TroopTrack so why bother figuring out why they’d given up the first time?

Engagement is more than just how many times the account owner logs in
Since that discovery way back when I’ve watched login counts quite carefully, if not formally. If the person who signed up for TroopTrack (i.e. the account owner) logs in a second time, I have a dramatically better shot at signing them up. I began to wonder what else I could look at to figure out how engaged my customers are during their trial period. So I added another metric – the total number of users in a troop and the number of times they had logged in.

New observations emerge
The user count helped me understand something new about my customer’s behavior. Most trial accounts that don’t convert only create one other user – a scout. It makes sense to do this – they want to see what info we track for a scout right away so they go there first. That seems to be the general first milestone: Add a Scout.

The next milestone I’ve observed on the path to purchase is similar: the account owner adds another adult user and invites them to check out TroopTrack. If this person logs in more than once then things look good. How good? No clue yet.

There’s one more milestone that I can currently see that is important: loading users en masse. At some point in the trial a troop adds more scouts and adults and invites them all to check out TroopTrack. At this point they have pretty much already made a decision to purchase and they are just waiting for the trial to expire and for me to ask them to pay up.

The Engagement Metric
This morning I decided to add a new metric to my admin console. I call it the activity score. There are a lot of things a troop can do during their trial period, and I’ve decided to give them points for each of them. The points aren’t weighted (yet) but they may be later on. Basically, I assign an activity point every time a troop member does something I care about, like log in, add a user, record an award, upload a photo, plan an event, etc. I aggregate these points in my admin console and I plan to keep a record of the number of points a troop has on the last day of their trial period as well as the outcome of their trial (purchased, didn’t purchased). It will be interesting to see what I learn from this.

I’m also thinking of adding a features used / not used list for each trial account. That will help me know what to talk about when I give a troop leader a call and offer to help. If a troop isn’t using event management, I can talk with them about that. They might be having trouble figuring out the features they aren’t using and I can help them out with it. I hope that will help.

PayPal sends me more emails than anyone else except pivotal tracker, and that’s awesome
Right now I get an email from PayPal almost every day. Yeah, you got it – someone sends me money almost every single day. It’s pretty cool. It’s not a lot of money, from $5 – $200, with the average being significantly closer to $5 than the latter.

I’m not entirely sure how relevant that little aside is to my rambling about engagement, but it’s important to me. After four years of plugging away on TroopTrack, I still believe, and the evidence that I should believe gets a little better every day. Just sayin’.

Configure garbage collection settings for ruby
Starting with Ruby 1.9.3 you can configure the GC for rails in environment variables. Ruby GC defaults are way too low for rails, so it helps a great deal to bump them up. I use the defaults that come with REE, namely:
RUBY_HEAP_MIN_SLOTS=600000 RUBY_GC_MALLOC_LIMIT=59000000 RUBY_HEAP_FREE_MIN=100000

Set up Nginx to cache assets for a really long time
Thanks to the new asset pipeline and the precompile step, you can improve asset performance by caching the heck out of your assets. I use Nginx a lot and this is what I put in the config:

location ^~ /assets/ {
 gzip_static on;
 expires max;
 add_header Cache-Control public;
}


I got this tip from Ryan Bates’ railscast on the asset pipeline, .

That’s all I’ve got for now but hopefully I’ll collect some more bits here over time.

Basically, if you (metaphorically) placed Rework and The Lean Startup in a blender, turned it to high, then ran the puree through a mumbo-jumbo filter (basically the last 1/3 of The Lean Startup would get removed), the remaining juice would be called “The Lean Bootstrap”.

My Life is Sometimes a Study in What Not To Do

About three weeks ago I released TroopTrack 3.0. It was a huge deal. Here’s a list of some of the major changes in this release:

• Moved from a single slicehost server to a distributed environment using Amazon S3, RDS, and EC2
• Upgraded from Rails 2.3.8 to 3.2.2
• Completely redesigned user interface
• Re-designed the inbound email server (TroopTrack includes a distribution list server)
• Consolidated several different features into one and completely re-designed that one feature
• Switched to Twitter Bootstrap
• Added very fancy CMS capabilities
• Switched to an asset pipleline

That’s just a sample. The release took just over a year from start to finish. At the same time that I was working on the release, I continued to support the existing version, and I found myself saying “this will be better in 3.0″ a lot. The more I said it, the more customers wanted to know WHEN 3.0 was going live. “Q4!” I said. Then it was “January”. Then it was “February!”. Then I promised March. And March it was.

The release was a total disaster. There were too many things going wrong simultaneously. There were environmental issues. There were problems re-processing all the user uploaded images to give them the new styles. Users were confused by the new interface. There were bugs.

Worst of all, I forgot to take down a “This is a beta site” on the log in page that warned users that beta sites were unreliable, not guaranteed, and not expected to be nice. This totally freaked users out, and it took me a while to figure out why they thought they were using a beta site.

Users got angry. Some threatened to leave. One demanded a refund (I gave it to him, right away – I don’t mess around with refunds). I started fixing bugs, but the requests just kept flooding in. I went from 100 open helpdesk tickets to 250 in no time flat.

It was horrible. At one point I had a panic attack. Had I finally managed to sink my lean bootstrap? Was the game over? Had I created a self-imposed runway and then crashed the plan right onto it?

Um, wait, aren’t you that lean/agile guy?

Well, I’m not THAT guy, but I am A guy. And yeah, I am pro-lean and pro-agile. Heck, I wrote a workshop on it. I spent more than a year helping a midwestern insurance company through the difficult value/culture/process shift from waterfall to agile. And yes, I work at DeveloperTown, where we are totally into lean startups.

That said, there was nothing waterfally about TroopTrack 3.0. It was agile all the way through except for one teensy little detail…

Release Often

I didn’t have to do such a huge release. I could have done these things one at a time, like this:

• Release 1: Upgrade to Rails 3.2.2 sans asset pipeline
• Release 2: Roll the infrastructure over to Amazon
• Release 3: Switch to the asset pipeline
• Release 4: Re-design the user interface with Twitter Bootstrap
• Release 5: Re-design the inbound mail server
• Release 6: Consolidate features
• Etc

That’s what I should have done. I don’t need hindsight to tell you this – if you brought me your project and proposed a big release like this I would tell you to break it up into smaller chunks and release it one chunk at a time, and I’d be right. That’s a lot less risky.

So why didn’t I do it right?

It takes discipline to release often

In many ways, I have spades of discipline, but not in one: I can’t always resist the temptation to start one feature before I have finished another. New releases of gems and other shiny objects call my name like chocolate chip cookies haunt Snoopy. So, part way through the UI re-design, Rails 3.1 came out and I thought “What the heck?”. And I started on it. Then I got back to the UI re-design, except part way through that I thought “Events would be much easier if I consolidated X, Y, and Z first”. So I started on it. Next thing I knew, the release was huge and, instead of having a small release every two months or so, I was ignoring my users, making promises I couldn’t keep, and, when I finally released the product I had so much in it that I totally botched some critical but simple details.

X.0 releases create a runway you don’t need

One of the key principles of a lean bootstrap is the infinite runway. A runway is defined as the number of months or pivots you have left before you run out of resources to continue operating your startup. There are different types of resources, but the four key resources you need to keep on eye on are cash, time, talent, and optimism. Any decision that puts a cap on one or more of these resources is risky and should be considered very carefully.

An X.0 release is a big, dramatic release. Anything that drags on more than two months is probably an X.0 release and represents a big risk to your lean bootstrap because you are spending your cash, time, talent, and optimism on an unvalidated investment that may or may not work out. The more of your resources you dump into the X.0 release without validating that you are doing something awesome, the more likely it is that a big chunk of that investment is going to be garbage and be rejected by your users.

Optimism is your most valuable resource

I’ve seen crunches in all four of the resources I mentioned above, and most of them can be solved by patience. If you are low on cash, you can just slow down a bit, skip the Starbucks, and be okay. The same is true of time and talent – you can modify your pace to preserve those resources. But optimism is hard to predict and plan for, and emotional deficits can be hard to make up. A bad X.0 release can sucker punch the optimism right out of you like you wouldn’t believe.

If you screw up and get in too deep, back it up if you can or stay the course and muscle through

What do you do if, part-way through a new effort, you figure out that it is getting out of control?

You have two choices: go back to the point where you made your first bad decision and finish just that piece, or soldier through. I vote for going back. If you use a decent SCM and good commit messages, this isn’t usually too hard.

If you decide to soldier through, you need to draw a line in the sand and don’t cross it again. Finish what you started. Release it. Get feedback. Then do the next thing.

There will never be a TroopTrack 4.0

I have learned my lesson. I’m through with big releases. In fact, I’m moving the other direction, back to the way it used to be before I started 3.0. Nightly releases. Small changes. Incremental improvement. Feedback cycles of a day or less. That’s the way I roll.

• Yukihiro “Matz” Matsumoto – the inventor of Ruby, a language that revived my love of programming and turned my career back into a passion. My interest in meeting Matz is amplified by our common connections to the LDS church in Japan and in the way he inspires the ruby community to be helpful and friendly.
• Stephen King – one of the most prolific American writers ever and a true craftsman. His career is evidence of something I really believe – that if you keep trying to improve at something you care about, you will, and it will matter.
• David Heinemeier Hansson & Jason Fried – As much as I appreciate Ruby on Rails, the attitude these two guys have about building a good business has influenced me more. At some point, something better than Ruby on Rails may come along, but the bootstrapper mentality will always be relevant.
• Carl Erickson – the founder of Atomic Object in Grand Rapids, MI, Carl exemplifies the leadership qualities I admire most. Technically, I’ve already met him, but if I hadn’t he would be on this list. If you care at all about building a company that is great, but not necessarily big, you should follow his writing.

This isn’t just a list of people I want to meet, it’s a list of people I try to be learn from and be like. So, if you’re on this list, thanks for your example. I appreciate it.

Dave

• How To Pronounce Indian Names
• How to Write a Self-Appraisal

These two pages are highly ranked in google and account for most of my search driven traffic. As a result, they generate between $800 and $2000 per year in ad revenue. If I had sold them to a magazine, I might have made $300 each. Once.

But that’s not my only self-publishing experience. The books for the classes I teach are also self-published. Exploratory Testing Practicum is published on Lulu and I publish Immersive Agile and User Stories for Business People at FedEx. Granted I sell them privately, but the point is I am no stranger to the work required to create a printable book.

I also published one of my works of fiction, Alter Ego, on Lulu.com. I laid out the book myself and designed the cover on my own as well. It shows. I can’t wait for the new version of Alter Ego to be out – the cover is infinitely better.

The Manuscript in my Drawer
I wrote Genesis 2.0 several years ago and for a long time I was determined to publish it traditionally. Even though I already had a grasp for the long tail of publishing independently, my egotistical need to win the approval of the publishing establishment held me back. I wanted it. I got pretty close to getting it, I think. I was able to interest a top agent to read it twice and send me an extensive critique of it. But I also garnered a pile of rejection letters from people who couldn’t be bothered to read a single word.

About three months ago I finally got over myself and decided to self-publish. Wary of my not-so-stellar artistic work preparing Alter Ego for publication, I decided to enlist the help of a real artist for the cover and creation of the eBook. Genesis 2.0 is a story I really love and I wanted the book’s appearance to reflect that.

An Option I Couldn’t Afford
Based on the recommendations of Joe Konrath and others, I contacted artists who create eBooks and eBook covers and quickly learned that it would cost $400-500 to prepare Genesis 2.0. This isn’t necessarily a bad investment, but at that moment in my life I couldn’t afford it and I decided to wait. I also wanted to re-issue Alter Ego more attractively (the new version is coming soon!), and altogether I would have been out at least $800.

That wasn’t happening, not after I burned through a small pile of cash on a small marketing experiment with TroopTrack.

Along Came Booktango
Partly because of the work I’ve done on Author Learning Center and partly because of my love for writing, I was asked to participate in the beta program of a new self-publishing package called Booktango. With Booktango, you can create an eBook from your manuscript and distribute it to all the major channels for free. Or, if you’d like additional help with your cover or some art inside the book, you can purchase a package for $49 or $189 depending on your needs.

I used the $49 package and published Genesis 2.0 and Alter Ego. I was surprised by how easy it was to take a Word manuscript and turn it into an eBook. Really, you just upload the file, spend a few minutes resolving any errors it finds, fill out the metadata about your book, describe your cover, and submit. It was quick and easy.

I was naturally skeptical about the cover design that I would receive. After all, the prices I had been quoted by artists were a lot more than $49, and I wanted my cover to look good.

I was stunned when I saw Genesis 2.0′s cover. It’s awesome. I love it.

The other thing I was worried about was what the interior of the book would look like. There’s currently no way to preview your eBook, but again I was very pleased with the end result. I’ve been told previews will be in a future release of Booktango and I look forward to that.

I was pleased that the table of contents was created for me – that was something that was a bit unclear to me at the time.

In the interest of true disclosure, I did run into a few problems while I was creating my book. There were some small issues with saving data along the way, and the user interface, while not bad, is also not awesome. But it’s easy enough to use. The cool thing I learned as I encountered and reported my problems is how responsive and helpful the Booktango staff is. They made it super easy.

The Bottom Line
I couldn’t be happier with the Booktango product. As soon as I saw Genesis 2.0 on my Kindle I decided to re-issue Alter Ego through Booktango as well. I can’t wait for the moment when I can take the old picture of Alter Ego down from the side of my blog and replace it with the new one.

So, would I recommend Booktango to other writers? Heck yes I would.

Minutes after posting this, I discovered that Alter Ego is complete – the cover on the right is the new cover, not the old one I designed myself.

Basically, if you (metaphorically) placed Rework and The Lean Startup in a blender, turned it to high, then ran the puree through a mumbo-jumbo filter (basically the last 1/3 of The Lean Startup would get removed), the remaining juice would be called “The Lean Bootstrap”.

Starting a company is easy
Anybody can start a company. You can probably start a company and request a federal EIN in less time than it takes to read this post. The hard part is what happens next. And next. And next after that. And next afta afta. And so on. For a really long time.

A lean bootstrap is like Mormon heaven
When Baptists die and go to heaven, they get to spend eternity leisurely singing in choirs and enjoying freedom pain and stuff like that. When Mormons die and go to heaven, we get to keep on working. Forever.

(Please note: This bit is meant allegorically. I’m not an expert on Baptist or Mormon heaven. Comments about either religion where the author appears to be wrapped around the axle or totally off-topic will just be ignored).

I’m not trying to paint a drab picture of what a lean bootstrap is like, or of Mormon heaven either, for that matter. In either case, if you are motivated by your love for solving a particular problem, and not just chasing Dante’s banner, the news that you are going to spend what could be years and years of your free time working on that problem is not exactly bad news. But you still need to take steps to make sure that you can sustain the effort required for as long as you need to.

A supportive life ecosystem is key to sustainability
Shannon and the kids believe in TroopTrack. When my founding partners quit a few years ago, I got a bit despondent. I almost gave up, but Shannon wasn’t having it. She KNOWS that someday we will make enough money off of TroopTrack to support our family, whether it’s another two years or another ten years she doesn’t care. I also have friends who have started their own lean bootsraps with their spouses, and we encourage and support each other.

But that’s not the only part of my life ecosystem that is supportive of TroopTrack. My employer, DeveloperTown, is also behind me. When things go wrong (like OOM errors on my productions server last night), my colleagues at DeveloperTown help me out. When I need work in an area where I lack talent, like graphic design, I can get that help at work. My work schedule is also flexible – I get to choose when I work on TroopTrack and how much, as long as I continue to meet my work obligations. This is a very big deal. Just sayin’.

Financially, I can’t afford to lose much money on TroopTrack. I have to be careful about what I spend on infrastructure and marketing, because I can’t burn money like a VC-backed startup. Heck, I can’t burn money like a single kid leaving in his Mom’s basement. I’m working on changing our lifestyle so that I can spend more on TroopTrack each month, but no matter what I’ll probably never be able to lose more than $1000/month on TroopTrack. Right now, I try to keep it under $100/month on average.

Your life ecosystem is different from mine, but you need to take a good hard look at it. Is it going to help you or get in the way? When your face is swollen and bloody and your head feels like it’s going to explode, is your life ecosystem going to push you back in the ring or tell you to throw in the towel?

You Can Make It Easier to be Supportive
Running a lean bootstrap is a choice. Don’t make supporting that choice harder than it needs to be – you want it to be as easy as possible for your life ecosystem to support you. Here are some things things I’ve done over the years to make it easier on my life ecosystem to believe in and support my ongoing commitment to TroopTrack. Most of them involve me giving up my personal time so that TroopTrack steals less time from my family.

• I all but stopped watching TV, including 95% of all the sports I used to watch.
• I knocked my personal spending down a big notch – no more weekly trips to Fry’s, no more casually dropping an unplanned hundred bucks at a bookstore
• I changed jobs to work for a company that is supportive of my efforts
• I learned enough about taxes to be able to deduct the money I spend on TroopTrack
• I (temporarily) gave up on a plethora of hobbies I love, including reading (I only listen to books when I drive now), writing fiction, wakeboarding, working on my boat, working on my beetle, etc

Don’t be Bob Kearns
Some people will ruin the best part of their lives in pursuit of a lean bootstrap dream. Don’t be that guy. Don’t be Bob Kearns, the inventor of the intermittent windshield wiper. His stubborn determination to beat Detroit cost him his family and friends. His obsession with winning overtaxed his life’s ecosystem and wrecked it. Or at least that’s how the film “Flash of Genius” portrays his life.

Every entrepreneur is, in a way, like Bob Kearns. I have an idea I feel passionately, perhaps even obsessively, about. I work on it every day. I’m trying to take on and beat bigger, older competitors who already have a product that is well-liked and well-used. I have scant resources outside of time and expertise. And yet I still feel like I can win. True victory doesn’t come at all cost. It needs balance and support from the outside. Do what it takes to make it easy to support you by sacrificing the unimportant stuff you love like TV, hobbies, and the latest books, not the stuff that matters.

Note: It’s worth mentioning that my family is not supportive of the fact that I’ve stopped writing fiction, stopped working on my beetle, and stopped wakeboarding. That’s fun stuff we all enjoyed and they want it back.

Basically, if you (metaphorically) placed Rework and The Lean Startup in a blender, turned it to high, then ran the puree through a mumbo-jumbo filter (basically the last 1/3 of The Lean Startup would get removed), the remaining juice would be called “The Lean Bootstrap”.

Dante’s Banner
In Dante’s version of hell, the souls of the uncommitted reside somewhere between heaven and hell where they are condemned to chase a banner blown around by the wind, never catching it, forever pursued by a mob of angry hornets.

Ouch.

Dante’s Banner for the Lean Bootstrap
In the lean bootstrap’s version of hell, the soul of the entrepreneur resides somewhere between success and fail where they are condemned to chase a hundred dollar bill blown around on by the wind, never catching it, forever pursued by a mob of demanding users.

Don’t Start a Lean Bootstrap Just to Get Rich Quick
Early on in TroopTrack’s history my partners and I had impossibly naive expectations about growth and profitability. I honestly believed all three of us would be working on TroopTrack full-time within a year of launching. The market was RIPE for a superior product to sweep in and steal a ton of market share before the competition could respond. So we set up an agressive timeline – we would launch a beta product within six months, then sit back and watch the money roll in.

Because we knew we were just a year away from being rich, we worked on TroopTrack in an unsustainable way. We got worn and burned out, stress started to pile up, and we began to have the disagreements typical of people who have sacrificed emotional, physical, and mental health for a “greater good.”

Our launch was a big thud. Our product was buggy and unstable. We didn’t have good ways of keeping track of customer feedback or monitoring exceptions as they occurred within our code. We didn’t know how bad our product was!

During this time, my desperation to generate revenue and prove that we had a “good” product took me down a thorny path. I started chasing deals with sponsoring organizations of multiple troops and tried signing them up en masse at a steep discount. The fact that I was occasionally successful at generating interest and once even closed a deal only made this inclination worse. I chased deals with churches, scouting districts, and charities with programs that are similar to scouting. I even considered a massive pivot to re-tool TroopTrack to support the Air National Guard!

The toll of this constant churning plus the feeble response of the market place was too much for our partnership – roughly eighteen months into it we dissolved and went our separate ways.

Start a Lean Bootstrap to Solve a Problem that You Care About
It took some soul searching and a certain degree of stubbornness, but I didn’t give up on the TroopTrack product after the original founders split up. It’s been years since then, and time has given me a certain amount of perspective about why I continued on alone. I think there is a lesson to be learned from my experience and the differences between why I was involved in TroopTrack and why my partners were.

In hindsight, I think the critical factor was the source of my interest in TroopTrack. It was based on my involvement in Scouting as an adult. I was frustrated by the products that were available – they were total crap and I needed something better. My partners, on the other hand, were recruited (by me) and persuaded to join based on the MARKET POTENTIAL of a superior product. They didn’t have any real experience in scouting but could see what a windfall capturing a corner of the scouting market would be financially.

In other words, I finally realized that I persevere with TroopTrack because, among other things, I am trying to solve a problem I really care about.

Love It or Leave It
Years later, I wish I had approached my partnership in a different way. Nothing against my former partners – they are both fine people and good programmers. But if I could do it all over again I would pick someone else. I think it’s fair to say that if THEY could do it all over again… they wouldn’t.

I believe now that I would have been better off picking a business partner who was motivated by a love of scouting and was also frustrated by the quality of products available to scouters. Even a non-technical partner of this sort would have been a better choice in the long run. Their insight into the way scouters perceived TroopTrack would have been much more meaningful than the acceleration gained by recruiting additional development talent.

I think I also would have been better off if I had just had a different attitude about TroopTrack in the early days. I convinced myself that it was an easy way to get rich doing something I cared about because I didn’t realize that just caring about something is enough justification. There doesn’t have to be an obvious path to wealth to make something worth pursuing. If you’re going to trudge the long road of a lean bootstrap, you better get on that path because you care about solving a problem, not because you want to get rich.