A team was stuck up with a programming problem, and so they reached out to the community for help. The moment I saw the mail for help, I whipped out my Komodo ( the editor that i use ), spent 10 minutes, and abracadabra, out came a beautifully written Ruby program. In no time, I was done .
Unfortunately, since the actual environment did not have ruby installed, I started rewriting this program in perl. Not only it took me agonizingly long time to write ( I have all but forgotten perl ), but i also found it very difficult to get down to writing a perl program, especially after writing one in Ruby.
In my opinion, writing a program in perl, after writing one in Ruby, is like driving an Ambassador car after driving a BMW.
Monday, September 10, 2007
Thursday, March 31, 2005
Simple is beautiful
Chats with Sailaja ( one of my friends ) are always very interesting. Not only you can converse on wide array of topics but you also get to learn a whole lot of new things. In one of those interesting discussions that I have with her, she sent me this nice little poem.
He drew a circle that shut me out
--Heretic, rebel, a thing to flout.
But Love and I had the wit to win:
We drew a circle that took him in!
"Outwitted" by Edwin Markham (complete poem)
This poem struck me. What a simple way to express such profound thoughts. The beauty of this poetry lies in its simplicity. Greatness lies in expressing complex things in a simple manner and not the other way around. And I actually think that this principle is very much applicable to software development.
Some of recent applications, that I have come across, have used dozens of classes to do something that should not have taken more than two. Use of patterns is good and is encouraged, but that has led programmers trying to crunch in whatever patterns they have learnt over the years in to one small little application. If not designing is a crime, over engineering is a bigger crime.
Test First Design is one of the activities suggested by XP. It is said that TFD helps in catching bugs, building up regression testing suites etc. Sure it does, but in my view, it achieves one greater thing, it helps restraining developers from over engineering their applications.
There is some good literature advocating simplicity:
* Refactoring to Patterns is a book by Joshua Kerievsky
He drew a circle that shut me out
--Heretic, rebel, a thing to flout.
But Love and I had the wit to win:
We drew a circle that took him in!
"Outwitted" by Edwin Markham (complete poem)
This poem struck me. What a simple way to express such profound thoughts. The beauty of this poetry lies in its simplicity. Greatness lies in expressing complex things in a simple manner and not the other way around. And I actually think that this principle is very much applicable to software development.
Some of recent applications, that I have come across, have used dozens of classes to do something that should not have taken more than two. Use of patterns is good and is encouraged, but that has led programmers trying to crunch in whatever patterns they have learnt over the years in to one small little application. If not designing is a crime, over engineering is a bigger crime.
Test First Design is one of the activities suggested by XP. It is said that TFD helps in catching bugs, building up regression testing suites etc. Sure it does, but in my view, it achieves one greater thing, it helps restraining developers from over engineering their applications.
There is some good literature advocating simplicity:
* Refactoring to Patterns is a book by Joshua Kerievsky
Mentoring - Some points
My journey, through the software world has been a long and a winding one. I have gathered bits and pieces of skills, through a process of great struggle, by spending long hours, by failing and falling and then getting up again.
So I felt that one of the ways that I can give something back to the software community was by mentoring / guiding someone. Helping someone to avoid the struggle that I had gone through.
This also complemented the idea of reuse (here reuse of experience). And then, Agile Methods very strongly recommended mentoring as a learning tool also.
My first few attempts at mentoring were greatly successful and I actually started imagining myself as a great Mentor. Then the disaster struck. My last attempt at mentoring turned out to be a total disaster. No matter what I tried, what I did, how much time I spent, nothing worked. Finally I had to abandon the project after 4 months of struggle and with huge loss of time invested. This thing has actually shaken my confidence so much that I guess this would be my last attempt at mentoring someone for some years to come.
But then I took some learning from the whole process and that is what finally counts.
* Mentoring is more than just passing of knowledge, it is passing of experience and this whole exercise is futile if either is not comfortable working with the other.
* Attitude is the most important attribute. Rest other things don’t matter as much. The person being guided should have willingness and interest towards learning. He / she should be ready to take efforts to extract learning out of the mentor and should be ready to work for it.
* Educational background does not matter, some of the best I have worked with had no computer science as a background, and some of the worst actually were from a comp science background.
* Choose the people you want to mentor carefully. Scan more on attitude and anything else. Not everybody can be mentored.
* What happens if the whole thing does not workout? Should you abandon or should you continue? I feel at this point once should try to put some process around the whole activity. The whole activity might not remain as mentoring, but at least the project might get completed.
This is where I feel Agile methods fail. It assumes the ideal situations and ideal people (programmers with great attitude and great aptitude). In reality such people are rare. I guess this is where I can see the birth of process heavy frameworks (ISO, CMM) from Deming’s original idea, which I felt were more agile in nature.
Being on a cynical side, Agile methods are for smart people and smart people are rare.
So I felt that one of the ways that I can give something back to the software community was by mentoring / guiding someone. Helping someone to avoid the struggle that I had gone through.
This also complemented the idea of reuse (here reuse of experience). And then, Agile Methods very strongly recommended mentoring as a learning tool also.
My first few attempts at mentoring were greatly successful and I actually started imagining myself as a great Mentor. Then the disaster struck. My last attempt at mentoring turned out to be a total disaster. No matter what I tried, what I did, how much time I spent, nothing worked. Finally I had to abandon the project after 4 months of struggle and with huge loss of time invested. This thing has actually shaken my confidence so much that I guess this would be my last attempt at mentoring someone for some years to come.
But then I took some learning from the whole process and that is what finally counts.
* Mentoring is more than just passing of knowledge, it is passing of experience and this whole exercise is futile if either is not comfortable working with the other.
* Attitude is the most important attribute. Rest other things don’t matter as much. The person being guided should have willingness and interest towards learning. He / she should be ready to take efforts to extract learning out of the mentor and should be ready to work for it.
* Educational background does not matter, some of the best I have worked with had no computer science as a background, and some of the worst actually were from a comp science background.
* Choose the people you want to mentor carefully. Scan more on attitude and anything else. Not everybody can be mentored.
* What happens if the whole thing does not workout? Should you abandon or should you continue? I feel at this point once should try to put some process around the whole activity. The whole activity might not remain as mentoring, but at least the project might get completed.
This is where I feel Agile methods fail. It assumes the ideal situations and ideal people (programmers with great attitude and great aptitude). In reality such people are rare. I guess this is where I can see the birth of process heavy frameworks (ISO, CMM) from Deming’s original idea, which I felt were more agile in nature.
Being on a cynical side, Agile methods are for smart people and smart people are rare.
Wednesday, March 16, 2005
Treasure House of Java Presentations
Javapolis conference is well know for having all the experts delivering talks. This time it was no different. To name a few delivered talks were Eric Gamma, Marc Fleury, Ron Jefferies, Martin Fowler and so on. The best part is all these presentation can be viewed online.
Here is the link for that
http://www.javalobby.org/av/javapolis/index.jsp
This might require registration into Javalobby user group.
Here is the link for that
http://www.javalobby.org/av/javapolis/index.jsp
This might require registration into Javalobby user group.
Monday, March 14, 2005
XP and Quality Frameworks ( CMM, ISO ..)
The traditional quality related frameworks (CMM, ISO ...) and Agile methods like Extreme Programming (XP, Scrum) have moved into opposite directions. One side trying to bring down the other. XP says that all the traditional processes are the root of all evil and cause of all the project failures, and on the other side quality gurus regards methodologies like XP as mere fads.
I agree that the quality frameworks have not really delivered what was expected of them, but then it is not that they have failed altogether. These processes still have a huge industry following and some of the quality certifications actually act as benchmarks in the software industry (CMM Level 5). By saying this, have suddenly undergone a total transformation and after trying to advocate XP for years have suddenly given up and started following the beaten path. Well, lovers of XP, you all can relax, no, I have not done that. What I am trying to show is that the path, a lot of XP gurus advocating (anti-quality, ISO and CMM bashing) will only harm XP in the long run. We should try to advocate that XP in no way goes against the Traditional quality paradigms. It in fact closely adheres to it and complements it.
During my journey through the CSQA certification, I noticed something very strange. At the core, principles of XP were in fact very similar to those that The Original Quality Gurus like Deming and Juran had advocated.
1. Improve quality by making small improvements in large quantities (XP - translates to rapid and continuous integration.)
2. Follow the Deming’s cycle - Plan, Do, Check, Act ( XP - A small design, Code a little, Test it fully, get the feedback and start again. Again continuous integration with continuous testing and rapid feedback. In fact the entire XP method can be seen as a slightly modified Deming’s Cycle).
3. Processes and Documentation. (XP - I here actually disagree XP’s view of documentation. Unlike what XP advocates, documentation inherently is an extremely important activity. Try transitioning an application which has no document and you’ll realize. However the problem with documentation is that usually it is not updated and it very rapidly becomes obsolete. This however is no excuse for not doing documentation at all. Some languages like python have actually taken a good step by integrating documentation right into code. )
So next time, u meet a quality guru, tell him that how by doing XP, we are truly following Deming and he will see us with more respect ( something that we deserve)
Tuesday, March 08, 2005
Some sites to learn Ruby
Continuing my current fascination for Ruby, I ll list down some of the sites that i used when i started of with Ruby.
Books / Tutorials
http://www.rubycentral.com/book/index.html
http://www.ruby-doc.org/docs/ProgrammingRuby/
www.pragmaticprogrammer.com
These should be enough to give u all a taste of Ruby.
Books / Tutorials
http://www.rubycentral.com/book/index.html
http://www.ruby-doc.org/docs/ProgrammingRuby/
www.pragmaticprogrammer.com
These should be enough to give u all a taste of Ruby.
Friday, March 04, 2005
Closures And Iterators
This is one of the best features that I like about Ruby (and believe me there are lots of them to choose from).
Here, one can pass a piece or a block of code to a method just like an arguement.
For Example :
There is a log file with log messages, messages in turn consists of comma separated fields.
Below, to analyse the logs better, I read the log file and then split each of the messages into separate tokens and then display them in a column.
IO.foreach("file") {line line.split(",").each() {token puts token.strip }
What, all this in just 1 line of Code. This is the beauty of Ruby. Java Geeks, try writing the same stuff in Java and see.
After so many years of programming in Java, i find programming in Ruby literaly liberating. I feel Ruby has given me wings to fly.
Here, one can pass a piece or a block of code to a method just like an arguement.
For Example :
There is a log file with log messages, messages in turn consists of comma separated fields.
Below, to analyse the logs better, I read the log file and then split each of the messages into separate tokens and then display them in a column.
IO.foreach("file") {line line.split(",").each() {token puts token.strip }
What, all this in just 1 line of Code. This is the beauty of Ruby. Java Geeks, try writing the same stuff in Java and see.
After so many years of programming in Java, i find programming in Ruby literaly liberating. I feel Ruby has given me wings to fly.
Tuesday, March 01, 2005
Gym and the Art of Programming
My Days at Bangalore ITPL Gym made me ponder over the similarities between pair programming and Weight Training. This comparison looks funny at the onset, but if you look at it carefully, it actually makes a lot of sense. We can actually transfer some of our learnings from a seemingly totally unrelated field to the art of software programming and agile methods. Let me outline some of the similarities below
1. Weight training is best done in pairs.
2. Weight Training, when done alone, has some serious shortcomings.
- The lifting techniques are usually not proper because there is none to constantly review and correct the lifts
- There is always a tendency to relax a bit, and not stretch oneself to the limit. This is one of the major reasons for not getting proper results.
- There is always a bigger risk of getting injured
3. Lifting in pairs and alternating with the weights tends to make the whole workout much more interesting and enjoyable.
4. When pairs train with each other, they tend to learn from each other.
5. Pairs can be of any combination: expert-expert, expert-novice, and novice-novice. The first two are more desirable. On the whole the though, productivity depends on the attitude of each of the lifters and also how they get along with each other.
6. There is nothing like a trainer to assist you now and then.
Now for the learnings that can be taken an utilized to make programming a better experience
1. Accept it or not, programming in pair with constant review and feedback is not only more productive and more enjoyable, but the programmers tend to learn and refine their skills faster.
2 I also do not accept that pair programming is always beneficial. It ultimately depends on the individual programmers. In an expert-novice pair, the novice is not going to improve if he has no interest / attitude for learning. Pair programming assumes ideal programmers (who have good skills, and have the right attitude to learn). This is usually not the case and thus pair programming might not always succeed just as an incompatible pair might have a disastrous workout.
1. Weight training is best done in pairs.
2. Weight Training, when done alone, has some serious shortcomings.
- The lifting techniques are usually not proper because there is none to constantly review and correct the lifts
- There is always a tendency to relax a bit, and not stretch oneself to the limit. This is one of the major reasons for not getting proper results.
- There is always a bigger risk of getting injured
3. Lifting in pairs and alternating with the weights tends to make the whole workout much more interesting and enjoyable.
4. When pairs train with each other, they tend to learn from each other.
5. Pairs can be of any combination: expert-expert, expert-novice, and novice-novice. The first two are more desirable. On the whole the though, productivity depends on the attitude of each of the lifters and also how they get along with each other.
6. There is nothing like a trainer to assist you now and then.
Now for the learnings that can be taken an utilized to make programming a better experience
1. Accept it or not, programming in pair with constant review and feedback is not only more productive and more enjoyable, but the programmers tend to learn and refine their skills faster.
2 I also do not accept that pair programming is always beneficial. It ultimately depends on the individual programmers. In an expert-novice pair, the novice is not going to improve if he has no interest / attitude for learning. Pair programming assumes ideal programmers (who have good skills, and have the right attitude to learn). This is usually not the case and thus pair programming might not always succeed just as an incompatible pair might have a disastrous workout.
Subscribe to:
Posts (Atom)
