I am working for a multi-national company. I was told that a project for Ministry of public credit, Bogota, Colombia. (Yes, in South America!)is in deep red and I may have to travel to onsite for the project.
I had no clue about the project and no idea about the location. As usual, I powered on my computer and started searching about Colombia. At the end of the search I got a reply that was good and bad.
But I could more or less summarise it like this.
- It is a country where drug trafficing and kidnappings are more than any other part of the world.
- It is not safe to walk around on the roads after 8PM or so.
- Cost of living is not too high.
- It is safe to live only in zones 5 or 6.
- Technology is not so advanced (Like mobiles, broadband etc)
- The language spoken is Spanish
- You must book a cab and should not take a cab just by waving hands on the road
The only convincing part, I read in almost all the sites, was that the country has improved a lot in the last 2 years and the crime rate is lesser than some other popular cities in the world.
I should also list the good things that I came across about Bogota, Colombia.
- Rice is a staple diet.
- You get vegetarian food (ask for "arroz con ensalada")
- Weather is always between 18 deg celcius and 22 deg celcius all through the year
- People are kind (?!?)
Ok. I need to pack my bags now!
Friday, 28 December 2007
Saturday, 20 October 2007
Collage Machine
I came across a very nice piece of software over the internet... It is really fun using this software. Check it out...
http://www.pentacom.jp/soft/ex/collage/collage.html
http://www.pentacom.jp/soft/ex/collage/collage.html
Wednesday, 22 August 2007
Agile Alternative
Can agile development methodology be an alternative to the problem? The answer is yes and no.
Whenever I think of agile I see it as a development methodology where the documentation part is missing. May be I am entirely wrong here. It is perhaps my perception that the knowledge does not get documented anywhere. If a team successfully built a rocket and launched it and if a new team is asked to build it again, it becomes difficult if agile development was followed in the first place. According to my understanding, the knowledge that was built over time is not documented anywhere so that it can be used to do the task effectively the second time.
It is perceived that the agile methodology does not allow Bangaloring (a k a outsourcing). But my strong feeling is that it is possible to offshore work even while following agile methodology. There are tools available in the market that helps organisations and projects to have the best of both worlds (I mean agile and offshoring).
The best part is users can see the software getting built in front of their eyes and change the requirements on the fly. This means that the user gets what he/she wants. Does this somewhat resemble the construction engineering industry?
Yes. It does. But then why most software projects are behind schedule and do not meet user expectations?
The reason could be…
Saturday, 4 August 2007
Software "Construction"
Anybody building a $300,000 house will not start the work without discussing the needs and desires with the construction contractor. Everyone understands that making a change mid-way during construction is very expensive. Is this understood for the construction of the software? Is the same principle applicable for software?
Sometimes I wonder how it would have been when no one understood the science behind the construction industry and how the requirements specified were translated into reality?
Did anyone understand the numbers and arrows in a building blue print? To explain a bigger and complicated plan, the blue print would have been accompanied by a miniature model. As the construction industry became popular, the general awareness about reading the plan and understanding the construction engineer's language became easier. Today, the building requirements are specified by the user in the most technical terms understood by the engineer (perhaps this made the construction engineer community feel nothing special about their job!!!). When the engineer produces the estimates and the type of work he is going to do, the user agrees and is able to visualize the end product. All the more, the user will be able to see it getting constructed physically!
In the software industry, the user does not have an understanding of the software task when it is being done and there is nothing visible for measuring the progress. It is a logical development activity. It cannot be seen or realized till it comes to a point where there is no flaw in it (after a stage where the development and testing are all over). To cater to this need and to foster customer satisfaction, there are different methodologies being developed and the software development process is also running with a 'science' behind the scenes. But for the user to understand this science and come to a level where they can specify the requirements in plain software terminology will take a while. But we are not that far from that (will the software engineers then lose the pride that they carry now?). Since there is a gap in the way requirements are specified and the way it can be interpreted by the development team, we are in a position to define the standards and clearly identify responsibility. The responsibility of setting the standards lies with the standards group and is doing its job well. It is in the hands of the development team to interpret the requirement in the same way as the business looks at it.
This is possible only if the development team replays what their interpretations are. This can be achieved through walkthroughs. In places where the walkthroughs are not possible, it is possible to send out a diagrammatic representation of the understanding of the business process helps. This is where the tools (thanks to Microsoft Visio and other visual modelling tools) come into play. These tools represent the business entities and other business process flow with a standardized set of symbols (this is the outcome of the job well done by the standards group). But the development team has done a great job that is gobbledygook for the business community.
The alternative is…
Sometimes I wonder how it would have been when no one understood the science behind the construction industry and how the requirements specified were translated into reality?
Did anyone understand the numbers and arrows in a building blue print? To explain a bigger and complicated plan, the blue print would have been accompanied by a miniature model. As the construction industry became popular, the general awareness about reading the plan and understanding the construction engineer's language became easier. Today, the building requirements are specified by the user in the most technical terms understood by the engineer (perhaps this made the construction engineer community feel nothing special about their job!!!). When the engineer produces the estimates and the type of work he is going to do, the user agrees and is able to visualize the end product. All the more, the user will be able to see it getting constructed physically!
In the software industry, the user does not have an understanding of the software task when it is being done and there is nothing visible for measuring the progress. It is a logical development activity. It cannot be seen or realized till it comes to a point where there is no flaw in it (after a stage where the development and testing are all over). To cater to this need and to foster customer satisfaction, there are different methodologies being developed and the software development process is also running with a 'science' behind the scenes. But for the user to understand this science and come to a level where they can specify the requirements in plain software terminology will take a while. But we are not that far from that (will the software engineers then lose the pride that they carry now?). Since there is a gap in the way requirements are specified and the way it can be interpreted by the development team, we are in a position to define the standards and clearly identify responsibility. The responsibility of setting the standards lies with the standards group and is doing its job well. It is in the hands of the development team to interpret the requirement in the same way as the business looks at it.
This is possible only if the development team replays what their interpretations are. This can be achieved through walkthroughs. In places where the walkthroughs are not possible, it is possible to send out a diagrammatic representation of the understanding of the business process helps. This is where the tools (thanks to Microsoft Visio and other visual modelling tools) come into play. These tools represent the business entities and other business process flow with a standardized set of symbols (this is the outcome of the job well done by the standards group). But the development team has done a great job that is gobbledygook for the business community.
The alternative is…
Subscribe to:
Posts (Atom)
