Startup Fever: Which language ?

I have never had my startup ... not at 22 , not many people except a few of my batch mates, have a startup at this age. Kudos to them and many more like them who do not want to be a peg in the corporate machinery but rather wont be different in their own way.

But some experience come in me in the form if co-ordinating for IMG in my college days. As a brief introduction IMG is Information Management Group which is responsible for management of a significant portion of IT resources of the institute. IMG is a student body , consisting roughly of around 40 students mostly taken through an elaborate process of interviews and tests and some others handpicked by giving them small intern projects.

There is in all a lot to reflect from the experiences of managing in a 40 member technical team, most of which can be (i guess) directly applied towards making a startup. I always wanted to cover this stuff here but due to a complete lack of blogging impulses it has always remained in me for almost more than an year now.

Lets not digress further and reach to the point straight away. To any new person starting to write a few bits of code (for oneself) the first question that comes is what language to write. Whenever I write code or asked people to write code for a project. I ask a few questions

Which language am I comfortable with ? Which language is the team comfortable with ? What is the size of code you want to write ? For how many users you want to write it ? What are your coding skills ? (More important) In what language you are most comfortable with debugging ? Most people are not very good code writers, but they need to know debugging pretty well, if you cant debug very well, you are bound to exceed time lines and screw up on big projects.

A good decision is always a mix of gut feeling, logic and a penchant for doing new stuff. If your gut says Java is good, a general survey tells you that people love it and you have a thing for trying out the "new framework" out there.

The problem: "Every language on this goddamn earth sucks to the core if you dont know how to ''exploit it''. " Let us say Java, I coded in java extensively, if you dont know wtf you want to do with it, the thousand s of techniques out there are sure to drive you crazy.

Here is how I decided what to do for a major project. I "knew" java sucks if u cant use it properly, key ?? the key is to understand the problem at hand and come with a design first. My problem had key features:
1. Scalability, the app was to be used by 1000s of users.
2. Familiarity for my team, everyone knew java well.
3. Maintainability for the group, can t use ASP .NET coz nobody is really interested in learning that. Everyone loves java for some strange unknown reason.
4. My penchant for the newly learned Java EE 5 and JDK 5 features !!! My personal choice goverened a few things incidently ;).
5. An elaborate mix of potentially screwing problems that a framework will take loads of code to write and a bad experience with existing frameworks.


Never write code first and than design later !!! unless you want to throw that code write out of the window or are cool with being bankrupt.

We decided to do a high level prototype of all the challenges that we could have faced and than scrapped all that code , just took a month of our time. Than redesigned the application from scratch, included all the features we wanted to and wrote all the code from scratch (no framework BS) and ran it, believe me it rocks !!

Due to our apparent lack of experience we screwed a bit at some places, but hey as far as it runs, it runs fast, is secure and damn easy to maintain ... it suffices all the requirements of a good s/w project ?? (yes it is scalable across layers and compatible across platforms, is standard compliant, has visible design patterns and blah blah blah ).

In conclusion ... the above fundas worked for me, hope they work for you :)

The "No Faith" approach to security

I dont know whether this is a known method or not but I found this approach quite good enough especially for a person like me who has no way to know everything that goes in and out of an (or any) application. The "No Faith" approach assumes that whatever class you are coding will have some malicious code executing it. You can say that you need to check everytime whether the parameters passed to you and the methods called are called by say the correct users, with the correct privileges and they have passed the correct parameters. It is also important to see, if at all you are using an API or your own code, what are the assumptions that are made in the class that you are calling. Sometimes say when you are writing C code the class may be expecting a character array of a particular length and you may be supplying a longer array or it is not null terminated. Or when you write Java (EE app) than you are not explicitly checking whther the user calling the function has the correct rights or not. Or say you are allocating a resource or using a name which already is used by somebody else or is prone to use by any other program.

So the best idea is to not have any assumptions on how things might work. A good example that came to us when coding alumni. There we check for user privileges when someone delets his own message. First it is checked on the page itself so you dont have an option. If you can somehow access that page (God knows how you can do that !!) and again you somewhow execute that call on the JSP (again I wonder how). There will be another check from the session itself that is difficult to surpass (I cant think of any way that anybody can).

The basic idea is dont trust the layers above you, they may have gotten dirty themselves, just keep a check.

I call it "No Faith" approach to security , you may call it whatever you like.

Imperfection: The last law of design

I do not intend to start a debate but i believe that imperfection is the key to a great system design. I believe that inherently the universe was left imperfect by creation ( ?? ). I think perfection is too dificult to achieve even by God (no debates on athiesm or creationsim intended ). So instead he decided to make everything imperfect and in that imperfection lies the beauty of making everything work the way it should.

I think the uncertainity principle, godel's theorem and probability are all a symbol of leaving away the details. Because in any system the minutest details cannot be stated to the infinite degree. So God or who knows the universe itself decided on its own that let us give no details below the planck distance. Or maybe it is too computationally tedious to describe the movement of each of a 100 billion gas atoms so just make it chaotic.

So the last rule of design is to make things imperfect because that is where the fun starts. Let us say we want to make a website, fully upgradeable and to the minutest details , we make it perfect. Well we have achieved everything !! Its perfect ! Now what ? Nothing else left to do , nothing to add or remove , because it is perfect. But is it possible ? It is not possible as we all know and should understand its impossible to percieve the future, only speculation is under the power of humans (or who knows even God). Perfection can only be restricted to a small domain. It can never be universal. But imperfection is universal and it works !! Some might say its not imperfection I talk about, it is just ignorance. Since I dont know so I say it is imperfect... I will just say it is impossible to make something perfect and so it is throughout.

What is possible is to make an imperfect system but to make it self improving (remember the matrix with the anomaly !). the anomalies sweep the imperfection, cause the chaos and ultimately benefits the system by making it change.

Well I gues the post is incomplete with me looking for more reasons to write more on this...

Team Design

The other day I was wondering what are the flavours that are necessary for a good team to function. Let us say I want to start a company and want to choose some colleagues ... people of the same age as myself what will I be looking for in them, or even for a company project. What are the essential qualities that should be present in a team ?

Now one can go at lengths to explain how to pick up the right team and what kind of qualities should one have ... let us keep it for some later time. Let us say that there can be three primary drivers for any project. The drivers come from the problems that a team faces in implementing anything. Let us consider a generic engineering problem and expand it on a managemnt perspective.

To start on any problem one needs good technical skills. So you always need a few guys or at least one person who has good technical skill. The skill-set may not be so important but the ability to evolve and to learn new stuff fast is really important.

Now typically any implementation is faced with hurdles apart from technical. These can be tedious political processes, long corporate cycles or hostile market dynamics. Situations where a person's skills at dealing with people with the right attitude is required. People with attitude are very important to a team which has to do a lot of public dealing. You need to know when to show the right emotion to the right guy.

The last key point is to have feelings about the work you are doing. If people do not feel for their work they can never perform in it no matter how much brain or attitude they carry. One always need to have someone who believes that they have a great idea or someone who believes they are going on the right path. Somebody to move the flagged souls of their peers.

To sum up the three things that make a good team body are brain, attitude and heart. Whaddyasay ?

Upgrading at the speed of thought !!

The other day I was thinking about designing systems that are upgradeable. While working on the alumni project (it is basically a social networking site) several time sI had this thought of making the design upgradeable.. so much so that you think of a feature and u can implement it in a few hours.. say 2-3 hrs. Thats what upgrading at the speed of thought should be like.

It is certainly difficult to make systems that are so upgradeable.

.. and with the way most people use languages it seems more so impossible now !! Lots of code and long call stacks one leading to another and hell of code to understand.

(I started this post long ago .. its kinda incomplete)

System Designs and Hacker's Perspective

Back in Roorkee I was occasionaly asked this question: How to be a hacker ? Not that I am a hacker myself... neither I ever claim to be one. To be frank according to the widely popular definition of hacker, I am most certainly not one. Not to digress further, I encountered a howto once on becoming a hacker.

In my very own definition a hacker is a person who has got a really good knowledge of a certain or a class of systems. A hacker can hack a radio, a spectrum , a software or even a car engine. More importantly he cannot be the one who designed the system but has a keen interest in it. To hack is to exploit the system to make it do what you want it to do but was possibly not an intended application. Like you can hack a PSP to play it like drums (somebody has actually done it!!).

So how is system design and a hacker's perspective related ? There can be at least two types of system designs in relation to a hacker's perspective. One that keeps into mind that there will be people who will try to tinker with the original system and try to expand it. The other types of systems are those which are strict about their rules and will not allow anyone to exploit them for any other use.

Let us consider the latter case of the two and divide a hacking problem in two parts. One the component to be hacked and other the platform on which it needs to be hacked. A hacker keenly studies the design of both the systems, typically a top layer and a bottom layer, the top is where the hack needs to be performed and the bottom layer is on which the hack will be done. An analysis of behaviour of both these systems is required. One needs to know both the strong and weak points of these layers and needs to put them together and tweak wherever possible to get the desired output.

Therefore from the hacker's perspective a system can be manipulated if it is layered and each layer there is a possibility to do some sort of analysis and somehow effect the behaviour of system at that layer.

Some Good Links

Due to my lack of creativity in the recent months and the non-disclosure agreements that I have been bound to.. I am not able to come up with something good enough to be written on this blog. However I will take this opprtunity to link up with some good posts like the ones by Joel Spolsky. Not any in particular but the ones on Windows Vista Shutdown Button, Interviewing techniques and the k-i-s-s rule are really good. There is a lot of stuff toread on his blogs.
I frequent slashdot and come up with some good stuff now and than that ranges from UI design to programming languages. In am a big fan of OS designs although since I have seen and worked with OpenVMS .. it is really one of the best systems I have worked with... I feel kind of elated everytime I read some stuff from Tannennbaum (OS). I like some of the concepts in OpenSolaris also, if somebody cares to look for, especially dtrace.
Sun reminds me of Java and the JSRs. I was working with Java EE 5 back in college and read some good JSRs on web services, ejb, security and rules. JSRs should not be read by anyone unless they want to work on reference implementations and still want standard compliance. However the blueprints on Java Core patterns are a good place to learn about enterprise application designing.
Thats all I can recall right now, I have got to go back and solve a customer case ..quick :)

My First Views

Creating this blog has been on my mind since I started to work on the alumni project in IMG back in IIT Roorkee. I realized that its not just operating systems but in general any kind of system that interests me. The alumni project was by far the most detailed design expeience I ever had. I had previous experiences in software designs in my various academic projects but alumni was diferent because it dealt with enterprise level designing. In any case, I am creating this blog to post my views and opinions on system design in general , not just enterprise designs but everything from operating systems, programming languages, programming concepts, hardware designs and system implementations... and of course take views from others also.

The idea of creating a blog is to put instant thoughts as well as detailed experiences at one place. So just check out for some interesting stuff here.