Growth is fun and exciting in a startup, but it can also be just a little painful and scary.

Its scary because people can’t anticipate problems that arise from growth such as having customers, supporting them, answering their requests, and fixing the issues they experience with your product.  Or adding employees, training them, educating them on the vision of the company, keeping them motivated and collaborating with each other.  And then there’s the product itself!  More customers are using it, and generating data which leads to a less than awesome experience for your customers.

This isn’t the time to feel overwhelmed.  Its the time to pat yourself on the back: you found product market fit and you’ve recruited some stellar people to help you out!

Now you’ll need to change some processes to handle the growth which can be the painful part.  Its easy to throw money at the problem, but lets just say you you may or may not have access to a seemingly bottomless pit of cash.

Figure out what you need not what you want.

It all comes back to milestones.  Where do you want to be in 3 months, 6 months, and 1 year?  You don’t need to have definitive growth numbers for your startup but you need to put things in perspective.  Lets say you’re shopping around for a customer support ticketing system, and right now your growth is fairly predictable and manageable by a single human being and possibly part time.  In that case don’t buy something that’s going to cost more than what a single customer is paying you monthly.  You might even be fine  doing support via email and phone, and it will probably aid in your customer development process to have someone listening for feedback.  If your customer support person starts to get inundated then its the time to look into a system to organized.

Start shopping for products when you want to cut down on human labor costs that are quantifiable by time and money.  The people you hire are smart, so invest in their productivity and happiness, and don’t let them become drones by having them do repetitive mundane tasks that aren’t advancing themselves or the company.

Building vs. buying?

You’ve isolated a few areas in which you need to put a new tool in place or replace an old one.  As engineers running a company its easy to say: “Oh I’ll just build it!”  Wrong answer.  Yes it might be super easy for you to whip something up, but who’s going to test that new tool, maintain the code base, and add on to it?  If its you great!  You now have a new department: internal tools.  Oh you’re small… well then you just cut down on product development.

Save yourself some keystrokes and shop around for products instead.  As I mentioned before, if you identified your needs then it becomes easier to tell people what you want and to shop around for it.  Yes there are times when you might not find what you’re looking for, and it might make sense to build it in house if its cost effective (cost == time + money).  If you find a product that satisfies 70-80% of your needs and is within your budget buy it!

When I was working at Mint I had the painful task of searching for an email provider to handle all the outbound emails we were sending.  Integration was a nightmare especially given the products that were in the market at the time.  Had I taken a little more time to do research I would have found MailChimp and been happier.  Live and learn.

Fortunately I did learn, a different lesson while working there, put off managed hosting for as long as possible.  Which is why  when I started BizeeBee I went with Heroku.  Could I have written deploy scripts, and the add-ons that they offer on my own?  Sure, in fact I wrote some of them at Mint (sms and email messaging, performance monitoring, etc) in Java!  But going with a solution like Heroku for less than $100 a month gave me the freedom to build, iterate, and launch BizeeBee all in the same year!  Did I mention $100 is also less than the going rate of a developer pretty much anywhere.

How long will the solution last?

Remember the title of this article is retooling.  If your startup is on a growth trajectory it will outgrow tools, and you’ll need to refine processes.  Get comfortable with it.  They key is to identify when you’ve outgrown a product or anticipate when you will.

Sometimes you can live with a less than perfect solution for awhile, especially if its cheaper than the alternative in terms of setup and maintenance.  Just acknowledge the limitations, and prepare to fix them if they cut into progress.  For example, at BizeeBee we have a customer support tool that I built.  Its not perfect,  it drags the system down a little when we run large queries, but we’re operating with limited resources.  I’ve optimized the queries once they really start to impact application performance, but I haven’t yet setup a dedicated database, and optimized the heck out of it, because I have other priorities.  I’ll throw resources at it when it start to cost us customers and time, or isn’t serving its purpose.

ROI

Retooling is not a cost.  Its a cost if you do it prematurely.  If you do it when you absolutely need to or when you anticipate a need arising then it can actually be aid in the growth of the company.  Once again figure out what you need.  Do you need to grow your user base?  Do you need to keep your customer happy?  Do you need to get paid on time?  Do you need your employees to be happy and productive?  Those should translate to what you’re looking for in a solution.

Retooling isn’t just about finding the right tool, its also about finding the tool that will help you you meet your next milestones, and once you reach them you’ll need to retool again.  Happy retooling!

I’ll be speaking at Deploy hosted by Seattle 2.0 on November 8, 2010.  Building upon a couple of my blog posts (Pre-Launch and Post-Launch) I will be speaking on the engineering execution for a successful Launch.  Here is an outline of the topics I will cover.

1. Stability

• Security: store and retrieve hashed password, encrypt sensitive information, field validation through JS, Ruby, Java, and DB constraints
• Bugs: prioritize mission critical vs. look and feel
• Background Processes: nightly cron jobs, data imports
• Browser Interoperability Issues: IE Hacks, Litmus

2. Scale

• Identify bottlenecks through performance testing: JMeter, New Relic, profilers
• Front-End Optimizations: JS compression, sprite images, measure page load and rendering times
• Back-End Optimizations: index database tables, avoid costly joins, identify “growth tables”, lazy loading and load fewer columns, caching, process data via db instead of loading into business logic
• User Experience: design around slow processes

3. Support

• Logging
• Error Messages and Error Handling
• Debugging Tools: scripts for redundant queries, DB admin

This is a follow-up to my prior post Pre-Launch Prep.  First, pat yourself on the back for making it through the launch!  Now let’s focus on next steps.  The product team’s job is to create and design features that will keep users engaged, and engineering team’s job is to make users happy.  Happiness == (bug free  && accurate data && responsive site).

1. Squash big bugs first!

Grep the logs and count the number of Exceptions or Errors then have it!  Best to create a nightly script to tally up Exceptions and Errors so that you don’t have to type the same grep command everyday.  You also want to check the user forums for discussions on bugs and talk to customer service representatives.  But before you begin doing a big fix make sure that the bug impacts a majority and not a vocal minority.

2. Get down and dirty with data.

Depending your product you might have data accuracy issues.  The easiest first step is to hit the production db and make sure the data that is being pulled in is correct.  If it is then you know there’s an issue farther upstream i.e. business logic or rendering.  If the db is wrong then you’ve got an issue with storing data, which could be caused by a broken link somewhere in the front to back-end flow.

3. Prioritize performance.

Everyone is always touting the vices of premature performance optimizations, which is a valid point, especially in a startup where you are resource and time constrained. You don’t need to optimize from the start, but you do want to build infrastructure to measure your site’s performance.  Performance is both a front and back-end issue.

• Front-End: your page load time is abominable because you’ve got lots of graphics that haven’t been sprited, have browser interoperability issues, or network latency sucks because your user bought the cheapest DSL package…
• Back-End: sure you’re using ajax on the front-end, but if each request is hitting the db and you’re pulling in thousands of records no point in being asynchronous…

Figure out where your bottlenecks are, and then tune it up!

I’ve been advising a few pre-launch startups that are getting ready to do their first ever product launch.  From first-hand experience I know that the first product launch can be nerve-wrecking.  You expect the product to be pixel perfect, and all the features to be fully functional and bug-free.  But there is such a thing as spending too much time on perfecting the product, and forgetting that you need to be able to support load on the system.  What good is a shiny product that people can’t even sign up for because a server has gone down, or their signup process takes on the order of minutes or hours!

Here are a few tips I’ve been giving people to help alleviate their pre-launch preoccupations:

1. Logging.  For good developers this should be a no-brainer, because they would havetested or debugged their code and would have included logging to do so.  For Java I use log4J, Ruby has its own class Logger.  You also want to make sure you are rotating the logs daily.
2. Keep an eye on Exception and Errors. Once you’ve got your logging in place create a simple shell script to grep the logs and tally up errors and exceptions.  You can set this up in cron to delivery the logs to your email every hour or day.
3. Fix Showstoppers. These are bugs that prevent a user from signing up, or are glaringly obvious and create a negative and lasting impression on new users.
4. Monitor Your Servers. Tools like Nagios or Ganglia.
5. Monitor the drop off points. There are typically three: coming to the site, sign-up, and then performing the first action (depending on your product’s features).  To do this you will need Google Analytics.
6. Load Test. Test the limits of your system so that you know how much load it can handle.  JMeter is a good tool to use to do this.
7. Load Balancer. If you are responsible for your servers then I’d highly recommend doing this.  Check out this intro lesson on load balancing.

Hold off on all new feature requests!  First impressions count for a lot, and whats more important than being feature rich is being able to have a site up and running.  What good are more features if users can’t even get through your front door!  Focus on supporting the new and incoming users and giving them a worthwhile and timely experience.  Stay tuned for a follow-up on what to do the morning after…

Every year I make the usual new year’s  resolutions to be healthier, friendlier, calmer, cheaper, smarter, and so forth.  But, I don’t actually set goals for how I want to become a better developer!  So I decided that I’d put together a list of skills I want to have, and goals I want to accomplish by the end of 2010.

I’m also going to post the best tutorials and troubleshooting tactics I come across while meeting my goals.

1. Learn Ruby on Rails

2. Learn Objective-C and Create an iPhone app

3. Learn Adobe Air

4. Read 3 books on software architecture

5. Attend at least 1 developer conference

I have posted the presentation I gave today at Code Camp here.  Hope you enjoyed it, and please feel free to email me feedback!

When I first started coding I believed it was good enough to get stuff working, and then move on to solving the next problem.  I’d spend a little time designing, but most of my time implementing and testing.  My primary concerns were correctness followed by efficiency.  I didn’t see the point in re-factoring code until it was time to add new functionality or modules became incompatible or worse incomprehensible!  However, once I started to work in a team that was growing linearly I realized that readability is very important for code maintainability because:

1.  Other people read your code either because they are learning the code base and need to extend it or because they are trying to figure out how their functionality can fit with yours.  If it isn’t immediately obvious what problem the code is trying to solve then they are going to turn to you for help, and if you are around to explain it to them, great.   But even then you might have forgotten when you wrote, which then causes them  to add new functionality that most likely duplicates your existing solution.  Now there are two pieces of code that solve the same problem, and need to be maintained!

2. Other people mimic your code.  Before adding new functionality most people read through existing code to see if it solves a similar problem.  Instinctually they will copy the pattern, or skeleton of the solution if it applies.  Now you have more unreadable code!

So what constitutes as unreadable code? 

1. Function names that are ambiguous or functions that perform multiple actions that aren’t reflected in the function name.

public void createBudget(User user, String name, Double amount) {

    if (user.getBudget(name) != null) {

       user.getBudget(name).setAmount(amount);

    }

    else {

        Budget budget = new Budget();

        budget.setName(name);

        budget.setAmount(amount);        

        user.addBudget(new Budget(name));    }  

    totalSpending(user.getBudget(name));

}

This function is doing more than just creating a budget.  It is checking to see if one exists first for the given name, if not then it creates one.  If it does exist it updates the amount.  Instead of forcing developers to read through the entire function to figure this out a better name would be: createOrUpdateBudget (assuming that eventually more than the amount will change).  The same principle exists for variable names as well.  In today’s world of coding using and IDE with the auto-complete function saves typing, so long and descriptive variable names are preferable to ambiguous ones like “String s” or “String temp”.

The call to totalSpending makes no sense in this function.  If the point is to total up spending for a budgeted category then it should be done outside of the function meant to create a budget.  Limiting functionality reduces the levels of redirection a developer has to read through and understand, and makes it easier for them to understand what is going on.  Otherwise they have to remember multiple interactions, and juggle them when adding new code.

2.  Lumping together function calls.

Looking at the previous example there are multiple function calls lumped together e.g. “user.getBudget(name).setAmount(amount);”.  This is done out of convenience, and while in this case the functions are small, and perform simple actions, it becomes much harder to read if the function names are longer and more descriptive.  Its best to go through the additional typing, and break them into two separate lines.

e.g. Budget budget = user.getBudget(name);

        budget.setAmount(amount);

3. Using private or inner classes.  

If a class cannot be reused then it might make sense to create it as an inner or private class.  However, the tradeoff is that it becomes harder to search for the class name in IDEs.  If you plan to reuse the class because it a basic structure that can be reused then it should be promoted to being a public class.

4. Overbearing parent classes.  

Naming is very important to describing the concept that a class is trying to convey. Highly general names should be reserved for parent classes e.g. “Account”.  But as you add to the class hierarchy the subclass names should be very specific e.g. “BankAccount” or “CreditAccount”.  This also gives developers an intuition of what each class might have as data members.  For example, the Account class might have general variable such as “String name”.  Whereas its subclasses will contains members that convey the concept of that class e.g. CreditAccount has a variable “Double interestRate” or BankAccount has a variable “Double atmFee”.  It also becomes easier to add data members to each of these classes because the classes are divided, and prevents developers from polluting the parent class with too data members that don’t pertain to multiple classes.

5. Function length

Length does matter!   Going back to point #1, you should strive to cut down on function length by removing calls to functions that are extraneous, or re-factoring sections into simple single level functions that can be called and re-used.

For my summer software reading I choose Secrets of the Rockstar Programmers by Ed Burns (yes I know the title is a bit cheesy…).  The book contains interviews with several male programmers, who have been in industry for at least 10 years, and have made significant contributions to in pure software such as creating a framework like Spring, or working on .NET architecture.

I thoroughly enjoyed the book, and the format makes it easy to digest.  However, it took me a while to get through, because I wanted to mentally process each programmer’s hard and soft skills, and lifestyle.  I thought it was an accurate depiction of what I believed the life of a programmer to be, and what it took to be stellar in the field of software.

There are a few common themes amongst these rock stars.  The vast majority of them have trouble with work life balance, the exception being British programmers, such as Adrian Colyer, CTO of SpringSource, who spends weekend with his family.  But for the rest, life is about solving problems and thinking about problems all the time.  The younger programmers, especially, have trouble balancing a family life, and attest to the fact the have to be told spend time with family or have learned to make time.  As far as hard skills go, Burns spent most of his time asking how these programmers keep up with technology trends, which blogs they read, and how to spot the latest language fads.  When it comes to soft skills, a few believe it is important to have a business sense if you want to advance, but there are a few in the minority, who would rather focus their efforts on development and technology.

I also enjoyed the historical perspective of the book.  Burns interviews programmers who pretty much started out with punch-cards, to those who have never had to manage memory.  Having been an electrical engineer, it is very interesting to see how hardware technology improved the overall productivity of programmers, and from the software side it peaked my curiosity of what’s to come in areas such as cloud computing and thinking about the computer as a network rather than an individual self-contained processing unit.

After finishing the book I started thinking of issues that I felt the book did not handle, the most obvious being there were no female programmers interviewed!  While I don’t believe it necessarily detracts from the essence of the book and what it takes to be a rockstar programmer, I think it highlights one of the fundamental problems that exists in the software industry: lack of female role models.  Those who did exist such as Grace Hopper, have yet to be  replaced by a new generation.  And I don’t think it is because software is particularly difficult, there are plenty of women surgeons and lawyers.

Leaving aside the gender bias, I also thought the book was too biased in interviewing programmers who worked for purely software based companies like Microsoft, SpringSource, and Sun.  While I think programmers at these companies are highly capable individuals, IMHO, they do not have the same resource constraints (both programmers and technology), and consumer driven issues such as security and high availability that programmers at places like Amazon.com, Facebook, and Mint.com face.  It has hardly, if any programmers like myself, who work for consumer web services, and are constantly fighting to solve scalability, security, and performance issues.  I would have liked to have learned about how people handle thinking about such issues given the fact that the age of the Internet is causing more software engineers to go into web services.

Overall, I would highly recommend reading Burns’ book, especially for those who are a few years out of college like myself, who are wondering what the next steps are in their career, and interested in learning from those who have paved the way.