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 was initially a management major, but my college required one computer science class during our first semester. It was in that class, amidst loops and pointers, that I fell in love with programming. Soon, I switched my major to computer science. Now, I’m about to graduate as a software engineer, and I love what I do. I feel alive when I solve problems and create new things that improve people’s lives. I especially love the endorphin rush I experience once I get a pesky bug fixed!

During my junior year, I went on a software development internship where I was often the only woman, the youngest, or the only Asian in the room. During those six months, I realized that the trailblazers of technology, or at least the ones we know of, were all powered by testosterone.

And it made me wonder — why don’t we have a Martia Zuckerberg or even a Steph Jobs?  I look around me, and I notice that there are simply not enough women running tech companies or founding the next Apple. Actually, there are not enough women on the top, period. In a TED speech, Facebook COO and Harvard Business School alum Sheryl Sandberg commented that only fifteen to sixteen percent of executives in the corporate world are women.  In fact, companies such as Facebook and Zynga do not have a single woman in their boards. Those dismal numbers have to change, and I want to be part of the solution.

That is why I want an MBA. I want to leverage technology and business to change that ratio. I want to equip myself with the skills that I will need to run a tech company with that mission someday. Maybe, I’ll be gutsier and even start one myself.

Some people are brave, though. They found companies right away, but at the young age of twenty, I feel scared that I won’t know anything or that people won’t take me seriously, especially since I do not have an American undergrad degree. Perhaps that’s the imposter syndrome talking, but I do feel that an MBA will better prepare me for the career path that I see for myself. I will get to be intimate with every nook and cranny of a company’s structure, finances, etc., before I have to do it in real life. I guess that’s just my style – I want to have a broader view before I have to make tough business decisions, whether for my own venture or for the next Twitter.

But whether I do go for an MBA or not, one thing is for sure: I will stay in the tech industry because I believe in its capacity to ignite social change. In fact, what I love most about tech is that it is a great “democratizer.”  Imagine, a poor student from the streets of India who does not have the means to hire private tutors can still learn through organizations like the Khan Academy. Students who are not privileged to attend prestigious schools can still have access to the same caliber of information through ventures like MIT Open Courseware and Harvard’s courses in iTunes U.

Growing up as the daughter of an immigrant in a small, Midwestern town, technology is what empowered me to be what I am today. It was the backbone of my education, the very reason I was able to have a job in a top ten software company. I want to use that unique quality of tech, coupled with solid business acumen, to empower the underdogs of the world, the children of underprivileged immigrants, all young women. I want them to be able to look up to strong women like what I aspire to be, and realize that yes, they can code, they can be scientists, they can be CEOs. I want them have the opportunity to be leaders, not just followers. I want to be part of the transformation of our society into an America where women creating tech startups and running big corporations is part of the norm, rather than the exception.

Frances is about to graduate with a degree in Computer Science with specialization in Software Engineering. Previously, she interned for six months for Accenture Software and will be joining them as a Software Engineer in June.  She also contributes to The Levo League, Women 2.0, and STEMinist.  A proud geek girl, she’s sure she is the only one who can’t play video games. Follow her random musings at @FranAdvincula.

In 4 days it will be the 1 year anniversary of launching BizeeBee my second startup. When I started BizeeBee I was determined to put in place engineering principles that I hadn’t been able to at previous companies.  I also wanted to avoid a lot of bad practices that I had experienced throughout my career such as splitting the responsibilities of development and testing, and product bloat.

I know most startups like to take the quick and dirty approach to product development, and then go back and refactor or rebuild their product.  I think that’s great and we’ve certainly refactored a lot of our code base too.  But I started charging customers from day 1 of launching and had to convey confidence to get them to pay.  So I emphasized quality first and foremost.

My vision for BizeeBee’s product and engineering team was to create a simple and high quality product, and to do so cost-effectively.  I communicated these constraints to my team, and we knew there would of course be trade-offs, but we all agreed to these basic principles to guide our decision making and product development process.

Invest time in talent

In any industry employees are not interchangeable.  I know there are a lot of people who like outsourcing and just want something “built”.  This is fine if you are driving a culture of results.  But I truly believe employees need to be engaged in worthwhile work to produce quality.  So I hire for raw talent, hunger, and patience above all else.  I truly believe this is the only way to attract top performers.  You can look at people’s track record, but many don’t have one, so you just have to rest on raw talent and motivation.

Having a talented team is great because it means they will invest time in learning, after all talent is just a byproduct of learning, practice, and refining a skill.

So I invested the time in letting my engineers learn Rails and the entire stack of technologies that went with it.  I also had them talk to experts in the field about engineering process.  We adopted an Agile process and pair program.

Trade-off: giving people time to learn and not spend all their time developing means that less features will be built.  I know most founders would be too impatient with this approach, but I guess that’s why its helpful that I do yoga

Cost Effective Quality

I didn’t have the luxury of having enough money to hire QA engineers, but then again I never liked how engineers would abdicate responsibility for their code to someone else.  Not having a QA team meant that my engineers would need to test their own code.  So for the first time ever I got what I had wanted: TDD (test driven development).

Trade-off: once again less features are built, but what is built has a high level of quality.

Simple Design & Integrating Solutions

Over the course of my engineering career I’ve read a ton of design books, because my personal mission of becoming an engineer was to build things that improve human life.  So I wanted to build products that had an emotional appeal, and people would derive joy and want to use them all the time.  Life is already full of stress, the last thing I want to do is cause someone to have a bad day because I built a shitty product.

We don’t build everything, especially if we can find a good off the shelf solution.  If we don’t find one we’ll either build it ourselves, and if its not cost-effective then we’ll wait until we can afford to build it.  This of course means we’re spending a lot of time doing research, talking to vendors, understanding terms of service, and understanding the long terms implications of the partnership.

Trade-offs: this can stall product development but its important to know who you’re getting hitched to

I can’t speak for other startup founders but as one who wears both the business and technical hat I’ve had the freedom to create a company and engineering culture that I’ve grown to love and can be proud of.  I have to give a LOT of credit to my two developers: Alex Notov and David Grieser who pushed me into implementing a lot of processes and have made me a much better femgineer.  I also want to thank Jesse Taggert for her help with product design, and introducing us to Kevin Fitzpatrick at  Pivotal Labs.  And last but not least Lyndi Thompson our buzz bee who spreads the word about our product and team, and keeps encouraging me to write code and blog posts.

Its been a good year and I look forward to continuing to build BizeeBee in 2012!

Looking back 21 years ago I never would have fathomed I would have become a femgineer or been involved in high tech.  At the age of 8 I had decided I was going to be a lawyer, writer, and professor because I loved to read, write, and speak.  I spent the next 10 years of my life working toward that goal.  In elementary and middle school I wrote short stories, in high school I joined the debate team, and when it was time for college I chose Duke because it has a really great law school.  So where did I get of course and decide to become an engineer, pursuing 2 majors (Electrical Engineering and Computer Science) then decide to move to California, work in the tech industry, then join startup, and then start my own company?  Well the truth is I was NEVER encouraged by anyone to become a lawyer.  In fact, as I’ve pointed out in this blog a number of times most of the men in my family are engineers.  And when I told most people I wanted to be a lawyer people were actually shocked that I didn’t want to be a doctor or engineer despite coming from an Indian immigrant family.

But what led up to me actually switching?  While I was growing up no one told me to be an engineer, my family didn’t even push me towards a particular career they just figured I’d end up in finance, engineering, or medicine.  But there were a couple things that were happening on the sidelines.  First my mom and dad really pushed me to excel at math and science mostly because they wanted me to keep up with the other Indian kids, which I didn’t really care about but it did make me more competitive in other areas like high school debate.  Second, I’ll never forget the day I went to my cousin’s house and saw she had a computer, I really wanted one badly… Why?  Because I wanted to play video games, type up my short stories faster, explore on the internet, and submit pretty book reports to my teacher.  I just wanted a computer to live a full life and accomplish goals I had.  Finally, there was the time that my dad took me to see his fab when he worked for Texas Instruments (my dad  has actually worked for a lot of the big players in high tech: Sony, TI, Intel, Samsung, and Microchip).  I was just blown away when I saw how the little robotic arm picked up each wafer (computer chip) and moved it over.  I just sat there and stared at it for hours.  Despite the curiosity of how things worked, the lifestyle of being an engineer was not glamorous to me.  I grew up watching Ally McBeal…

So what did finally got me into engineering?  Realizing I was a builder.  I realized that all my life what I really enjoyed more than anything was building and creating things that made life more enjoyable.  I always loved technology, I taught myself how to make my first webpage using Geocities in high school, I used to hang out with the nerdy boys who would burn CDs on the weekends, and spent hours on the internet reading, researching, and of course chatting with people who I wasn’t supposed to (a/s/l ring a bell?!).

I was literally sitting in my freshman economics class bored to tears and tired of just reading and writing papers.  I wanted to build something.  I wanted to create.  And that’s what drove me to taking my first computer science class in college.  The rest is history.

How do you encourage engineering?

But enough about me, this is about how we can encourage young women or girls to become femgineers and get interested in high tech.  Well let’s start with what it means to be a femgineer.  I coined the term almost 5 years ago and started this blog.  To me being a femgineer means you are an engineer at the core, you enjoy building things in software or hardware, but you are chic and sophisticated, you have a personality beyond being a nerd.  Maybe you like to travel, speak a few languages, play sports, enjoy cooking, and the list goes on.  Its not enough to tell girls what they should become or what society needs, you need to sell them on the vision of what life will be like, and how you affect the world.  In order to that you need to have role models.

When I was growing up there were hardly any women in engineering that were strong role models.  Until I met my college professor Lisa Huettel.  She was the first female engineer who inspired me.  She was young, energetic, and I loved her method of teaching and the time that she took with each student.  She was one of the driving forces for me switching into engineering in college.

We need more role models and we need to showcase them front and center.  Point out their achievements both as an engineer and in life.  Options are available for those individuals looking to make a difference in their life along with ways to help with the cost of an education. There are even opportunities for single mom scholarships to ease the stress from family while earning a degree.  Its important to take a holistic approach, work isn’t everything.

How do you retain engineers?

When I was graduating from college I noticed a lot of my peers actually didn’t go on to become engineers both men and women.  Even people who were better engineers in college than me! What did they go on to become?  Investment bankers and consultants.  Why?  Because they saw absolutely no value in being an engineer.  What they had experienced through internships were dull days of sitting behind a desk coding, little to no social interaction, and forget the opportunity for travel or making bank.  Being a consultant had a glamorous lifestyle at least on face value.

Then I saw the same thing happen at large companies.  Women who were engineers were leaving to become mothers or pursue other jobs where they could meet with people on a daily basis instead of sitting behind a desk.

Those who were initially interested in engineering are  dropping out.  Its not that they don’t like building or problem solving, they’re unhappy with the their job or the lifestyle.  These people initially bought into the vision of building, problem solving, and creating products that improve people’s lives.  But the reality of it was long hours, lack of appreciation, and unhappiness caused by sitting at a desk coding all day.  Being treated like a cog will not inspire or motivate people.

We can encourage young girls and boys to pursue jobs as engineers all we want.  But if we don’t do a good job of keeping them motivated they will drop out at some point whether its high school, college, or even after the enter the industry.  Part of the reason many engineers join startups is because they get to be part of the product, process, and profits.

When children are growing up explain to them what it means to be an engineer, point out the jobs that are out there in hardware, software, and design.  Show them the value in building and creating.  Want more femgineers or mengineers?  Encouragement them every step of the way, its the only way to inspire and motivate anyone!

My last Ruby Tuesday post was pretty laudatory regarding prototyping in Rails.  In this post I’m switching gears and exposing the pains and limitations with Rails.

The development team at my current startup is composed of engineers and designers, basically I make everyone on the team write code  I understand that Rails’ benefit is in thinking from an MVC mindset.  But because it integrates all components its requires that all developers have some knowledge of a high level language (Java, Ruby), front-end technologies (HTML, CSS), and an understanding of databases.  While it doesn’t require them to have depth of knowledge I think the tight coupling makes it hard to separate the layers.

The following are the three limitations I’ve been experiencing with Rails:

1. Integration – when it comes time to integrate HTML or design changes, designers and front-end engineers need to work in the same space i.e. the same .erb.html file.  Yes I know it doesn’t require a painful and time-consuming compilation process like XMLC or Velocity.  But its easier for the designer to change the look and feel using XMLC or Velocity because they have defined a set of DOM objects.  With Rails designers have to understand views and partials.
2. Convention over configuration – the speed of development with convention over configuration Rails seems to come at the price of normalization, meaning there  is not foreign key construct in Rails.  You as a developer are required to configure this yourself along with other database constructs like unique constraints and indexes.
3. Deprecation – perhaps its just me, and I’m used to Java versions being released every year or two, but it seems like there are a lot of constructs that are deprecated between Rails versions.  The book publishers can barely keep up with the changes.  The other is that some of the constructs that are deprecated which I think are quite large i.e. scaffolding.

Despite these pitfalls I do advocate Rails as a prototyping platform.  The learning curve isn’t steep, and convention over configuration improves the progress developers can make in a day.  I’d also like to learn more about how people have addressed these pitfalls as their prototype matures.  What have been some of your experiences and approaches to dealing with Rails as you transition and build out the product?

I’d been hearing a lot of buzz around jQuery and how much developers like it.  While I myself am not a front-end developer and prefer doing mostly back-end work in Java or Rail, after I saw jQuery in action at SXSWi I wanted to learn to code it in first hand.

One of the reasons I never liked coding in JavaScript is because I didn’t like it being dynamically typed language and having to deal with retrieving DOM elements based on their names and the ability for the namespace to constantly change.  I also found it cumbersome to have to deal with integrating CSS and JavaScript.  jQuery resolves a lot of these issues for me.  jQuery is basically a JavaScript library that lets developers manipulate DOM objects as if they were POJOs, and also manipulate objects based on their CSS classes.  It also has an extensive animation library giving user a richer experience.

For those out there who are new to JavaScript I highly recommend the following sequence of tutorials:

1. Getting Started with jQuery
2. Additional Tutorials
3. Pretty jQuery Interfaces
4. AJAX with jQuery

And of course you need the requisite tools to get up and running so I’d recommend downloading the lates version of FireFox and installing the Firebug plugin to help with debugging any JavaScript issues you might have.

If you want to get further into jQuery check out the main site, which includes a testing framework QUnit,

At the SXSWi conference this past week I attended a lot of great talks on iPhone applications that covered its user experience, development, and how to create apps that emulate the features of a native app but are quicker and easier to create.

User Experience

Josh Clark’s talk on creating apps that are “TapWorthy Applications” was one of the best talks I attended.

The following categories have successful iPhone applications because they focus on what the user wants to accomplish while “on-the-go”:

• microtasking
• capturing lost time
• location based
• entertainment

Each of these categories requires improving the quality of each tap by making it very  useful for users.   To do this you have to think about the basic functionality that users want that is divided into primary and recurring tasks.  Simplifying the design requires focusing on the mobile context, what the user is trying to accomplish when micro-tasking,  creating opportunities for exploring – secret panels and hidden doors to provide additional functionality without cluttering the design, and to think about ergonomics and industrial design so that it is easy to use the application itself.  You will also want to condense the amount of data that is being presented to users, which Josh describes as the “glance test”, i.e. a lot of information can be gleaned by just glancing at the app.  Apps that do this well incorporate large graphics and minimum amounts of data e.g. Weather App.

Finally prototyping on paper is a good way to figure out what it is users actually want and how they interact with the app before spending a lot of time building a code base for it.

Development

Jonathan Stark’s presentation focused on developing browser based mobile applications but still provide a lot of the richness of a native app.  To accomplish this feat he suggests using the following tools and APIs: jQTouch, PhoneGap, CSS3 and HTML5.

jQTouch is a jQuery plug for developing mobile applications that emulate a lot of the functionality that a native iPhone app would have.  The app loads in Safari but has a lot of the same characteristics that a native iPhone app would.  The benefit is that it is a lot faster to develop and does not need to be approved by the App Store.

PhoneGap essentially fills in the gaps of taking a web-based application and transferring it to a mobile platform.

The first time I saw my VP of Engineering use Idea Intellij I feel in love with it!  All those shortcuts, a debugger, running a server, refactoring code, inserting exception handling, and the ability to do auto-complete!  I was coming from an Emacs, NEdit, VI background, which are all powerful in their own right.  I loved Emacs, because I could switch between files quickly and compile in a single window, which is great for C and C++ development.  NEdit is great for hardware languages like Verilog and VHDL where you make a lot of single line edits.  And VI, was my first love, because of all those shortcuts!  But they all paled in comparison to Idea Intellij.  I used Idea for 3 years during the course of my Java development.  And then the unthinkable happened, I upgraded to version 8.0, and it sucked!  My experience was so bad that I reverted to version 7, and refused to upgrade while everyone else on my team upgraded.  I vehemently opposed upgrading for months because of the performance issues I faced.  None of the optimization techniques worked, and I forever remained an Idea 7 fangirl, while the rest of my team upgraded to version 9.  Developers hate waiting for code to compile, so why would they even tolerate an IDE that takes minutes to load or start a server, and brings the rest of your computer to a grinding halt.

It’s been over a month since I’ve done Java development.  I’ve moved onto learning Rails.  While I have been happy with TextMate for the most part, my application is starting to get more complex, and I find myself constantly switching between files.  I’m also really lazy when it comes to typing and love shortcuts and autocomplete functionality.  Hence the quest to search for an IDE has begun again.  Currently, I’m playing with Aptana RadRails.  I decided to install the full application instead of an Eclipse plugin because I wanted to see it in its full glory.  I’m not a huge fan of Eclipse, but I know its probably the best free IDE out there with the most language plugins.  As my application becomes more complex and involves more languages I’ll switch over to Eclipse.  Or maybe just maybe I’ll give Idea 9 a shot…

A happy developer is a productive developer.  Sitting around and waiting for stuff to load or compile is time sunk.  An IDE makes or breaks a developers productivity.  A good IDE handles all development tasks and all stages of development: coding, debugging, refactoring, testing, and running the web app.  An awesome IDE provides the ability to integrate multiple languages like JavaScript, Java, and HTML, which is crucial for a developer like myself who deals with the whole stack (front and back-end).  But the most important factors are speed and ease-of-use.  An IDE should be blazing fast; I don’t want it to suck up memory, take minutes to load, and forever to synchronize changes.  Some nice to haves features are integration with code repositories and doing error checking (e.g. highlight unused references, static code analysis).

But the main reason I like IDEs is because I a like having single tool that slices and dices, and moves me seamlessly through each stage of development.

Quick video on installing RadRails: http://vimeo.com/channels/radrails#6450292

When I was a freshman at Duke, coding away in Teer basement, I would often hear disgruntled engineers shout: “Damn, I’ve got 300 syntax errors, I left off the semicolon!  Why does everything have to be so exact?”  Those were the days of coding in C++, a language in which you had to actually compile, but hey it was faster than punchcards!

Nowadays we have dynamic typed languages like Ruby that don’t even require semicolons!  But that doesn’t mean we’re in the clear.  We still have to debug.  RoR has done a good job of building in a lot of debugging tools.

Here is my philosophy and methodology for debugging:

1. Errors and Exceptions are the easiest: Load the web app, if there is an error or exception thrown in the webpage tackle that first.  If I don’t know what the exception means e.g. InvalidAuthenticityToken, I will look it up.  And read about it and usually that will lead me to a solution.
2. I love logs! If the web app seems to load properly, but some functionality is broken I go look at the logs.  You can add log statements based on the level of logging you want to controllers in RoR with the following code: logger.debug “BUGGY” or logger.info “YO”
3. Data Corruption: to the Database! If the data appears to be displayed incorrectly then I go straight to the database.
4. Look & Feel: if something is off with the way the page is rendered then it is most likely something I did wrong in HTML or CSS.  I like using Firebug for CSS issues.
5. Vijayashanker Code If something is off about the functionality, and I have a sense of where it is happening I will go through and read my code.
6. Debugger Last: I’m not really a lazy person, but setting breakpoints and stepping through code can be tedious.  So I save this as a last resort if I can’t use any of the above techniques to find my bug.
7. I hate “debug” statements! I’m a neat freak, I don’t like polluting my code with debug statement, and creating more work for myself in having to go and remove them later.  If I can’t get the debugger to do what I want then I will resort to using debug statements.

As I was debugging today I discovered a few good resources here are a few of them:

• Debugging Rails Applications (walks you through common debugging techniques and also explains logging levels and configurations)
• Logging Tips (Everything you ever wanted to know relating to logging in RoR)
• RoR Google Group (I found solutions and insights into most of the problems I was experiencing today)