Ronin Blog

Throughout any given software developer’s career, I think he or she is bound to run into a few archetypal projects. Some are good projects to have experienced, others not so much. Either way, I find these are the projects that offer up the biggest smack-in-the-face lessons.

I also find that the order I’ve laid out below tends to mirror the progression of a software developers career chronologically as well.

The school project

I love this one, because this is where a large number of hackers become “software engineers”. Or so says the industry and HR people. The only reason I value this type of project is because it’s such a stark contrast to how development happens in the real world. Somehow, the particular mix of apathetic group members + hero group member + late nights in the computer lab makes for good memories to reminisce after you’ve been in the software industry for a while.

The “I can do that in a weekend” project

Don’t lie - the first time you saw twitter you said, “I can write that and more in a weekend.” Maybe not twitter, but we’ve all run into successful apps and scratched our heads pondering what the big deal happens to be. So go ahead, write it. Build that app. Then eat dirt. I find this is the fastest way to learn that 1. no, it’s not that easy, and 2. even if you built and launched a me-too app, no one cares.

The “I’ll build it from scratch” project

This is another one too many of us have had the guilty pleasure of partaking in. Instead of taking well-known and well-document open source solutions already out there, you decide you can do it better yourself. More often than not, you walk away with a new appreciation of that whole shoulder-of-giants saying. Then you start shopping.

The “other platform” project

Everyone gets curious about the greener grass on the other side. So appease the need. If you’re a *nix/apache type, give .NET a shot. If you’re the .NET type, give open-source platforms a shot. Loving Java? Try C#. RoR expert? Give Django a shot. Learning both sides is not so much for gaining actual experience as it is for gaining perspective. My personal experience has shown that you just might stay on that new platform. (Of course, most of my experience has been of the Microsoft camp going open source.) At worst, you’ll know you validated the choices you made going into your current setup.

The “coding as a job” project

If you haven’t already, get a job (at least once). It’s a quick shot of reality and harsh perspective. It helps you realize what engineering in the wild is like. Product managers, program managers, project managers, mid-level managers vs. you. It helps you realize whether working in a team is your strength or your weakness. It helps you learn to curb that ego of yours. It makes you appreciate just how difficult running a business is, aside from the technical side of things. Observe the sales people, watch the BD team. Learn their tactics, their way of doing things. It will make you a more well-rounded individual. If nothing else, you’ll learn what kind of software and services the suit-and-tie crowd really need.

The startup project

The beauty of software is that everyone’s got an invitation to start something up. This is more than just a “all the cool kids are doing it” thing - I feel that everyone should try to build a project (and eventually product) that brings real value to people. In fact, try charging for it. Nothing validates your ideas, concepts, beliefs, and ambitions more than getting others to give attention to what you’ve got to say or sell. If you fail, no big deal - you’ve learned something valuable and chances are you lost nothing but a few weekends and hosting money. If you succeed, well then it’s all the more rewarding.

The open source project

This is where the “end-game” of software development happens. You go through life looking for projects to be passionate about. You’ve gone through school and pulled through the grind. You’ve tried the whole day job thing and you’re either feeding your family or you’re looking for a new cause. You’ve done your own start up, for better or for worse. In the end, you begin to realize nothing is better than sharing your great hack, tool, technology, algorithm, framework, project, or application with the world. I find that the sense of accomplishment that comes with open source projects spans the spectrum from being the sole maintainer of tiny, obscure plugin to being a drop-in-the-bucket contributer to a massive framework.

I feel like today is the day after the lottery for all of web 2.0. You know, the day where you look down on your ticket comparing your numbers to last night’s numbers. Then you sigh. Game over. You just lost your dollar.

Oh wait, but I forgot, the lottery is for under-educated poor folk who are desperate to get rich. What’s the difference between that and the game the Silicon Valley has been playing for the last 2 years? What’s the difference the lottery and the game played in the early 2000’s? From all of this web 2.0 stuff, we’ve basically learned that the exceptions (Google, Youtube, Facebook) got rich, while the rest got/are getting shafted.

However, when one door closes, another one opens.

First, this is a great opportunity for businesses with legitimate, sustainable models to separate themselves from the rest of the pack. More signal, less noise for all of us. Similarly, this is an opportunity for those with unique talents to find themselves in smaller, leaner, more efficient teams. At the end of the day this will reward responsible companies that curb spending and reduce burn-rates.

Second, the opportunities for areas outside of consumer web space finally have a chance to shine. No more showing up for VC pitches only to be asked, “does it come with a Facebook app?”. Companies that focus on selling actual products with actual price tags will be rewarded.

Third, for developers, a whole new world of viable alternatives opens up. The Rails community seems to be happy about the opportunities present in the downturn. However, there is no better time to start your own indie developer shop. For example, maybe it’s time to start desktop development again - the market for Mac software products grows with each day, and incumbent developers will tell you there is a lot of money to be made.

At the end of the day, jobs will be lost, families with be affected, and people will have to search for their own answers. But, we just have to keep our heads up and look for that next open door.

I came across a great article by Cameron Herold guest blogging at Tim Ferriss’s fourdayworkweek.com blog. He writes:

Regardless of whether or not you believe you will ride an emotional rollercoaster running a business, you will. You have two fundamental choices: you can hold on and scream, or you can wave your hands in the air and have some fun.

Also, you’ll find Marc Andresson’s precious nugget of wisdom being quoted as well:

First and foremost, a start-up puts you on an emotional rollercoaster unlike anything you have ever experienced. You flip rapidly from day-to-day – one where you are euphorically convinced you are going to own the world, to a day in which doom seems only weeks away and you feel completely ruined, and back again. Over and over and over. And I’m talking about what happens to stable entrepreneurs. There is so much uncertainty and so much risk around practically everything you are doing. The level of stress that you’re under generally will magnify things incredible highs and unbelievable lows at whiplash speed and huge magnitude. Sound like fun?

I can’t stress enough how important it is to recognize and respect the awesome force that is human psychology as it comes into play during the hectic start-up phase of a company. More often than not, however, setting the right expectations and being informed about your particular industry means you can flatten the so-called “Transition Curve”.

The problem I find with today’s entrepreneurs is that the optimism is often too overbearing. Perhaps it’s the romanticism with which we surround the notion of a “start-up”. Perhaps it’s because people are starting their own companies at younger and younger ages. Perhaps it’s because a lot of tech start-ups are headed by folks who know more about cool technologies than running actual businesses. More likely, it could be because VC money is (or at least was) too readily invested. Whatever it is, the right expectations are not being set to counter-act what Cameron refers to as the “Uninformed Optimism” phase of start ups.

My advice, for what it’s worth, is that you should find something you’re passionate about, persist at it, and do your research.

In his book “The Design of Everyday Things” Don Norman talks about mental models as a way to describe how a system is perceived from a designer’s perspective vs. a user’s perspective. The trick in having an application that feels natural for users is to have those two perspectives be as aligned as possible.

A few weekends ago, when I was conducting usability testing for Ronin, I noticed that the subjects were often clicking the upper-left logo to go home. This is a common paradigm on the web, and it’s often very acceptable to have the upper-left logo act as a “reset”, but I was disappointed in the inefficiency of navigation. For example, for a particular user to navigate to a certain invoice, he would click home, click on the client’s name in the “Recent Clients” section and then navigate into invoices from there. He would also frequently click from one client to another using “home” as a bridge while scanning for open projects. While this didn’t seem like much work (and he pointed to me that he didn’t mind it at all), I felt that the mental model he has established for the application didn’t quite match the mental model I had in mind as the designer of the application.

One problem I identified was that he used home as an entry point because it was the only thing common to all pages - the fact that they were tied to the home page somehow. The lack of consistently available top-level navigation made it impossible for users to develop a deeper, more accessible mode of traversing through the app.

Enter tabs.

Tabs help to establish a clear mental model.

What you’ll notice if you study most applications is that there is always a highly visible interface component that helps users establish a mental model of how to interact with the application. Media players typically have play/pause/stop commands, browsers have back/forward/address-bar, and web applications typically have tabs, or some high-level navigation element.

After adding the tabs in, I found that it helps reassure users of exactly what Ronin is designed to do. It helps scope the application so there is less learning time when a user first jumps into the application. It clearly maps out the high level concepts of “Clients”, “Projects”, and “Invoices” and gives users a consistent anchor to use apart from “home”. You’ll find that these tabs have been implemented into Ronin.

We as humans continually evaluate and reason about the things we perceive. Unfortunately, being subject to so many new ideas and applications means we can only commit a large part of our learnings to standard interface elements and practices. It’s up to the application designer to keep in mind that helping nudge this process along is often means obeying age-old rules of thumb. In this case, it’s “always have visible, clear, top-level navigation.”

I love Otherinbox. I think it’s a great tool to manage the email overload we’re subject to in this web-world of ours. But, getting my friends and family to check it out is impossible.

Why? Because they hit otherinbox.com upon my recommendation and they’ll look at and it and say “WTF am I looking at?” (exaggeration mine). So then it’s up to me to explain to them what it is, how it’s set up, why they need it. I realize after doing this a few times that it’s not up to me to explain other people’s products. That’s what a freaking homepage is supposed to do.

My advice: if you’re building a product homepage, you better have a 1-liner that makes people “get it”, because the one thing we’re short on in this information overloaded world is attention. (This is the same advice for sales pitches, VC pitches, whatever.) Your homepage is an elevator pitch. Heck, I’ve been elevators that move a lot slower than people skimming through product homepages.

The very opposite of that is a blog-driven product homepage. Blogs are for articles, news items, random-thoughts, not for product explanations. Maybe it’s just me, but when I see a homepage like that, I wonder why people are too lazy to make a good homepage.

I’ll give Otherinbox the benefit of the doubt and pretend that because they’re in private beta, they want to turn people away… (yeah, right).

Also, if someone from Otherinbox happens to run across this blog entry - change your favicon, please. It’s still running the Typepad default.

I ran into this little gem today: Golden Rules for Making Money by P. T. Barnum (1880). It just proves nothing changes when it comes to the fundamentals of making money. However, these days, there’s an extra word, instead of “Making Money”, it’s now “Making Money Online”. Just ask David Heinemeier Hansson, he was even compelled to give a talk on the subject.

Well let’s see what the new-age twists are on these Golden Rules. What changes to P.T. Barnum’s rules when we apply web 2.0 logic to it? Half-seriously, I call it Golden Rules for Making Money 2.0 (web entrepreneur edition).

1. Don’t mistake your vocation -> Hackers should code, designers should draw stuff in Photoshop, and Businessmen should sell and give VC pitches.
2. Select the right location -> Move to the valley. Or at least be in India or China.
3. Avoid Debt -> Splurge on someone else’s dime. Get VC money.
4. Persevere -> “Startups rarely die in mid keystroke. So keep typing!”
5. Whatever you do, do it with all your might -> Stick with Ruby.
6. Depend on your own personal exertions -> Take as few partners as possible. More sweat equity.
7. Use the best tools -> Stick with Rails.
8. Don’t get above your business -> Release early, iterate often.
9. Learn something useful -> Learn Scala or Erlang on the side.
10. Let hope predominate but be not too visionary -> Do something small …
11. Do not scatter your powers -> … and do it well.
12. Be systematic -> Switch to 4 day work weeks.
13. Read the newspapers -> Read Blogs.
14. Beware of “outside operations” -> Don’t blow your exit money on another venture. See rule 3.
15. Don’t endorse without security -> VCs: invest in people with previous exits.
16. Advertise your business -> Use Google Adwords.
17. Be polite and kind to your customers -> Offer email and phone support.
18. Be charitable -> Open source parts of your code.
19. Don’t blab -> Get IP. Enforce it.
20. Preserve your integrity -> Don’t comment spam or SEO spam to get traffic.

See? It’s basically the same thing nearly 130 years later.

Effective development of any project (whether web or otherwise) requires effectively “scaling” the code-base. The experienced shops like Amazon break their code into services - modular components that are easy to understand and maintain by a small group of developers. I don’t need to hark on the benefits of modularity, but one can never overstate the importance of having a “shallow” code-base. The best software architects know this, and the big shops apply these techniques effectively.

However, from my observations, CSS always tends to get left out of good code-base architecting. That’s probably because designers who work with CSS only do it as a means to and ends - getting a pretty and usable design, while developers who work with CSS couldn’t run away from it fast enough. It’s stuck in some void where people approach it with a 10-foot pole.

Oddly enough, it’s CSS that is often in most need of solid architecting. After all, the “language” (if you can call it that) sucks, was poorly designed, doesn’t work consistently in most browsers, isn’t DRY, and makes people want to take a sip of the old table driven kool-aid once in a while.

Here’s how I approach the problem:

1. Break your CSS files down. Give your CSS files short, easy to understand names. “basic.css” is not a good name. What’s basic about it, exactly? “main.css” is a poor name. Is it the main CSS file or CSS for the page called main? I like to use “common.css” for CSS patterns (more on that later), “style.css” for styling only (more on that later) and “x.css” for pages called x.
2. Use an asset manager. This goes with number 1. Breaking your CSS down into small chunks means more round-trips if you <link> each stylesheet. Go with an assest manager to bundle all those files for you. For example, try bundle-fu for Rails.
3. Separate styling and layout. Styling is what your <em>s <strong>s <h1>s look like. Layout is probably specific to the page. Get detailed. “styling.css” can be for basic HTML elements, “styling-modules.css” can be for styling specific to reusable modules, etc. Developers call it separation of concerns. CSS designers call it sanity.
4. Don’t put IE specific hacks into their own file. (Only do this if you don’t care about validation.) This flies in the face of convention wisdom. Well, the next time you’re wonder why something looks different in IE after pouring through your CSS, only to realize 30 minutes later that something’s inconsistent in “ie6.css”, don’t forget what I told you here. IE specific CSS files are un-DRY. Instead, put the hacks as close to the non-hacked CSS as possible and document it.
5. Use common patterns. People spent countless hours on things like clearfix and the holy-grail so you don’t have to. Put these common patterns into their own file (I like common.css and common-layout.css) and don’t mess with that file.
6. Use a reset. This is an extension of #5. Resets means your CSS works tabula rasa. No more wrestling with inconsistent browser defaults. Try these reset rules. Make sure you document any exclusions for bandwidth saving reasons.
7. Use white-space effectively in CSS files. This one doesn’t work for me, but I’ve seen people swear by it. Use indentation to mimic the DOM hierarchy when you’re doing complex selectors.
8. Document CSS like you would document code. And realize that sometimes the best documentation comes from having well thought out CSS in the first place, just like how good code documents itself. If you’re working in an environment where many people are touching the same CSS files, having everyone understand the organization (see #1) is the only documentation you’ll need.

I’m sure there’re are more best-practice approaches to “scaling” CSS so that more than one person can work on it without going bananas, but these work well for me. Heck Ronin only uses a subset of these rules, and it’s already saving me my sanity. Google around and maybe you’ll find more to add to this list.

The mantra of the web 2.0 app is to release early, iterate often, and repeat. A big part of the “iterate often” though, can be confused for rolling on your own intuition. Even a great dog-food eating developer won’t be able to guess exactly what his or her customers want. After all, every individual is different.

This past week, the buzz in the developer world was/is Jeff Atwood and Joel Spolsky’s stackoverflow.com. One particular off-topic item that immediately caught my eye was the floating “Feedback” tab on the left side of the screen. I thought this was brilliant. It was an personal invitation for users of the site to express their opinions and cast their vote on suggestions for improvement. 

After clicking on this Feedback tab, I realized that this was a service provided by UserVoice. The folks at UserVoice have come up with a simple, easy-to-install widget that every web service out there can take of advantage of to quickly gather valuable user feedback. Brilliant.

Being a big fan of gathering feedback for product direction, I decided to look into it for Ronin. By the time I hit publish on this blog entry, you’ll be able to find the Feedback tab in your Ronin account. Use freely.

I’ve been a part of quite a few startups with varying degrees of involvement. I’ve been a part of them, studied them, worked for them, observed my friends involved in them, heck, even started them. I’ve watched them grow, watched them plateau, watched them die. If I had to distill my entire experience with start-ups into one rule of thumb, it is that start-up life is a roller coaster. A manic-depressive roller coaster.

No seriously. You are not ready.

Paul Graham writes:

One minute you’re going to take over the world, and the next you’re doomed. The problem with feeling you’re doomed is not just that it makes you unhappy, but that it makes you stop working

This cliche metaphor about roller-coasters is not news for anyone who’s read anything about the scene - it pretty much goes in one ear and out the other for the entrepreneur. However, I find it only really hits people hard when they get a taste of the roller-coaster of emotions first-hand.

I’ll be the first to admit that I had very little understanding of just what this roller-coaster feels like. When I was 17, I had my first experience at “entrepreneurship” building a small Windows application that was simple music production tool. In retrospect, it didn’t stand a chance, but I was young.

At the time, it was project of love. I didn’t necessarily want it to become a business - I just wanted people to like it. But, I think somewhere along the way, ambition snuck-in and turned it into more than just fun. I would devote time every day to working on my code. I would scour the internet seeking best-practice advice from peers twice my age. I would dream about features to be added in between classes. I would gather feedback from close friends - all in a very self-assuring feedback loop. Being young, every line of code, every keystroke, was fueled with “what ifs” - tell-tale signs of foolhardy ambition.

What-ifs are always escalating. What if my friends really love my app? What if it gets the attention of a small group of people? What if garners the adoration of hundreds of users? Thousands? Tens of thousands? What if people like it so much, I’d be able to pay for college just on software sales? Maybe even make a living off of it? Maybe it’ll make it big and I’ll strike it rich? Ah, the possibilities. The upwards roller-coaster was in full effect.

The way down is a lot less fun. It sucks. You begin doubting things. You begin to doubt your creativity, your reasoning, your abilities. You start to wonder if all that hard work you put in was worthless. The proverbial cloud is draped all over you for a long time and you begin to do more second-guessing than hacking. 

… And then something good happens. Either some new development arises or you’ve got a great new idea. Either way, you’re back on the roller-coaster.

Looking back on that experience (and the many between then and now), the greatest thing that came out of it was my growth as a person. I learned to appreciate the art of programming - setting me up for a future in computer science and software engineering. I learned to appreciate balancing personal life, with project life, with school life, and what eventually became career life. I learned that the rewards for writing software can be at a personal level - almost spiritual. I learned that the roller-coaster ride is tough. These learnings are constant; they’re everlasting. Good lessons are roller-coaster free.

The reality is, your wildest imaginations about the possibilities for your projects never come true. This is especially true in the current Silicon-Valley start-up climate. Everyone thinks that with a few lines of code, they’re going to be the next Big Thing. Dream on. If you’re thinking you’ve got some secret sauce that will take you to the top in one shot, you are just waiting for that roller-coast drop to bite you in the ass.

Instead, get real. Get realistic. The best way to avoid the fall is to never let your head get in the clouds. Start projects on small ideas with the realization that the most you can ask of it is that you’ll enjoy working on it, that you’ll learn a lot about your craft and your own abilities, and that you have a very good shot creating something great for like-minded individuals. The greatest success will eventually come from a series of small steps. But that takes the realization that sometimes, the greatest success is not financial, but personal as well.

In an oft-quoted blog entry, Chris Wanstrath of GitHub writes:

I didn’t just walk out of high school, pick up a Ruby book, meet Tom and PJ, then launch the site GitHub.  Before GitHub came, in chronological order, Spyc, Ozimodo, my ozmm.org tumblelog, ftpd.rb, Choice, Err the Blog, acts_as_textiled, Cheat!, acts_as_cached, Mofo, Subtlety, cache_fu, Sexy Migrations, Gibberish, nginx_config_generator, fixture scenarios builder, Sake, Ambition, and Facebox.  And that’s just the stuff I released.

In About Us, I described that “we want to do something small, something important, and something really well”. That describes Ronin as a culmination of the ideas I’ve described. Ronin is not a roller-coaster ride. Ronin is a labor of love - not a shot at a billion dollar business. I only ask that it provide me with more learnings, more experiences, and good people to work with. I hope that idea resonates with both the people who enjoy Ronin as a product and the people who read this blog entry with ideas for projects of their own.

Ronin was built with the idea that small firms and independent contractors should have an easy to use and super-affordable invoicing and client management app in one simple service.

Before we started Ronin, we took a look at existing products out there (and there are plenty) for our own freelance use. After reviewing the options, we decided that people deserve an alternative that doesn’t cost more than the monthly cable bill. Even better, for small businesses with a small number of clients, Ronin should be free. We also wanted something that fits our work flow.

To make all of this feasible, we applied the philosophy from Getting Real into the product that we built - everything you need, nothing you don’t. We built in all the features we feel that we needed in our experience doing freelance work, but we’re always open to more ideas and welcome suggestions to improve our application to what suits our users.

We also believe that companies don’t have to aim to be the next Big Thing. Instead we want to do something small, something important, and something really well. By not trying to be everything for everyone, we can be something useful for you. We hope you enjoy our product.