Archive

Archive for the ‘Implementing Concepts’ Category

Product technology : Selection parameters

February 14th, 2009

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 :D ) 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 , , , , , , , ,

Classroom to cubicle

January 31st, 2009

Here is the presentation from my talk about How to bridge gap between Classroom and Cubicle.

Few points about the target audience -

  • From a relatively smaller town.
  • Not much exposure to Internet.
  • No vision about career and various opportunities.
  • Not vibrant, enthusiastic about career.
Presentation was very well received. I am hoping that from about 200 student who attended it, at least 1 will take somethings home.

Implementing Concepts, Misc

You take your own interview methodology

October 6th, 2008

We are trying out this new method of conducting interviews of experienced technical/non-technical resources. This method is only used for 2+ years of experienced candidates.

What we do is we have a pre-interview with people who have applied (15 minutes) with out much technical questions after a careful screening of resume and reference checking. After this pre-interview we divide short-listed candidates in group of 3-4 people. Now the second round of interview these candidates conduct there own interview in sort of debate/group discussion. So each candidate will ask question to others in the group and they will write down answers to it on paper. 

Candidates try to bounce each other of with the cool thing they know about technology which they think others may not. We just moderate the interview after conducting 10 mins of introduction and rules section. This debate (?) is typically for 1.5 hours. Note that we do not give grades to answers, just that we moderate closely and through observation decide who is better.

There are generally 2-4 groups that we form and we select 1-2 guys from each group. This is not a rule, if we like all we will select all! Then winners of groups go through third round of interview again in same way but for 3 hours! We downgrade a person who does not ask questions, but just gives answers. We also downgrade people who are too agresive and want to show off with by asking questions which even they cant answer satisfactorily. There is bunch of observation that we do in this process. And we note down these observations not by pen, notepad or any other thing but using twitter!!!!

Why we came up with this model? Well people can answer questions just fine. There is limit to how much research I can do before going into an interview. There are only so many type of questions that I can come up with. I dont have time to categorize these questions or decide how hard they are etc etc. So I delegate by job on the person who has applied for the job itself :D .  

We are just trying this model till we see it works or not and then if it does then we will implement it for all senior positions. Do comment if you think there are some things we can try out or if you find any broken piece with this model.

Ideas, Implementing Concepts, Process , , , , , , ,

Pair training

September 19th, 2008

I have always been thinking about how I am going to train a freshly graduated student coming just out of college and joining my company. Not having a good training program in place is one of the major mistake any startup makes. I have been with a startup where we had same problem. So what we did was devise a sound training program.

Most important thing you have to understand is writing quality code is art, there is no other away to put it across. Have you ever learnt a musical instrument? Painting? Singing? How do you learn it. First you have see a maestro at work, live. Performing just for you. So you know the body language, know the small movements, listen to breathing as he/she performs. We do the same in our training program. We start with one week of class room training focused on software solutions and not technology. (We hire people who have some knowledge of technologies we use) After this one week, we give new trainees a project to execute, typically a small project like implement a blog tool, bug management tool etc. We work with the trainees in all phases of project execution.

We do requirement analysis together and play roles of customer as well as facilitator. We do design with them. But most importantly when the architecture of the project is decided, we implement a use-case for each new person in pair programming. All the trainee has to do is sit with one of the more experienced developer and watch him implement the use-case.

Advantages:

  1. When a person see how a pro writes code, how he uses various tools including time-sheets, IDEs, debuggers , he gets window into how as a professional he should work.
  2. Experienced person normally walks trainee through various things, classes as he is writing them. This gives insight into how a high level design is transformed into low level classes and data structures.
  3. We normally don’t have time to do entire low level design, attribute design. So we rely upon experience and re-factoring to some extent.  Pair training gives trainee hands on re-factoring.
  4. Get to know various tools, shortcuts, first cut what proficiency trainee should have once he/she has experience.
  5. Time management. How much can be accomplished in how much time.

Disadvantages:

  1. Sometimes there is chance that trainee will pick exact bad habit trainer has. Though we try to monitor our training processes closely, but there is still a chance. To reduce it we do pair training with multiple trainers.
  2. Time consuming. Hence we do it on a Sunday. Yes we work on Sunday! We want to grow and build a great company.

Implementing Concepts, Process, Startup , , ,