Sushrut Bidwai

The post which will bring some very very interesting discussions/debates/fights. Here it is.

(Before starting flames on this post, do read the last line note.)

When I co-founded this company and decided to work with early stage startups, I was faced with technology choices. Ruby was (is) getting mainstream momentum. Many startups were using it. PHP, no matter how much I dislike it, was still used widely. Python with Django was also started getting some ground. .Net and Java being as important as ever. Choices were there, all looking good on surface. Features were all there. We decided to evaluate all these technologies. We both come from deep roots in Java and object oriented technologies and do have some bias towards it. But still we tried to do our best. We listed down all pros and cons for all these technologies. Investigated all of them. Build sample projects/apps in all of them. Talked to experts, technology mentors.

Also while making the choices we had some limitations on ourselves and this choice should be evaluated against these limitations.

Limitations - 

• We are not building one single product. We will be building many products, for diversified set of applications. For mobile, for web, for enterprises, for embedded devices and may be even for space crafts.
• Talent acquisition, training and retaining costs. Though we build cutting edge products, we still are a services company.
• We use our services arm to groom engineers. So finding projects on same/similar technology which can be executed by services division was also essentially, but this was more of an nice to have feature rather than limitation.
• We will be working for many startups in next few years. We want technology to support creation of off-shelf components and using them with multiple startups where ever possible.
• Knowledge transfer for code/design and technology should be minimal. Again nice to have but not exactly a limitation.

Design Methodology, Startup, Technology django, GWT, java, Perl, PHP, product, python, ruby, What not

In last few months or so, I have had debates, diplomatic way to say I had fights, with fellow geeks about how to choose technology for a product. These parameters are not necessarily for startups, but in general. In the next post, I am going to write about how these parameters gives clear advantage to Java and GWT when it comes to Web applications.

Feature Set - 

   Most of the technologies, or the eco system around them, provide enough features to build any application. True, this wont be the case if you are developing an embedded application or application for space craft etc. But most of the enterprise, web application can be built using any of the technologies. Python, Ruby, Perl, Smalltalk, .Net, PHP, Java and Flex provide everything that is required to build an application. From language point of view, these technologies will differ significantly. Features they offer to developers and geeks are not considered. A true geek develops kick ass application, which creates wealth for the stake holders. I never believed that geeks who say “I wont work on a Windows machine”, are essentially good for the company and its success.  But bottom line is feature set is pretty much common in all the important technologies and no single technology is at advantage here.

Performance -

  Very selective call. If you are building a next SSN (Stupid Social Network ) then you will have to consider serving million users. If you are building a banking system, you will have to consider serving million transactions. If you are an Ajax heavy application, you will have to think of Javascript caching and issues it presents. Performance of the complex business algorithms is essential to the over all performance of the system. Can technology take advantage of multi-core CPUs? Does it support good distributed session management? Does it have strong security features? Can it scale? How big is the footprint of application? CPU Vs Database Vs Memory Vs Bandwidth tradeoffs. One of the most important thing in performance evaluation is, you cant generalize it. In my experience, the only theory which has hold true, is the last statement when it comes to performance evaluation.

   But again, Java obvisouly holds and edge over all other technology. Java deployed on a Linux machine with Sun RISC servers to back up, makes up the highest performance you can get. Although other technologies may not be that far behind. So for a reasonably high throughput requirement system, most of the technologies will provide you support to tune them and make sure you achieve your numbers. If you use Java, then you have to worry a little less about such tweaks that are available. One of the reason is, sheer number of high performing Java apps around and availability of quality Java performance consultation.

Maintainability -

  This is point I consider the most while choosing a technology. All other points does not give clear advantage to any particular technology. But maintainability of any particular technology is so inherent to the technology itself that this becomes a very important criteria for selecting it. A product has to be supported, enhanced, maintained for a long long period of time. Successful products tend to out live the creators. Technologies will change very fast. Product will have to adapt as per changes. Code written by you will need to be maintained by some other, may be less talented person. The code will under go lot of changes as time goes by. Does technologies you are choosing help you in keeping code maintainable? Does it provide clear constructs and architectural/design patterns which are self explanatory? Can you look at your own code written in that technology one year down the line, and explain it to some one else? Is data flow and control flow clearly depicted by the technology? 

Talent Acquisition -

   A product typically wont require more than few dozen people to develop. But as the product becomes successful, you are going to need 100s of developers to maintain it, support it, enhance it and keep it improving and delivering value to your customers. Can you acquire such talent which is required to maintain product you have developed using the technology you have chosen? I know a team of 4-5 python programmers who developed a product (not so good product) and when they wanted to expand their team to add few more programmers, it took them 8-9 months to find 2 programmers who fit the bill. If the product was developed using Java/.Net it would have taken less than 1 month, if the product would have been developed using Smalltalk, they never would have found those programmers. 

   But that does not mean you cant use other technologies at all. But you will have to know that, you cant rely on the outside to get you talent. In India, no recruiting agency will even understand how to shortlist Python or Smalltalk programmers! So you will have to come up with a contigency plan to cope up with situation. You will have to hire talent which is good in some other similar technology and train them. You will have to hire ahead of the curve and spend money on training. If you can do that, then you can choose such technologies, else not.

Distributed team work -

  Now lot of experienced folks are going to be pissed off with this, but these are my views from my experience. No matter which product you are building, how big or small it is, at some point in time you will be working in a distributed environment. Some programmers working from home, some from other continent and other timezone. So can technology be so efficient to make sure you can support such distributed team structures. Can multiple programmers work on same module/file without having to spend a lot of time on resolving check-in conflicts? Does technology provide good patterns to support separation of concern, so that you can work in horizontal or vertical team structures with out creating lot of issues? Does the technology at least comes up with a really good Diff tool? .

Eco-system -

  Your product is going to live long long time if it is successful. True, having a successful product means you can spend money on porting it to whole different technology if required. But such porting rarely happens. We are still bridging with applications which run on mainframes. Businsess will very rarely do such porting. Its risky, expensive. Also are you going to fire all programmers who worked with you in making the product successful? No! So re-training costs. 

  So what you need to consider is, how good is the eco-system around my technologies. Will the eco-system evolve as per changes in other tangential technologies? Are the technologies supported by a community which is strong, vibrant and evoling? Is this community lead by a company which makes heaps of money from the technology? Can I find a consultant in particular area, like performance management or memory management,  quickly? Are their enough companies out there who make support product for this technology? Are developer tools and environment available off the shelf? Are there any outsourcing vendors available who are competent in these technologies?

Time to market - 

   People say in todays world time to market is reducing very fast and we need technologies which accelarate the same. I say, time to market was always an essential factor in considering technologies. Today we have large choices of technologies to choose from which provide very different time-to-market and hence the big discussion.

   Again lot of people will say its so easier to build application in a particular technology, that time to market is 50% lesser than other technologies. I say, okay, may be that is possible. But what is time to market? From product concept to first public release of the product is time to market. This includes time for team building too. If it is going to take me 6 months to find good programmers I can work with for a particular technology then how is that going to reduce my time to market? But I will discuss few more things on this issue in the next post, where I talk exclusively about Java+GWT combo and how we are reducing time to market using it.

Why?

  Last but not the least parameter. Why I am choosing this particular technology? Is it a status quo to work in these technologies? Am I a true if only I work on products which are written in this language? Are my customers well versed with this technology? Is the cost of building a product much lesser than other available technologies? There can be numerous such Whys, but you need to be clear about this.

Implementing Concepts, Process, Startup .Net, java, Perl, PHP, product, python, ruby, Smalltalk, Technology