Outsource Your Development Process Tools

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!

Is it Healthy to be Stealthy?

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.

Prioritizing for Success; Living, Breathing 80-20 – Part II

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.

Prioritizing for Success; Living, Breathing 80-20 – Part I

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?

Ruby On Rails Cluster On Ubuntu using VMWare

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.

Setting up Ubuntu Linux For Ruby On Rails Development

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. 

Horses For Courses – Selecting the Right Technology Stack!

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. 

The Essential Startup (Engineering) Team

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.