I met the lads from Goldfish while in Cape Town earlier in the year. Expect to see them coming to a radio station/festival near you soon.

"If programmers got paid to remove code from sofware instead of writing new code, software would be a whole lot better." - Nicholas Negroponte Billy Hollis warns of the danger of software addiction;

Object Mentor : "If you are working in an Agile team, don't feel guilty about taking a day or two to think some issues through. Indeed, feel guilty if you don't take a little time to think things through. "

Quality Assurance in software development, is not the sole responsibility any one team, yet the structure (and project schedules) of many organizations makes the Test team, in particular, "accountable".

The net effect is you end up with strange beliefs that "not letting developers talk to testers" will improve the quality of the software product. What gives?

At what point did we lose the plot?

Fortunately, there's some smart folks out there who realize there's a better way. Competitive software companies nowadays are doing some interesting things;

  * Building & Testing what the customer actually wants (BDD, Agile Specs

  * Not wasting time (and money) on stuff that's not important. (MMF, Getting Real)

  * Automating things instead of doing them by hand. (Like testing!)

  * Training people how to write Code That's Easy to Test (the Pragmatic Programmer)

  * Training people how to write tests for that same code (cmon, this is basic QA people! Educate your developers.)

  * Training people to write & run those tests before they write any code (e.g. BDD/TDD/XP )

  * Isolating bugs when they are introduced, not 6 months later (Continuous Integration) And last but not least;

  * Responsibility, accountability and pride your own/team's work. (Leadership, Software Craftmanship, SCRUM)

Easier said than done, yes, but its not rocket surgery.

 

I've been a user of the "Password Gorilla":http://www.fpx.de/fp/Software/Gorilla/ (I use OS X) with an automatic backup of its (encrypted) password database with "DropBox":http://www.getdropbox.com/ . (Kudos to "Joel S":http://www.joelonsoftware.com/items/2008/09/11b.html for this idea)

I'm not a great fan of Password Gorilla's (PwG) UI, and am tempted to go to a purely OSX app. But being a Java app, I do like the ability to install/run PwG on a windoze box at short notice if the fit does ever hit the shan.

Another issue for me is the encryption strength of the PwG database. I read of several users syncing TrueCrypt volumes to DropBox instead, which is a damn fine idea. Any suggestions for a multi-patform PwG-clone with a better UI / encryption ?

Welcome To Australia

h4. Mozilla visiting Macedonia Announcing: "MECT":https://wiki.mozilla.org/MECT coming to Skopje on the 14-16 April. Technical workshops include "firefox for web developers, the open web, standards compliant browser, HTML 5, the new js engine, new css features"

As a developer, you might want to ask yourself why Pair Programming is something you should be bothered doing? "Jeff Langr suggests the following;":http://langrsoft.com/articles/pairing.shtml * Awareness of other parts of the system * Resume building * Decreases time spent in review meetings * Continuous education. As someone who thinks he is a pretty hot programmer, I still learn new things every day from even the most junior programmers. * Provides the ability to move between teams. ("this team is boring," "I can't stand working with him," "that stuff they're doing looks cool."). Since this can be a benefit for management as well, they don't have to clamp down on their resources. * More rapid learning as a new hire. You don't sit and read out-of-date manuals for a week, or worry that you're going to be fired because the system looks indecipherable. If you want some out-of-date manuals to read, I have a couple lying around that I don't use anymore. Me, Im too busy Pair Programming to read em.

Here are some notes based on "Jay Fields article on Pair Programming":http://www.infoq.com/articles/adopting-pair-programming h4. Goals * team enjoys pairing * more productive * team building * efficiency * knowledge sharing * better code quality h4. Methods * 60-95% of core working day * no-one advocates 100% * Only production code written by pairs (XP) h4. Pairing Stations * flat, long desks * 2 ppl comfortably * fast machine * 2 x 24" or 2 x 30" monitors * 2 keyboards & 2 mice * uber chairs * create an environment >= working on own computer h4. Tools * use best-of-breed tools (vi/textmate or whatever) * iterate - find your sweet spot * image for quick deployment * re-image regularly ** encourage dev's to add tools to the image h4. Pair Switching * benefits ** shared expertise (tools/domain/patterns/testing etc) ** balance learning & mentoring * min 1 day * max 2 days * alternatives ** once per iteration ** promiscuous pairing h4. Driving * Ping pong programming * Mentor ** teach Learner to fish * Learner ** take control ** discuss / understand / implement / learn * m,l = l,m ** roles can swap! h4. Anti-Patterns * Uninterested Pair ** not talking. * Distracted Pair ** Helping others ** Checking email ** ancillary tasks * Spellchecking Pair ** Large experience gap ** time pressure ** 1 person reduced to spellchecking ** cannot bridge gap & deliver - split h4. Dont pair when * Some things can be better done on own E.g. ** Research ** Spiking ** Debugging (when large experience gap) ** Doco ** Admin chores h4. Managing * don't force to pair * pair properly, see if they prefer * opposing views ok ** but intra-team they should agree