A quick note on an argument that may be obvious, but I never run through until today.
The advanced for loop (the for(Type t : Collection) form), introduced in Java 5 doesn't check for null collections. What this means is that if you pass to your loop a null collection (possible, when you don't have total control on the arguments that are passed to your method), the for loop will throw a NullPointerException. This is a correct behavior, since usually you don't want to consider in the same way null collections and empty collections, but can be a source of errors (possibly runtime errors...) if you don't take care of null values by yourself.
mercoledì 17 dicembre 2008
mercoledì 10 dicembre 2008
Two hearts are better that one...
A technique we are using these day, along side with the Pomodoro techinque time boxing, is Pair Programming, even if we are using it in a very unstructured way. As with every agile programming technique, this one revealed its usefulness, but has some 'dark corners'. What is Pair Programming ? Essentially it's just two people working togheter on a single workstation, sharing a single keyboard: one programmer (the driver) write the code, the other (the observer) review the code, trying to find out potential problems, bugs, bad code or thinking about possible improvements in code or design.
Some researches and studies have proven that pair programming reduce bugs of about 50%, with about a 15% cost increase (which is good, as bug fixing is much more costly if done at a later time, maybe by a developer who does't know the code...). A nice side effect is just that code and design decisions become shared among the team (at least two persons...), reducing the management risk (no programmer is a bottleneck, being the only one to know critical parts of the system, anymore...). There are obviously other benefits, like training on the job for less experienced developers, less distractions, better design and coding due to double knowledge and experiences...
Along with all these benefits, there are some drawback (as usual...).
According to the tries we are doing we saw that not all activities are good for pair programming. For example, there are some jobs that would be made exactly in the same way by both developers (as a result of common experiences), where the design is well known and the code quite consolidate, or some repetitive tasks. In this case the bugs are naturally few, and are quite easy to resolve. So, the contribution of the observer is quite low. The risk is to bring some boredom to the pair, and the attention in the long term is reduced by the pair practice instead of increased.
Another important thing to remark, which is not always kept in the right consideration, is that not all developers like to work for the whole day in pair. Some developers like to work alone, at least for some time, when trying some new technology or when doing some common task.
Another thing to think about is how to apply pair programming along with the pomodoro technique. Working for 20 / 25 minutes side by side brings the natural question of how to organize the work: for example is good to make an advance design, shared by the two, before writing the code ? Or is better for a developer to start coding while explaining his point, and then to review the design together ? Or every developer must try to prove that his design is good before starting ? All these approaches can lead to good results or to bad results.
In the next days we will try to use some of these approaches and to find out which ones work better for our project, a first pace in the road to agility.
Some researches and studies have proven that pair programming reduce bugs of about 50%, with about a 15% cost increase (which is good, as bug fixing is much more costly if done at a later time, maybe by a developer who does't know the code...). A nice side effect is just that code and design decisions become shared among the team (at least two persons...), reducing the management risk (no programmer is a bottleneck, being the only one to know critical parts of the system, anymore...). There are obviously other benefits, like training on the job for less experienced developers, less distractions, better design and coding due to double knowledge and experiences...
Along with all these benefits, there are some drawback (as usual...).
According to the tries we are doing we saw that not all activities are good for pair programming. For example, there are some jobs that would be made exactly in the same way by both developers (as a result of common experiences), where the design is well known and the code quite consolidate, or some repetitive tasks. In this case the bugs are naturally few, and are quite easy to resolve. So, the contribution of the observer is quite low. The risk is to bring some boredom to the pair, and the attention in the long term is reduced by the pair practice instead of increased.
Another important thing to remark, which is not always kept in the right consideration, is that not all developers like to work for the whole day in pair. Some developers like to work alone, at least for some time, when trying some new technology or when doing some common task.
Another thing to think about is how to apply pair programming along with the pomodoro technique. Working for 20 / 25 minutes side by side brings the natural question of how to organize the work: for example is good to make an advance design, shared by the two, before writing the code ? Or is better for a developer to start coding while explaining his point, and then to review the design together ? Or every developer must try to prove that his design is good before starting ? All these approaches can lead to good results or to bad results.
In the next days we will try to use some of these approaches and to find out which ones work better for our project, a first pace in the road to agility.
Iscriviti a:
Post (Atom)
