Summarizing Mishkin Berteig list of “The Wisdom of Teams - Generalizing Specialists”:

• Backups Team always has a backup specialist, if the assigned one is away, sick, or was hit by a bus.
• Skills Every human being has an incredible capacity for learning. And even more - most of us like to learn new things. By learning even something unrelated to my current major activity, I discover something common and something new that I can bring to happy software development.
• Rules By agreeing explicitly on the expectations inside a team, the team improves cohesion and lowers tension. Better relationships - better software.
• Management Much less management is necessary for such team. In fact, the only real management is necessary is setting up/discussing goals from long term (years?) to short term (end of the week or today) and just giving the team the resources they need. “What can I do for you, team?”

No Comments »

Software development and teaching it requires something more than a one pair of eyes to watch the code.

Essentially, the software development process is the process of translation from customer’s ideas down to code done collectively. That’s why code should be written more for reading by other people than for computer execution.

Unfortunatelly, our teaching system and existing developers rarely seem to understand this simple idea. At least, not until they will try to read and get some oldish perl code like this:

sub makesmblock { my($isblock2,@mh)=@_; my ($smi,$xmnum);  $xmnum=1;
foreach $xbit(@mh) { ($bit,$fpnum)=split(/\і/,trim($xbit)); if($bit) {
#print "$bit<br /><br />";
if(($fpnum==1 && !($nocf)) || ($fpnum==1 && ($PROCESS{'domode'} || $PROCESS{try})&& !($ori_ha{'notrycontactform'}))){$bit.=qq~\|$transm41\|$my_http\?cf=3$ltag$vtag~; }
if(($fpnum==1 && $sitemap==2 && !($nosm)) || ($fpnum==1 && ($PROCESS{’domode’} || $PROCESS{try})&& !($ori_ha{’notrysitemap’}))){$bit.=qq~\|$transm39\|$my_http\?sm=3$ltag$vtag~; }

(real code from real product)

Systematic code review is possible either by

• scheduled real-life code reviews
• pair development
• distributed code review

Scheduled meetings with the only purpose of code review is a no-no in our software development team. As well, as in any team that doesn’t sit in a single office, I guess. Pair development is equally hard for geographically distributed team. Thus, we are left with only one option of distributed code review.

We are using trac for our project management for years with great success. That’s why I, naturally, tried to use trac peer review plugin.

No way

Given latest stable trac 0.10.3 you get html parse errors (#1035) due to crappy html, generated by plugin.

And even after you mask those errors with patch, you discover another defect (#938) that makes impossible to use this plugin at all.

Looks like its time to look for an external code review system. At least until someone fixes (rewrites) PeerReviewPlugin or writes another one.

No Comments »