I recently put a suggestion to my boss asking if we could open source an application that was developed by our team. I will not delve into finer details of the application but it is something that we have worked on for the past two years.
We have added most of the features that we set out to have in the application. The application is pretty stable now with very rare downtimes. The user awareness is there and growing every day. People have started using the application and are increasingly asking for some usability enhancements. I felt that this was the perfect opportunity to go open source with it (with open source, I mean only within the company. My organization is still not into the culture of open source, not yet anyway)
My boss felt that it was too early to think along those lines. But I wanted to get my readers's views on this.
How does open sourcing projects within a company work ? In my opinion, it should work in pretty much the same way as "real" Open Sourcing works. There could be issues with people spending too much time on open source projects in the organization while not spending equivalent time in their assigned projects. These are issues which I am sure will be ironed out if the attitude taken and the approach taken are right.
In fact, I would use this post to go one step further and suggest something even more radical. A software company should only take up projects which the employees want to work on. Then, these projects could be open sourced so people with the required skill-sets could work on them. Obviously, this model requires that you do not have actual project teams. People assign themselves to projects they are interested in. If the company takes up something and finds that folks are not interested in working on this or that project, they could say to their customers : "Sorry folks, we cannot help you here" or suggest a better approach.
I understand that there are several flaws in this approach.
For one, democracy does not always work. Developers do not always know what is best for them. You need to do the donkey's work sometimes to learn before you can develop something new. Newcomers to the industry will not necessarily appreciate this fact.
Second, open sourcing is mostly meant for applications where there are never-ending opportunities. Consulting companies do not often work that way. They usually have a project with a fixed deadline and a fixed schedule. They are expected to deliver to their clients within a certain period of time.
Third, open sourcing has this bad reputation of being a developer's paradise. There have been open source projects where the contributors have gone overboard with exotic features while neglecting basic etiquette like documentation, good GUI etc.
(Read this excellent piece on the shortcomings of the open source model in general)
With all those flaws that I mentioned, I still feel that things could be tweaked. No model is complete in itself --- you need to customize it to suit your field of work.
All that was my take...what is yours ? Please pour in your comments ...
Thursday, March 08, 2007
Wednesday, March 07, 2007
Data, data everywhere -- not a drop to drink !
I am not trying to give away anything here. But the organization that I work for is obsessed with collecting data. My estimate is that we spend an average of 30-40% of our time trying find out where we stand.
All operations are geared towards facilitating the data collection process -- how can I tweak my project management so I can get more data about the ..er...project management ? Status reports are prepared and shared quarterly, monthly, weekly, daily...There are whole applications developed internally whose sole purpose is to provide reports and charts --- to slice and dice data in a gazillion ways : how many projects did we complete last week where two or more people were involved where there were two Java developers and 1 DBA ....
And, these dashboard applications are getting more and more complex every day. With every change in leadership, there is a change in the specs on what kind of reports should be built. Every manager has his idea of the ideal report, the ideal chart.
You can only create charts and reports when you have data in the first place. So, off we go. We collect data day and night. There are groups whose sole purpose is to collect data about the projects we do, about our customers, about the revenue we make, about the business we won, about the business we lost, about the number of people who joined the company, about the number of people who left....it is endless.
For every 10 things that an employee does, at least two have to do with the process of either data collection or data reporting.
With so much data being collected, there are obvious compromises on the quality (accuracy and completion) of data being reported --- but that is a whole new story altogether.
But I also noticed one very funny thing. With so much data being collected, you would assume that everything that the company does would be measured. You would assume that the operations would be managed with precision. Atleast to some extent...
But no. I will cite two examples to make my point:
The place where I work has a canteen. Let us say, it can seat 200 people at full capacity. There are atleast 1500 people working in this office. Now, how would you manage this canteen at lunch-time (say 1 PM to 2 PM when most people would have lunch) ? You obviously cannot have everyone having lunch at the same time. And you cannot regulate by asking people on certain floors to have lunch at such and such time. This is typically when your decision suppport system would pitch in and provide an optimization-based solution. You would open up a seperate dining area in the building. You would perhaps consider serving lunch on the terrace. You could consider opening up lunch earlier than usual. You could vary pricing of lunch or availability of dishes so that the traffic is staggered.
The point is: if you had an inkling of which times the canteen is overpacked, you could plan better and provide better services.
The second example is of the company transport. The company provides to and fro conveyance to the employees at pre-scheduled times in the morning and evening. But, I have noticed (with great personal discomfort) that there is no pattern to the number of busses provided for transport. To cite one case, in the evenings there are busses running at hourly intervals from 6 through 9. The operations dept does not have a clue as to how many people take the bus at 6 and how many take the bus at 9. As a result, there have been instances where the bus at 6 is half-filled while the bus at 9 is packed to the hilt.
My aim was not to point fingers at the administration of my own company. I understand that I am part of the problem and I am only ridiculing myself.
The point I am trying to make is: Do we really need to be obsessed about collecting data ? Do we also need to be discriminative about what kind of data to collect ? How do we use that data ? Does it end in charts and reports ? Or does it need to be chanellized into a decision-support system. If data cannot be used to make meaningful decisions, it should not be collected: is that a correct observation ?
Some of the above questions have obvious answers, some do not. There are also organizational obligations (maintaining and earning industry certifications, for example) that drive data collection initiatives and force the organization to go against the grain of logic. But where does this all take us ?
All operations are geared towards facilitating the data collection process -- how can I tweak my project management so I can get more data about the ..er...project management ? Status reports are prepared and shared quarterly, monthly, weekly, daily...There are whole applications developed internally whose sole purpose is to provide reports and charts --- to slice and dice data in a gazillion ways : how many projects did we complete last week where two or more people were involved where there were two Java developers and 1 DBA ....
And, these dashboard applications are getting more and more complex every day. With every change in leadership, there is a change in the specs on what kind of reports should be built. Every manager has his idea of the ideal report, the ideal chart.
You can only create charts and reports when you have data in the first place. So, off we go. We collect data day and night. There are groups whose sole purpose is to collect data about the projects we do, about our customers, about the revenue we make, about the business we won, about the business we lost, about the number of people who joined the company, about the number of people who left....it is endless.
For every 10 things that an employee does, at least two have to do with the process of either data collection or data reporting.
With so much data being collected, there are obvious compromises on the quality (accuracy and completion) of data being reported --- but that is a whole new story altogether.
But I also noticed one very funny thing. With so much data being collected, you would assume that everything that the company does would be measured. You would assume that the operations would be managed with precision. Atleast to some extent...
But no. I will cite two examples to make my point:
The place where I work has a canteen. Let us say, it can seat 200 people at full capacity. There are atleast 1500 people working in this office. Now, how would you manage this canteen at lunch-time (say 1 PM to 2 PM when most people would have lunch) ? You obviously cannot have everyone having lunch at the same time. And you cannot regulate by asking people on certain floors to have lunch at such and such time. This is typically when your decision suppport system would pitch in and provide an optimization-based solution. You would open up a seperate dining area in the building. You would perhaps consider serving lunch on the terrace. You could consider opening up lunch earlier than usual. You could vary pricing of lunch or availability of dishes so that the traffic is staggered.
The point is: if you had an inkling of which times the canteen is overpacked, you could plan better and provide better services.
The second example is of the company transport. The company provides to and fro conveyance to the employees at pre-scheduled times in the morning and evening. But, I have noticed (with great personal discomfort) that there is no pattern to the number of busses provided for transport. To cite one case, in the evenings there are busses running at hourly intervals from 6 through 9. The operations dept does not have a clue as to how many people take the bus at 6 and how many take the bus at 9. As a result, there have been instances where the bus at 6 is half-filled while the bus at 9 is packed to the hilt.
My aim was not to point fingers at the administration of my own company. I understand that I am part of the problem and I am only ridiculing myself.
The point I am trying to make is: Do we really need to be obsessed about collecting data ? Do we also need to be discriminative about what kind of data to collect ? How do we use that data ? Does it end in charts and reports ? Or does it need to be chanellized into a decision-support system. If data cannot be used to make meaningful decisions, it should not be collected: is that a correct observation ?
Some of the above questions have obvious answers, some do not. There are also organizational obligations (maintaining and earning industry certifications, for example) that drive data collection initiatives and force the organization to go against the grain of logic. But where does this all take us ?
Subscribe to:
Posts (Atom)