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!

Tweet This Post

After launching BizeeBee I realized that my initial post on what to do after you launch wasn’t enough to cover all the work that the BizeeBee team has done after launching and thought I’d share some of our efforts.  We launched BizeeBee about three weeks ago with a few yoga studios across the nation.  The on-boarding process was pretty smooth, but once we had customers up and running I had an epiphany:  we have paying customers who depend on us for their livelihood, and we are a reflection of their business.  The team’s entire perspective about how we were managing our development process changed!  Here are the key things we added to our process:

1. Backup and Restore

We were responsible for the reliability of our users’ data.  They need this data to understand the health of their business and convey it to their customers.  If something happens we need to be able to retrieve their data and most importantly restore it!  So we started doing backups, initially daily, but will move to hourly.

2. Testing

We could no longer just deploy to production anytime we wanted because our users use our product daily and hourly to run their business.  While continuous deployment is pretty seamless, I was more afraid of introducing a bug during someone’s working hours, so I wanted plenty of time to test and do a hotfix if necessary.  If testing hasn’t been a priority in the alpha or beta, it should become an imperative once you’ve launched.

Even if you don’t have time to setup a full regression suite, you can take a cue from our development process:  we have all our flows documented, and run through all of them manually every night, even if the feature hasn’t been touched in months.  We also test across the three major browsers: Chrome, Safari, and Firefox.  The last thing I want to break is something simple like password recovery or deal with browser interoperability issues.  We’re working on creating an automated suite that will run daily to ensure code quality.

3. Branches

I initially disliked GitHub but now I love it!  It has made branching and merging a breeze because unlike SVN the cost of checking out and switching between branches is very low.  It doesn’t suffer from the same large data footprint that SVN does.  We created 4 categories of branches: master (current development branch), features (one off apps like internal tools), releases, and hotfixes, and also setup a policy of what could be checked into each branch.  For example, once a release branch has been created we can no longer check in new features only bug fixes.  Instituting these kinds of policies minimizes risk of introducing a bug after a release, and people have a good understanding of the ongoing changes in each released version.

4. Track Customer Support Issues

I created an admin tool that lets me login daily to see our user growth count and feature usage.  This also lets myself and my team troubleshoot any issues that customers might be facing.  It has read-only access to their data and the authorization is limited.  If you find yourself constantly querying logs and databases, and have teammates who don’t know SQL or how to query logs then creating a tool that reflects the data empowers them.  And resolving customer support issues as quickly as possible is critical to the quality of your startup!

These are just a few changes we made, but we’ve got even more in the pipeline: more data encryption, site monitoring, and scaling the system based on growth rate.  I’ll post another follow-up once we tackle those shortly.

Tweet This Post

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?

Tweet This Post

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,

Tweet This Post

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.

Tweet This Post

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

Tweet This Post

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)

Tweet This Post

I also like learning and being outside.  So I’ve started a tradition of podcasts and power walks.    I really like listening to: Learning Rails.  The podcast is free and you can subscribe to it on iTunes.  If you visit the site you can also download the screen casts.  If you haven’t yet gone through book exercises I’d recommend looking at the screen casts while listening to the podcasts, it makes it easier to follow and understand what Michael and Christopher are talking about.

I’ll cover video tutorials in the next Ruby Tuesday.

Tweet This Post

1. Women want to code!
2. Entrepreneurs want to understand where they can meet developers and how to interact and motivate them to join their startups (this is gender neutral).
3. There is a growing gap between entrepreneurs and engineers (once again gender neutral).

Because the panel was brief some questions on each of these points went unaddressed.  I’m going to attempt to address some of them now.

1. Just do it!  Seriously, if women in their 20s can run companies, 30s can run marathons, 40s can give birth then they can certainly code!  Any new skill is daunting (believe me I’ve tried snowboarding on blues…)  But the key to learning a new skill is patience, practice, and perseverance.  Start by figuring out what you ultimately want to do e.g. designing websites (CSS, HTML, Illustrator/PhotoShop), creating software programs or web applications (Java, Ruby), or pulling data for business reports (mySQL).  Next evaluate what kind of learner you are: self or group?  If you are good at self-study then go do some tutorials.  Don’t do it all in one shot, pace yourself!  And if you like learning in groups then go attend a workshop or a class.  You can enhance your learning with podcasts on the subject (there are a ton on iTunes), and reading books on the topic.

2. Its no secret developers are a nose-to-the-grindstone bunch.  Good developers are especially hard to meet in the wild  Here are a few secret hide-outs: Hacker Dojo (Mountain View), Meetups (Ruby, Java, iPhone, Android) along the peninsula hosted monthly, and of course un-conferences like CodeCamp, She’s Geeky, and Chirp.

I hate to stereotype but I think there are two key motivating factors: building cool stuff, and solving tough problems.  By building cool stuff I mean developers who like to work in a fast paced environment, like a startup, and be a part of a product’s evolution.  By solving tough problems I mean developers who like to work in a stable environment and think about tough engineering problems like scaling a database or improving the performance of a site to load photos really fast.  Figure out which you want for your company or team.  Then motivate them, first and foremost with projects, and second with the autonomy to build or work on those projects and drive the direction of them.

3. This is mostly a communication issue.  I’ve noticed a growing trend in entrepreneurs understanding jargon, and even what technologies work best for front vs. back-end development.  But I have yet to see a movement in the developer community  to create a more articulate bunch of coders that can clearly explain tradeoffs in laymen’s terms e.g. more servers == more $$ or more code clean up == more developer time.  I think such initiatives needs to start at the university level, perhaps by incorporating a public speaking component to the curriculum.  And in companies managers should force their developers to explain projects and give presentations that are across departments.  I don’t think agile does a good job of emphasizing the need to be articulate, but I think it would help with the entire product development process.

Tweet This Post

Recently I ran into a browser compatibility issue. When I used the following code

<#assign currentDate=myObject.todaysDate?date?string.short>

<td>${currentDate}</td>

The dates would render the current date but in the wrong millenium only in Firefox.

The solution is to instead do the following:

<td>${myObject.runDate?date}</td>

The correct date is printed.  The format is month name, date, and year, and it also contains a timestamp.

Tweet This Post