A Process is a well defined set of actionable steps (including best practices) explicitly designed to improve the efficiency of the organization. No more. No less. And to ensure that, your first step is to make sure you have the right tools. From a product development perspective, the obvious and critical process tools for are:

• Configuration Management: Source Control System providing the ability to manage versions/revisions of source code. This enables tracking of code-changes, rollbacks, managing branches, releases etc.
• Quality Assurance: Bug Tracking System that helps track software bugs generated through quality assurance tests.
• Project Management: Task/Resource tracking and planning system that helps in the planning of tasks, tracking deliverable and optimizing task allocations.

Choices for the tools are pretty standard; the selection drivers are for the tool to perform it’s intended function well, not hinder development, and be cost effective. For version control, the choice is generally Subversion since it addresses many of CVS’s drawbacks, is extremely easy to use, and in TortoiseSVN there exists a great client tool for the commandline-averse. For bug tracking, there’s Bugzilla, and for project management, it generally comes down to Trac and/or Basecamp (from 37Signals). While there are other more comprehensive tools out there, you can get almost everything done with these, and they are FREE! And that’s a magic word for any startup!

Process is wonderful because it provides a definition of how things get done. The team is generally more efficient, new hires have a means to understanding the method to the madness, and when the day comes where you’re successful enough that ISO compliance matters, you already have a leg up generating that audit trail! But, as someone with experience working for a  30,000 person strong telecommunications giant, 100 person growth mode company, and a 5 person garage stealth venture, take it from me that one shoe does NOT fit all. You should (read have to) tailor your processes for the environment you’re in if you don’t want it to be a mill-stone around your neck.

As an example: A lot of entrepreneurs, especially those with a big company background, want to do things in-house as they start off. A friend of mine who started his company some years back had some pain to share – Of course he didn’t have the budget for an IT staff, so he used his developers for the initial setup of these tools. It took about 3 weeks to set things up, and it was time to get to product development!

Points Of Pain:
For the first couple of months, this worked well for them. They’d setup VPN connectivity primarily to enable their remote developers. To access any of these tools, they’d diligently vpn in, check their bug-list, access the code, and work till the wee hours of the morning. But as they started to grow their development team, issues started to crop up. Pretty soon, what started as an irritating itch turned to a full blown hemorrhage. And here’s why:

• With new versions of Subversion or Bugzilla that were released, patches needed to be applied. In addition, for every new hire, configuration files needed to be edited, access control scripts needed to be modified, and access issues resolved. For all these tasks, precious premium development cycles were wasted.
• Many of their developers were Linux users, and the windows based VPN setup was a bane of their existence. Not a day went by when they didn’t have VPN connectivity issues, and developers could not access code, sometimes for hours.
• With their VPN setup and no dedicated IT function, security was always a concern. Was the network safe enough? Was it configured right?
• For a distributed team, notifications were critical, when bugs were fixed for the Q/A team, and when reopened for the development team, as well as management to keep track of progress. In addition, emails related to checkin-diffs are extremely useful in getting a sense of what’s fixed, and cursory code review. Integrating your email system into this setup and making it work right isn’t particularly easy.

The world is indeed flat. As your engineering organization grows and gains a certain maturity, there will come the time when your engineers will be dispersed, located around the world. Not being able to access code or checkin new versions, or receive notifications reliably can seriously destabilize your development momentum. The last thing you want when starting off is to have your development team stymied by the very processes you’ve setup to assist them.

What should you do?
Process is definitely required. The question to ask yourself is whether you want the tools that enable it to reside in-house. In today’s distributed team environment, I question whether that’s good wisdom, because there are some great alternatives. Companies have been established to essentially solve the problems of the nature described above, faced by every startup. They provide you with most process tools, and due to economies of scale, their fee structure is remarkably competitive. For example we used CVSDUDE.com, dedicated to providing Bugzilla, Subversion and Trac for your projects. They have some easy to use administrative tools that make configuration changes a breeze, but most importantly, they have a very responsive customer service team. In addition, you have complete control over different branches, how you want to expose them, teams you want to expose them to, etc.

My recommendation is to give serious thought to outsourcing your development processes if you can. There are many choices out there. It can truly liberate your development team and allows you to focus on what’s important – developing an outstanding product!

I am often asked when we decided to go ‘live’ with our product and what the factors were that prompted our decision to get out of stealth mode.

Now, from a business perspective, this really depends on what your product is trying to accomplish – If you have an idea so unique, different yet valuable that no one has (as yet) thought of capitalizing on through the Internet, it’s a no-brainer; you should try and go live as soon as possible. Never underestimate the value of the First Mover Advantage.

But most times, you’ll find there’s already something similar out there, and your competitiveness will very likely involve differentiation with existing solutions – maybe you have that killer function that will get users to abandon the competition in droves to adopt your solution, or your application is so well designed as to make an existing very convoluted process as simple as 1-2-3. It’s in situations like these that you may get stressed by the thought that going live early will allow the competition to ’steal’ your idea, and you might be tempted/forced to delay it until you’ve got the base functionality your competition already has, and then adding the differentiation factor that makes it better.

I’ll say this: It’s never too early. There are the obvious reasons, namely:

1. Getting your product out early allows you to identify and address process issues (such as deployment) early on, and fine tune it before the stakes get too high.
2. The sooner you get it out there, the quicker your user base will start to build. Ultimately, in the on-line world, success is driven by the users who adopt your product. And unless you have a revolutionary product capable of spreading virally, user adoption takes time especially when you don’t have those marketing dollars or a CEO with an established ‘Old Boy’ network to fall back on (which you likely won’t when you’re just starting off)
3. Yes, you’ve researched and identified an opportunity. A big one. Which is why you’ve ventured to start your own company. And you’re confident the product you’re putting out there is exactly what your customers need. But how can you be sure that the time and effort invested in developing this product will have the adoption rate you expect and that it indeed services a customer need? How can you know? Well, you can’t. And so the best way is to ask for feedback from the users you’re targeting by getting something out there as quickly as possible so you can collect and react to this feedback.
4. Having a product in use and available to play with is the best way you can convince potential VCs and angel investors that this is a serious endeavour and that your team can execute quickly, and execute well.
5. Having a product on-line allows you to evangelize easier.

These are the tangibles. Then, there are the intangibles that are equally important, such as:

1. The collective sense of achievement that the team’s putting products out there that are actually being used.
2. The collective pride when you get your 1000th user signed up, and looking forward to the day when your 100,000th will.

We were aware of these, so in our very first ‘founding team’ meeting, we decided our strategy would be to get something out in 2 months, come hell or high water. And once we signed up for it, every decision we made, every step we took, every task we defined was designed to help us achieve that goal. We applied the 80-20 rule indiscriminately to almost every blocking issue in pursuit of this goal.

1 year down the line, we’ve had 6 major releases, 4 diverse on-line products, our user base continues to grow, and every improvement is driven through the feedback by customers who are actually using our product. So we did indeed see the benefits we’d expected from going live early. But we saw another benefit, the most intangible of them all, yet in my opinion the most important – we saw a team executing with clinical efficiency, focused and driven to meet the next milestone. And I would attribute it to this one decision we made for the reasons below.

Bad habits die hard, but so do good habits. Our team’s ability to execute didn’t happen overnight – it always takes time to get everyone on a team aligned, and we had our teething problems. But 9 iterations on, and everyone has imbibed this focused lean-n-mean approach to almost every issue we tackle, and I strongly believe that the decision to get out of stealth as soon as possible was probably the single most important factor in getting our team aligned to this agile philosophy. It forced us to make the tough process and engineering decisions much sooner than we would normally have, and that continues to shape our team values, our attitudes and our focus that we apply on a day-to-day basis one year on.

You’d be surprised how even the simplest of decisions you make during the early days can affect the team, the project, and ultimately the fate of the company – I’ve seen companies that chose a different approach and started off with a plan to deliver an architecturally brilliant pluggable scalable framework in the first 3 months and then build on that platform in an agile fashion. I believe by focusing on breadth and starting slow, they’ve already started off at a disadvantage - while some still succeed, most struggle to gain momentum which is critical during the early days.

So there you have it. Now that you’ve read this post, it has hopefully given you the necessary impetus to push, and push hard to go ‘public’ with your application. You’ve got a great idea and the right resources. But how you start off the block is critical to how your team will execute in the coming months and years.

In my previous post, I’d highlighted the issues we faced when we’d first set out to prioritize our gargantuan set of requirements, and introduced you to “Pareto’s Principle”, also referred to as the 80-20 rule. So How did the 80-20 rule help us? How did we use it to guide us through all those competing requirements?

As I’d mentioned then, Pareto’s principle inherently addresses efficiency and the Return on Investment (ROI), and is applicable in almost all business and software engineering processes. Apply it judiciously, and you’d be surprised how well it can work to bring clarity and focus to a time-bound problem set.

Which we duly did. In our case, our customer base was homogeneous and of equal distribution (our payment model expected same payments for all customers, at least when we started off, so there wasn’t really a concept of a ‘high value’ or ‘low-value’ customer). The 20% customer-80% revenue rule thus wasn’t applicable in this context. So we asked ourselves other types of questions to help prioritize -

• What were the 20% features that would be used 80% of the time?
• What were the 20% features that 80% of our customer base really cares about?

And we chose requirements that satisfied these questions. It helped us whittle down our initial set of requirements to a manageable set. Now, if you’re really lucky your new subset will be doable in the time-lines you’ve set, and you don’t need to prioritize further. But sometimes, it’s just not possible. So you could:

1. Re-prioritize the whittled down set by re-applying the above 80-20 rule to reduce the functional set further OR
2. Understand what the technical factors are that bloat the time-lines, and tackle it by applying a different 80-20 rule, this time on the engineering front. 80% of engineering effort goes in 20% of the features. So drop these 20% features, and you’ve just saved 80% of the engineering effort.

Ultimately, you have to decide what works best for you. We went with applying feature-use trade-off once on the domain front, followed by a effort-feature trade-off on the technical front to define a feature set for each iteration. It worked well for us.

I agree this all sounds a bit complicated, but really, it’s not that difficult once you start executing on it. You don’t have to be exact, it’s just a process that if you follow diligently, you know you’ll always be delivering maximum benefit to your end customer with the limited resources and time you’ll always have.

We’ve learned to apply this 80-20 rule to all aspects of our decision making when we are faced with competing priorities. Not only has it helped us close on competing issues quickly, but has also contributed to the overall efficiency of our team.
~~
Some additional notes:

A] All of what I have mentioned above is common-sense and there’s nothing new in what I am advocating. The reason I thought to share this experience was because:

1. Knowing something and applying it are two entirely different things. Sometimes, these things just lie dormant somewhere in the sub-conscious, and an external stimulus is required to get us to ‘wake-up’ and start applying it. Hopefully this reading does that for you.
2. It was instrumental in helping me (and the team) execute with clarity and focus. If we hadn’t ruthlessly applied this in our day to day activities, I doubt we would have made the progress we have.

B] I often wonder why it was difficult for me to prioritize during those early days when I’d been doing it with ease (and success) in my day job – I think it may have been due to the fact that as part of the founding team, my emotional investment in it was far greater than in any other past project I may have worked on, and this made it harder to be impartial. And maybe that’s why 80-20 works so well – it take the emotion out of the equation!

C] Interpretation of the 80-20 is key to successfully applying it. There’s this joke about a software engineer who was really sloppy in his coding. On confronting him as to why there were always loose ends in his code, he replied “I was just following the 80-20 rule”! Be judicious and be thoughtful in how you apply it, and 80-20 will work wonders for you.

One of the early challenges we faced was trying to define the scope of V1 of our product – the first set of on-line services we would make available to our target base.

A startup is conceived as a result of the founders identifying a set of significant pain-points in a particular domain validated through market research. Since requirements originate from these, all requirements initially assume equal significance, and it’s tempting to start to build a system that does it all from the get-go. Of course, the reality is you have a very finite and limited set of development resources, and you improve your chances of success by biting no more than you can chew.

When we got off the blocks, it was no different – we had a vast set of requirements, and we knew we had to prioritize if we wanted V1 out in 2 months. We were thoroughbred professionals with experience in executive management, software development and systems engineering working for fortune 500 companies. We prioritized on issues to maximize effectiveness every day; and we were good at it. How hard could it be?

Hard enough! As we started defining our application requirements, we were overwhelmed by the competing requirements; it almost seemed like we had to sacrifice a leg to keep an arm; chop off the kidneys to keep the liver; at the end of our first requirements meeting, it almost  felt like for our product to be valuable to our customers, there was nothing we could drop out of V1. And we were just discussing the domain requirements – we’d not even got to the technical and non-functional requirements yet.

In these situations, there’s one thing to do, and that’s to look to Pareto for guidance! And so we did.

“The Pareto principle (also known as the 80-20 rule) states that, for many events, 80% of the effects comes from 20% of the causes. The original observation was in connection with income and wealth. Italian economist Vilfredo Pareto noticed that 80% of Italy’s wealth was owned by 20% of the population. He then carried out surveys on a variety of other countries and found to his surprise that a similar distribution applied.” — Wikipedia

Dr. Joseph Duran, another management specialist observed that such similar distribution patterns existed in many environments (such as business, software engineering, project planning, etc.) that require the application of an ‘input’ (investment of time, labor, effort) to generate some ‘output’ (quantity, quality, revenue, etc). Recognizing the universality, he coined the term “vital few and the trivial many”, and also labeled this observation the “Pareto Principle”.

There are many good articles on the web that explain the Pareto Principle, it’s application and it’s value, so I won’t delve into it much further, except to highlight some real-world examples that validate this principle, namely:

20% of bugs cause 80% of crashes
20% of the workers produce 80% of the results
20% of products generate 80% of revenues
20% of the inventory occupies 80% of the warehouse
20% of time can be used to address 80% of daily chores
20% of customers generate 80% of the revenues
20% of tests can detect 80% of system failures
etc., etc.

Pareto’s principle inherently addresses efficiency and the Return on Investment (ROI), and is applicable in almost all business and software engineering processes. Apply it judiciously, and you’d be surprised how well it can work to bring clarity and focus to a time-bound problem set.

Coming up…. In my next post, I’ll explain how we  applied the 80-20 rule it to solve our requirements and iteration planning… Stay tuned!

Earlier, I had shared my notes on setting up a development environment (Rails, Java and tools) on Ubuntu Linux. There’s another aspect to my setup that I think would be useful to share, which is how I have currently built my clustered server (test) environment. 

My Development Environment: 

My development machine is an HP Pavilion dv9000 Windows Vista Notebook. It’s a pretty powerful machine, so I’ve also installed VMWare Workstation on it and defined  3 VMWare slices each with Ubuntu 7.04. One slice is my dedicated Rails development environment, while the other 2 represent my ‘mongrel cluster’. Each slice has the Ruby and Rails eco-system, the LAMP stack (Linux, Apache, MySQL, Php), PhpMyAdmin MySQL client and some additional graphical tools, Eclipse, Java, Subversion, Mozilla Thunderbird, FTP Service.

Machine details:

• Windows Vista Home Premium
• HP Pavilion dv9000
• CPU: Intel Centrino Core 2 Duo (T5600 @1.83 GHz)
• RAM: 2046 MB
• Graphics Card: nvidia GeForce 7600

Why VMWare:

I’ve used VMWare extensively in the past, especially their ESX Servers. It’s an amazing platform, and VMWare (the company) has done a great job with their virtualization software portfolio. With hardware getting more powerful by the day, it just makes sense to use Virtualization software to improve it’s usage efficiency and ROI.

I had the option of dual-booting my 1.83GHz/2Gb Vista machine, but I opted for a VMWare setup instead. The advantages of using VMWare to host Operating Systems are many fold:

1. Firstly, you can easily switch between your host OS (in my case Vista), and a particular VMWare slice. I use Microsoft Outlook 2007 for my emails, calendar and meetings. I depend on it, and enjoy the application enough to not want to move to something else. Using a VMWare slice for Ubuntu allows me to switch from my development environment to my business environment as easily as (Ctrl+Alt), with (Alt+Tab).
2. You can host multiple slices running in parallel. So I could not only configure a development Ubuntu setup, but have two additional slices with a mongrel cluster setup so I have a full fledged deployment topology, all on my Vista box.
3. I found it very easy to install the Ubuntu OS on a VMWare slice. Pop the CD in, and VMWare recognizes all the necessary ports, networks and drives, and the Guest OS can configure itself appropriately by detecting the necessary hardware. when I installed Ubuntu on my first VM slice, I wasn’t sure how easy it would be to configure Ubuntu so it would work with my wireless setup. It was a breeze – I had to do absolutely NOTHING.
4. You can clone or take snapshots of an existing setup and use that as the base for deploying new VMWare slices. Your new image will be a replica of the one that you cloned or snapshot’ed. You don’t have to go through the process of installing everything from scratch.  I setup my development environment on ‘Ubuntu Rails 1′, cloned it and created ‘Ubuntu Cluster 1′, setup the mongrel cluster and some server specific programs, then cloned that to create ‘Ubuntu cluster 2′. All through some simple clicks.
5. Taking snapshots allows you to backup your image, so if you mess up, you can always revert to the last snapshot/checkpoint.
6. Finally, I have everything on 1 machine. Where-ever I go, my vista programs, Rails development environment as well as my deployment environment go with me!

This is a convenient alternative to having multiple hardware boxes dedicated to your cluster. Of course, i don’t recommend this for serious performance measurement and load testing and it’s definitely not a replacement for your ‘pre-production’ test environment, but it’s been pretty helpful for me when trying to run some light load tests during initial analysis of performance bottlenecks.

So give it a try… I’m sure you’ll enjoy your new ‘testlab-in-a-box’.

If you are planning on installing Ubuntu and setting it up for development but don’t know where to look, you’re in luck. Sometime back, I went through the trouble of installing a fresh Ubuntu7.0.4 (Fiesty Fawn)  in a VMWare slice and setting it up for some Rails development. I’d never worked with Ubuntu before, so I googled for help. And as always, I found a ton of crap mixed with a few nuggets of gold.

Good luck finding all the information you want in one document! I spent a whole weekend trying to mine the right information on the development stack and tools I needed. There are some good tutorials out there, but each deals with a specific task and you have to go through a fair set of links before you find the one for a particular topic that makes sense. 

Took a bit of time, but eventually I got the environment I wanted and I was ready to rumble. I was keen on writing an uber-tutorial with all that I had learned to share on my blog, but that would have required some serious effort and time commitments at my end. Effort, no problem, but time, hmm… with 2 jobs, a blog and a baby on the way, that’s a luxury I just didn’t have. The next best option was to share the notes I had jotted down as I went through this process. So here it is – a collection of the steps I took during the install process (in sequence) with links to the articles on-line that I found very useful.

The task:

To set up a development environment (run-time and related tools) for developing Ruby On Rails and Java applications on a Ubuntu Linux Operating System.

Why Ubuntu:

Most in the Rails community either develop on Linux or Mac. I’ve almost never come across anybody who deploys Rails on a Windows setup in a production environment. By choosing Ruby On Rails as our technology stack, it was clear I’d need to start working with a Linux based development environment.

There are many different operating systems based on GNU/Linux: Debian, SuSE, Gentoo, RedHat, etc. Of the distros I researched, Debian seemed to be the flavor of choice for the relative newcomers to the Linux world. Debian has a powerful application packaging tool (named apt-get) that allows you to easily (and painlessly) install software, which has been Debian’s major claim to fame. Ubuntu is an offspring from the Debian distro that’s had a meteoric rise in the open source community primarily because of it’s Debian lineage, but more importantly because they make it super easy to install and use (they’ll even mail you a CD free of cost if you don’t want to download an ISO image and burn one for yourself). And because it’s based on Debian, it inherently supports the apt-get packaging tool. It also has a well defined 6 month release cycle, so it’s a stable and well-maintained platform.

Easy to install, easy to use, and the community was raving about it. I decided to jump on to the Ubuntu bandwagon as well!

Steps: 

Installing Ubuntu7 (Fiesty Fawn)

1. Download and create the CD
2. Install via the CD.

References:  http://www.ubuntu.com/getubuntu

Installing the Lamp Stack

1) Download and install packages using apt-get
$> sudo apt-get install apache2 php5-mysql libapache2-mod-php5 mysql-server
2) Check Status of PHP – Edit file phpinfo.php in Apache web-root and test
$> sudo vim /var/www/phpinfo.php
3) Navigate to http://localhost/phpinfo.php- ensure php info is available.
 

References:
http://www.ossgeeks.co.uk/?p=15
http://www.ctunion.com/node/22

Installing PhpMyAdmin

1) Download and install phpMyAdmin mysql webclient. This is also available through apt-get
$> sudo apt-get install phpmyadmin
2) Ensure phpmyadmin can work with the mysql database. Navigate to /var/www/phpmyadmin/config and edit config.inc.php
$> sudo gedit /var/www/phpmyadmin/config/config.inc.php
Change
$cfg['Servers'][$i]['auth_type'] = ‘cookie’;
To
$cfg['Servers'][$i]['auth_type'] = ‘config’;
Add
$cfg['Servers'][$i]['username'] = ‘<sql uname>’;
$cfg['Servers'][$i]['password'] = ‘<password>’;
3) Navigate to phpmyadmin webclient and test: http://localhost/phpmyadmin

IP information if you don’t want localhost

$> ifconfig

Installing Java

1) Install the package java-package, from contrib:
$> apt-get install java-package
2) Download the Sun JDK installer for Linux, from http://java.sun.com/j2se/. Had to download 1.5 because the following steps did not work for Java6 (sept 8, 07)
3) Create the Debian package. Be sure you are not root:
$> fakeroot make-jpkg jdk-1_5_0_12-linux-i586.bin
(change to the name of your downloaded archive)
4) Install the Debian package. Become root and run this:
$> dpkg -i sun-j2sdk1.5-1_5_12+update01.deb
 

References:
http://wiki.serios.net/wiki/Debian_Java_JRE/JDK_installation_with_java-package
http://www.cosy.sbg.ac.at/~amayer/files/How-to-install-Java-on-Debian.html

Installing eclipse

1) Download the eclipse ‘classic’ (or any other) package from http://www.eclipse.org/downloads/
2) Copy eclipse-SDK-3.3-linux-gtk.tar.gz to /usr/bin (folder where you’ll extract eclipse)
$> su
$> cp eclipse-SDK-3.3-linux-gtk.tar.gz /usr/bin
3) Extract the tar – an eclipse directory will be created
$> cd /usr/bin
$> tar -xzvf eclipse-SDK-3.3-linux-gtk.tar.gz
$> exit
4) Launch eclipse
$> /usr/bin/eclipse/eclipse &
5)) Install RDT For Eclipse & Installing RadRails For Eclipse: Follow http://www.oreillynet.com/pub/a/ruby/2007/04/26/ruby-on-rails-meets-eclipse.html

References:
http://www.fluggart.com/linux/general/eclipse.html

http://www.oreillynet.com/pub/a/ruby/2007/04/26/ruby-on-rails-meets-eclipse.html

Installing Subversion

1) Download and install subversion
$> sudo apt-get install subversion
2) Checkout the rails project from your repository

$> svn co svn:<your repository>

Installing KDE – Not Successful

$> sudo aptitude update && sudo aptitude install kubuntu-desktop

References: (also explains removing, switching to Gnome, etc)
http://www.psychocats.net/ubuntu/kde

Installing Ruby On Rails

1) Download and install ruby, gems and dependencies
$> sudo apt-get install ruby rubygems irb ri rdoc ruby1.8-dev build-essential
2) Next, install rails through gems
$> $ sudo gem install rails –include-dependencies
3) There are a few more steps. See reference.
3.5) Install sql driver for ruby
$> sudo apt-get install libmysql-ruby
4) Install dependent gems (see reference for rmagick)

References:
http://wiki.rubyonrails.org/rails/pages/RailsOnUbuntu

Installing Mozilla Thunderbird

$> sudo aptitude install mozilla-thunderbird
2) If you want to open the application go to Applications -> Internet -> Thunderbird Mail Client
3) Finally, configure the client with your POP3 and SMTP server settings

Installing FTP Service

1) Download and install
$> sudo apt-get install proftpd
2) During install, set option to standalone (if you don’t have inetd function)
3) To Restart
$> sudo /etc/init.d/proftpd restart

References:
Setting up ftp service: http://ubuntuguide.org/wiki/Ubuntu:Feisty#FTP_Server
If inetd doesn’t work http://ubuntuforums.org/archive/index.php/t-79588.html

Install MySQL Graphical tools

Application->Add/Remove->Programming->MySQL Administrator, Query Browser, RapidSVN
   >Internet->Filezilla

Install SSH

For Capistrano (preferred way to deploy a Rails application) to work, you need ssh enabled on your server, and an SSH client on your development box.

http://www.nukesilo.com/2007/03/08/installing-openssh-on-ubuntu-linux-ssh-part-1/
putty:
http://www.chiark.greenend.org.uk/~sgtatham/putty/

P.S: 

Hope you found this useful:) Please do add a comment if you have additional useful pointers to share… it would be great if this post could grow into a ‘living’ list of things one could do to build a kick-ass Ubuntu Rails setup.

Alright, on to the technology stack! 

To truly appreciate the lesson here, I need to share with you a bit about my background, which is technology related - I love building software and have been involved in initiatives touching almost every aspect of the software development lifecycle; I’ve led server teams as well as driven the architecture, design and development of many large-scale products, mostly in the enterprise space. And for all of the 8 years prior to getting involved in this start-up, most of my development had been in Java, J2EE (JEE) and related technologies – put forth a particular technical challenge to solve, and I was confident there existed a Java based utility, library or web-tier framework that would enable me to solve it in quick time, given my expertise. The reason I mention this is to drive home the point that I lived, breathed and swore by Java and JEE; if anyone mentioned C# or .NET or PHP (heavens NO!) for web-application development, I would mock and taunt them, then laugh myself silly. 

My current role in the company is two fold – As the Engineering Director, I am responsible for driving the engineering effort which includes defining the processes, building, managing and leading the engineering team, and planning/executing the iterations and development road-map; As the Chief Architect, my responsibilities lie in determining the technology stack, architecting the product, defining the test-plans, performance metrics, etc., managing deliverables of the different engineers, and as the senior developer, driving the design and development of the application(s).

The first task was defining the technology stack and development tools. And I am sure you can guess what I came up with initially!. In my first presentation to our team on our options, I’d created a Mind Map of all the open source Java tools, application servers, ORM libraries, web frameworks etc. we would require. Here’s a sampling of the stack I proposed then:

• Language: Java
• Web-framework: Struts, Servlets, Jsps
• Javascript Toolkit: Dojo
• Business-tier: Spring based injection of POJOs 
• ORM Layer: Hibernate
• IDE: Eclipse (Java IDE)
• Servlet Container: Tomcat
• Unit Tests: JUnit
• Code Coverage: Cobertura
• Database: MySQL
• Performance/Profiling Tools: JProfiler, JProbe

We had set out to develop a product suite of consumer oriented web-applications, targeting  15 million potential users. Analyzing the domain and the requirements, it was clear most of our data would reside in a back-end repository and would be inherently database driven. So the above set of tools and servlet container would suffice, and there wouldn’t be a need for a heavy-weight enterprise strength app-server platform like JBoss supporting EJB and the like.

Around the same time, I’d heard of Ruby On Rails, a relatively new web-framework especially suited for database driven applications. Google it, and you’ll find tons of articles on folks who’d used it, and swore by the productivity improvements they saw – I came across articles that mentioned 8-10x productivity increase using RoR v/s a Servlet/Struts/JSP based solution!

The Nay-Sayer:

Now, the sceptic in me was quick to trash this as just another ‘me-too’ web framework. I’d seen this all too often - a hot new framework fuelled by hype from the trailblazer geeks who wanted to show how ‘different’ and ‘in tune’ they were with the latest and greatest, only for reality to bite in later and see this go the way of the Dodo. And there was merit in this view, the industry is littered with remains of the early adopters who were seriously set back because they bet on the wrong technology.

The other reason, as I mentioned earlier, was that we were *very* familiar with the above mentioned Java development environment and tools. We knew we could get something out there quickly. When you’re starting off, you want to keep the unknowns to a minimum. Going with Ruby On Rails meant we were injecting some serious unknowns to the core of our engineering effort – it wasn’t just about learning a new web-framework, it was the entire eco-system around it that we’d need to learn as well, which was quite different from the world of Java that we knew, loved and were experts in. We’d need to learn a new language (Ruby), a new ORM layer (ActiveRecord), the actual Web-framework (RoR), the Javascript framework (based on Scriptaculous and Prototype), the deployment mechanism (Capistrano, Mongrel, Lighttpd, etc), and familiarize ourselves with all the Gems and Plugins available in the RoR eco-system so we don’t reinvent the wheel. Add to this mix the fact that the deployment platform was Linux (we’d worked with Unix in the past, but because of Java’s byte-code abstraction, I’d worked mostly on Windows for my development), and I’d have to be crazy to go this route.

Finally, I had a day-job as well, and I expected the nights and weekends to go towards this endeavour. I really didn’t think I’d have the bandwidth to learn a slew of new technologies fast enough to actually see the ROI.

The Yay-Sayer:

But there was this other part of me that was really curious – no one would put their reputation on the line to claim the 8-10x productivity unless they did see a pretty substantial uptick in their ROI. In addition, many well known Java evangelists, well respected in the community, were actually jumping on the RoR bandwagon. Ruby as a language was starting to gain serious traction (it had been around for as long as Java, but had languished in obscurity because documentation was sparse, and mostly written in Japanese), and RoR was being identified as the killer application that was pushing the programming community to migrate to this language. Whenever you have an application driving the adoption of a language (rather than the other way around), you know there’s something there.

I was taking a month long break visiting family before joining the endeavor, and that worked to my advantage. I spent 12-14 hrs each day that month reading up on everything RoR. At the end of that month, I was convinced Ruby On Rails was the way to go. And when I got back, we did. If I hadn’t taken that ‘vacation’, I probably would not have had the chance to research and read up on Ruby and RoR, and we’d very likely have ended up working with our Java stack.

We are now a Ruby On Rails shop, and we couldn’t be happier. I am not going to espouse the virtues of the Ruby On Rails framework here (I’ll cover it in a future post). But when someone like me who’s been a Java enthusiast says ’selecting RoR was the best decision we made’, stand up and take notice. 

Horses For Courses: 

Every technology stack has a purpose and value, but there are some that are better suited for certain tasks as compared to others.

Ask yourself whether your application is likely database driven. If the answer is yes, then I urge you to take a step back and not rush into using the stack you’re familiar with, but rather choose a stack that makes development faster, cleaner, easier and more FUN. And Ruby On Rails makes development fun. The dynamic and meta programming aspects of the Ruby language and Rails’ exploitation of it makes certain things work ‘like magic’, and it’s sort of like a treasure hunt, trying to find the next ‘wow, that’s cool!’ nugget in the framework. And Ruby on Rails is a perfect fit for developing web applications. The first couple of months may require serious investment of time if you’re a newbie. But 1 year down the line, and I can state unequivocally that we’ve got a lot more done, with a lot less code and in a lot less time than we could have got done using a Java based stack.

It’s quite likely you’ll probably just read this post and then move on to the next one. But if there’s that that one thing I’d want you to take from my blog, it’s this. Give RoR a try. There are a dozen (nay, a lot more than that) reasons to go this route. Remember, you’ll reach a point where you can hire talent, so don’t think you have to learn EVERYTHING. You will at some point hire developers. But RoR gives you that red-bull turbo start that every startup needs.  I’ve experienced it first hand, and I hope it helps maximize your team’s efficiencies as it has mine. 

PS:

Ruby On Rails is not the panacea for everything. This post is applicable to you if your idea can be developed as a web-application that is inherently database driven (where most stateful information is ultimately stored in a  back-end repository).  Most non-communication/non-realtime web-applications will generally fall into this category. Otherwise, a Java stack may prove equally useful.

 A tip: Master the book “Agile Web Development with Rails, 2nd Edition”. It’s a great read, and the author does a fantastic job showing you how Rails is a natural fit for any Agile development methodology.

An interesting question that always seems to pop up during conversations with fellow entrepreneurs is what constitutes an ideal engineering team for an Internet startup when getting off the block. Assume you had to select the smallest set of individuals possible for your engineering function when starting your company, who would you hire? What are the bare minimum skills you’d need?

I thought it would be nice to start our journey by addressing this head-on and highlight what we did different, why it worked for us, and why I believe it’s an option you SHOULD consider when building your startup team.

Ask a first time entrepreneur, and the most likely answer is that a couple of senior developers, one with UI experience, and one with experience with the server stack and a domain expert should suffice. If the luxury of an additional resource could be added, it would be another junior developer. After all, you’re just getting started, there’s not much of a product definition, and the priority is to get a working (well designed) prototype that can later be tweaked and given a face lift when some decent functionality is in place, right?

At first, we felt the same. But as I will cover in a later post, one of the earliest (and best) decisions we made was to get out of stealth mode as quickly as possible. This driver made us question common wisdom to see how we could go ‘live’ faster. We wanted to accelerate as quickly as possible, build momentum and have a product on-line and *usable* by the general public as soon as possible.

“Usable”… That’s right! Usability - it’s a key component that we felt would ultimately determine our success in this space. Our product was trying to make a convoluted process as easy as 1-2-3. So for us, the usability aspects and the UI design had to be at the forefront, and not an afterthought. For that reason, the first step we took was to hire a UI designer/Usability expert, even before we thought of hiring any additional developers.

And it’s worked out well – from the onset we had a product that was UI focused and driven, and stories were created from the user’s perspective. There was a time when the walls of our office were just pasted with reams and reams of paper documenting different screens and how one flowed into the other. We had actual UI mockups of the application and flows in place even before the first line of code was written.

When you’re planning iterations, having the UI specs and design/stories in place at the start of an iteration is a boon. Not only did we have a great UI experience already visualized and captured on file, we also had the UI specs available from which to plan each iteration. And if you’ve done development with XP or SCRUM, you know the benefits of having a user story defined through actual UI mockups.

So in my opinion, the bare-essential startup team would be the following:

1 Architect/Senior Developer/Manager. 8-10 years experience. If you can get a hands-on architect with great coding skills who has led development teams in the past, that’s gravy! He is the guy with the big picure who will define the iterations, architect the application, implement server code, lead the developers and effectively run the engineering organization. Each type is not difficult to find, but if you find someone who can wear all 3 hats, you’re at an advantage.

1 UI developer. Coding rock-star, minimum 2-3 years startup experience with Javascript expertise along with CSS, Ruby On Rails (RoR) and Ajax support in RoR. If he knows Php, that’s gravy too! He will be the UI go-to guy.

1 Domain Expert. Generally, the founders will be the domain experts (since they identified the opportunity, that’s the likely case). And there’s empirical evidence that most successful startups generally have 2 founders (checks and balances, bouncing ideas off each other, etc. etc.). So it’s quite likely you’ll have 2 domain experts.

1 Server Developer. Coding rock-star, minimum 2-3 years startup experience Since we used Ruby on Rails, someone with RoR experience, and has deployed applications to production environments before. Deployment experience is a must.

1 UI Designer/Usability Expert. Generates the user experience, defines the user personas that represent the customer, orchestrates the screens and application flow. Generates the UI specifications each iteration that forms the basis of the engineering effort for that iteration. 

Net: 5 (or 6 if two founders). And don’t worry about Q/A… just ensure you define a good test plan, and folks will be able to find cycles to dedicate towards this.

In my opinion, this is the ‘bare-essential’ engineering team to give you that turbo-start. Some might argue that having 2 senior developers negates the need for 1 senior and 2 junior developers. On the contrary, I think 1 senior and 2 junior developers trumps a combination of even 3 senior developers for two simple reasons:

1. Your younger kick-ass coding rockstars have the hunger, drive and TIME you’re just not going to see in your senior developers, period!
2. If your 1 senior developer has managerial skills, he along with the younger developers will always give you a superior ROI in the long run.

And select the right technology stack and you can effectively quadruple your ROI. But more on that in a later post.