Vinod,

This is a great question. Utility computing is what you get with cloud resources. These two terms have been mixed over the years but Cloud computing is the way to get to utility computing. Hope this helps clarify, I would love to write more on this some day.

Regards,
Alok

If I am not wrong,with utility computing you will have access to all the required software and hardware on demand. So why ‘Cloud Computing’?

Thanks,
Vinod

1. The team I had in mind wasn’t just development team but the people involved in overall product development.

Money and time are both contraints and this is where a good manager plays a critical role. I have been in situations like this almost all the time since I had to manage multiple orjects all understaffed :)I ended up forging apartnership among those team to develop sharable code. The key I found was to be a minimalist when it comes to developing software. It requires some creativity but if you could adopt your design just a little to improve usage of of the shelf code, it can reduce developer work load a lot. This comes with other bagage but this is something that worked for me in the environment I was in.

2. KLOC for existing code is reasonable to use for the estimations you are talking about. I was referring to the new code developed. More lines of code does mean that the developer did more work but what I am putting in question is if that is all necessary code. If a developer took the same time and achoeved the same functionality with far fewer lines of code (and I do not mean cryptic programming practice) then I would consider that to be a better outcome.

3. Start-ups in general follow rushed development and your observation is quite accurate but this is where experience comes into play. Start-ups do not allow much time to learn, results are expected (demanded sometimes) quickly. If you have a couple of experienced members on the staff, they can prevent some basic mistakes from being made just because they have done that before. But all of this depends on the situation you may find yourself in with a startup and what you can do to influence it (sometimes even that does not work ).

4. 5. 6. I am happy to see that my experiences are quite close to yours I am sure there are others who will find this to be true as well

Thanks again for your comments and questions.

Great post Alok,

Kevin

1. I totally agree with you on the need for a team. However, there are cases (like my company) where budget constraints restrict the size of the team. According to these folks, time is not a constraint but money is. They fail to understand (even when told) that the cost of development might be a lot higher in this case than otherwise. I’m wondering if you have come across such a situation in your career. And if you could please highlight the process you adopted in one such case.
2. I still use KLOC as one of the metrics for time and resource estimation. I’m not sure if you have any other metrics in mind.
3. wrt start-ups, I have worked in one too. Again, I totally am with you on the re-architecture for sustainability part. But the need for to-go-builds and customer impact are so high that the first few customers end up being the worst served (in terms of build quality). Add product customization into the mix, and the end result is a recipe for disaster.
4. wrt UI, my formula for relative success has been prototypes and loosely coupled components. Also, the way I see it, UI richness is not for all systems. For example, I’m building a close-to-realtime healthcare solution. The need here is for a presentable UI with precise & accurate functionality. I guess at some point the end user does budge. But for all practical purposes, there is not one perfect UI. As you rightly said, it is perception.
5. Lesson 8. I can relate to another funny incident analogous to this. I knew this guy in a start-up developing web-based solutions on the .NET framework. He was telling me that they moved over to 3.5 because MS came out with it, it is the in-thing and everyone’s moving over. I kinda told him, its not 3.5 if you dont use it the way it is supposed to be. To be honest, I had no chance of familiarizing with the Agile principles till I was at p&p and met JD. First, I started appreciating it, and later followed it. I also learnt that its not meant for every situation. Very good point.
6. Haha lesson 9. My favorite. Another reason why I loved my stay at MS. I got the freedom to use my power hours (in the night) and not just limit myself to the hours at office. Like my brother say, “sometimes the next best invention might strike you in the ‘loo’”.

What a wonderful lessons you shared here… wow
I was reading and it all resonated with me so much.
My favorite though are #6 and #7 - heaven

The other one i loved a lot is “Assess the needs.” This one is too relevant to the situation i am dealing with right now. Right on!

Good stuff.