Startup City

Yesteryears' industrial age taught us to think production as a series of disconnected steps.

Raising captial, acquiring raw materials, recruiting workers, developing product, advertising, selling were all seen as either sequential or as isolated from one another.


In the new information age, the information gained by the sales and marketing people feeds the engineers, whose innovations need to be understood by the financial people, whose ability to raise capital depends on how well satisfied the customers are, which depends on how well scheduled the company's trucks are, which depends in part on employee motivation, which depends on a paycheck plus a sense of achievement, which depends .... et cetera, et cetera

Alvin Toffler in Power Shift (1990)

The ability of the employees to collaborate with multiple domains and technologies will be the key factor of success in the information age of future. Old management models like imposing work on employees with force of fear or money will produce mediocre outputs, or might even fail.

Employee motivation will be the key factor for high productivity.

From last week's Eclipse Community Survey, majority of the feedback were from firms which have 0 - 100 employees. I guess this trend means more startups, small to medium size companies are getting involved in Eclipse and open source.

Apart from very few super big firms like IBM, Nokia, Oracle etc not much companies have well thought about the importance and advantages of moving to open source.

Nevertheless,

If you have plans to start on your own,
if you are interested to learn about latest technologies,
if you like to watch the young entrepreneurs with the fire to succeed,
if you want to spend a day of worth,
and if you happen to be in bangalore next week,
don't miss this show.

100 startups are showcasing their products. Talks by CEOs from billion rupee firms!

If you are interested, you can register for the show - Startup City @ http://www.siliconindia.com/startupcity_09/index.php

madhu

Data Hiding

Today my blog is not directly related with eclipse. Lets have an OO discussion.

This started with a thought provoking arguement with one of my colleague. 

Problem - We have a public method which needs to return a data structure, say a 'List'. Which method signature attributes to a better design. (a) or (b)

(a) public List getRecords();

(b) public RecordCollectionVO getRecords();, where RecordCollectionVO is an object which internally stores a List instance.

Lets analyse both the cases. 

Arguements in favour of (a)

1. The method is implemented based on design by contract.
2. An extra class just to hold a list is an overhead.
3. Tomorrow if the 'List' changes to a Map, anyway the module which access this module needs to make a few code changes. Then what the heck in changing the method signature as well. Why are you lazy to change one extra line of code?
4. The chances for the data structure 'List' to change are rare.

Arguements in favour of (b)

1. The method returns an object which hides the internal data structure which it uses.
2. Tomorrow if the methods wants to return a Map instead of a List, the method signature will be unaffected. Hence which ever module that invokes this method doesn't need to change the way it access this method. 

I would opt for (b). Why?

Lets analyse a scenario which addresses both cases.

Case (a)

Consider three modules X, Y, Z.

Module X has the following method.

public List getRecords();

Module Y accesses module X and delegates the work to Module Z.

List list = moduleX.getRecords();

moduleZ.modify(list);

ModuleZ has the following method.

public void modify(List list);

I get a change request from my customer. I need to change the datastructure from List to a Map. In this case I need to modify the method signature, which inturn forces me to modify module X, module Y and module Z.

Case (b)

Consider three modules X, Y, Z.

Module X has the following method.

public RecordCollectionVO getRecords();

Module Y access module X and delegates the work to Module Z.

RecordCollectionVO rcVO = moduleX.getRecords();

moduleZ.modify(rcVO);

ModuleZ has the following method.

public void modify(RecordCollectionVO rcVO);

Now I need to change the datastructure List used inside RecordCollectionVO to a Map. In this case I do not need to modify the method signature. Thats good. But I have something more important here. I do not need to change even a single line of code in Module Y. The modules which need code changes are Module X and Module Z. 

If I can save atleast a single module from a single line of code change, I do not need to test that module again.

What ever, these are just two schools of thought. 

Pragmatic Visuals!

A few months before, when I joined in my new project as a software developer, one problem was alarming me. This is a project which is running for the last two years. I need to understand the code to add value to the project.

If you have coded for at least a couple of years you might know that the programs of many software projects wear out by the sheer complexity of the programs itself. You need to be extra cautious to see that the programs do not rot.

I read hundreds of java classes in my new project which had thousands of lines of code. I generated the UML diagrams using IBM's Rational Software Architect. The diagrams were drawn in my 15" monitor. It was like looking at a football ground through a key hole. I could see bits and pieces of the diagrams in a single glance. I scrolled and scrolled and scrolled. My brain found it hard to store the previous images in it when I scrolled to new locations. Damn! I need something more magnificent, more useful.

I tried the eclipse pde incubator project - visualization tool to see the relation between the different eclipse plugins! Things are getting better and better.

Oh! World! We need to progress a lot with our visualization technologies to handle the complexity of already written code. May be... to generate code as well.

I wished I had a device like Tom Cruise had in Minority Report, where I can project the UML diagrams in the space around me. A 3-dimensional projection. I should be able to walk through the diagrams and see the connections between the classes, packages and plugins which makes up bigger modules. I should be able to turn the diagrams with small devices connected in my finger tips. I should be able to create new modules, modify it and generate code to see a running application with a few clicks.

With GEF-3d around the corner we may see some innovative tools in the near future.

Definitely human race will pick up to beat the complexity around us. See this video about a mind boggling gadget. No more descriptions, see it by yourself.

Speed .... drhhhh

The Whetstone benchmark is a benchmark for evaluating the performance of computers.

According to Whetstone, you can see below the number of MWIPS (Million Instructions per second) for java and C++ applications in an Intel core 2 duo 1.8 GHz machine.

Java = Around 1000 MWIPS.
C++ = Around 1600 MWIPS.

Whetstone Results






If your application is slow who else can you blame now? Definitely your algorithms!!! Revamp all your old slow paced code.

Let your application top the throttle ... Speed up ... drhhhh

madhu

What would we have been if computers were not invented?

Hundreds of developers are working in Eclipse community day and night. At the moment, sixty seven active individual committers are working in different eclipse projects, probably after their day job. Why? Still many add value to the community by sharing their thoughts through newsgroups, bugzilla and blogs. Why?

We are a breed of people who like to create things out of our imagination. We like to imagine. In Lord of the Rings J R R Tolkien created hobbits, elves, dwarves and orcs from his imagination. In Harry Potter J K Rowling had created a set of magicians and witches from her imagination. Steven Spielberg creates a new world in each of his movie. The same way we like to create artefacts which shapes thoughts and visuals.

If computers were not invented we all would have been either writers, film directors, music composers, teachers, professors, stage artists, painters ..... the list goes on to the pure imagination of individuals.

Hence we often see the topic that compares computer programmers with artists! We go back to our roots when we compare ourselves to artists! The value of software engineers are increased when their artistic imagination is sharpened with the engineering skills.

The aesthetic beauty of views, editors, perspectives, wizards, menus, dialogs and much more of eclipse are mesmerizing for many eclipse developers. When we see our underlying task getting executed by the progress of a progress bar our mind will be filled with content feeling.

In a way we all are writers. We write tons and tons of lines of code. We draw beautiful figures in the form of class diagrams, sequence diagrams etc which sharpens our skill to create. We paint the class diagrams by realising them into wonderfully architectured frameworks, graphical user interfaces etc. If red, green and blue are the basic colours for a painter, 0's and 1's are our basic building blocks. From bits we create virtual worlds on which the real world depends more and more.

We are true artists of our genre!

madhu

From 1 to 1000

Eclipse started as a closed project in IBM. The first version of Eclipse was released in November 2001. Eclipse was annonced by IBM as a $40 million donation to the open source community.

Erich Gamma explains how seven years with eclipse has changed his views on software development. See the video!

As of today, http://www.eclipseplugincentral.com/ has 1125 eclipse plugin projects. In http://eclipse.org you will find around 100 high profile eclipse plugin projects.

Eclipse replicated from 1 to 1000 projects in 7 years. And where do we see our community after 10 years?

For me what does this mean. I can talk with lots of like-minded people in eclipse community. People who like to code, code and code again. :)

madhu

Hello Eclipse World!

Hello Eclipse World

I started my first blog http://mksamuel.blogspot.com with the intention to publish a few articles on Eclipse. The idea was to be part of the vast and vibrant community of developers and collaborators of Eclipse.

But eventually I started to post off-eclipse subjects. My interests vary from music, photography, movies to eclipse, datastructures etc... Hence I intent to keep http://mksamuel.blogspot.com entirely to post my other interests and to keep this blog entirely to share my knowledge of eclipse as well as eclipse related technical posts.

Please visit http://mksamuel.blogspot.com read about my recent post on Mind Graph Theory - Dreams Explained.

Madhu