Understand your manoeuvre

Below is my free translation of Alexei Kapterev’s (website and blog) blog post about understanding ones goals and purpose.

---

‘Understand your manoeuvre’ by Alexei Kapterev
Suvorov once said – “Every soldier should understand his manoeuvre”. He didn’t address soldiers, but officers, who were ought to explain the manoeuvre to soldiers. In real life, very few soldiers really wanted to understand own manoeuvre. They didn’t care about it’s goal, they cared… not to die. Understanding the goal didn’t help in this. On the contrary, understanding it led to realisation of own inevitable death. This demotivated, sometimes very much.

Can software metrics measure it?

Bumped into an InfoWorld article by Neil McAllister on software development metrics. Good questions raised:

Code metrics are fine if all you care about is raw code production.

Do your metrics take into account time spent refactoring or documenting existing code?

Are developers who take time to train and mentor other teams about the latest code changes considered less productive than ones who stay heads-down at their desks and never reach out to their peers?

And can metrics account for productivity sinks related to unforeseen circumstances? What about code that grows longer and ever more convoluted due to scope creep — how is productivity measured then?

What about code that is functional, high-quality, and delivered on time, but doesn’t do what it’s supposed to do because of simple miscommunication?

How well do the metrics account for delays due to budget shortfalls, bugs in tools or platforms, unmet dependencies from other groups, or dysfunctional processes?

Be sure to check the article and linked content in it

Lessons learned from RST Management

I’ve been lucky, once again, to get to James Bach‘s course, this time Rapid Software Testing Management. As with average RST, this one is also developed with Michael Bolton and Michael has a description for it. Though, of course, presenters are different and courses are not the same – they’re similar.

Overall, this course fits well with Agile, has lots of common sense and is very influential. In fact, Scrum’s standups idea was taken from Borland (as per Jim Coplien) and James told it was their project and his idea to do those. Similarly, in Borland testers worked closely with developers and practised thing XP and Scrum practitioners started promoting in late 90s.

Class was started with questions from the public – we wrote down the topics we had questions for and started digging into those. As with usual RST, James asked tricky questions and questioned our answers. He told interesting and instructive stories from his times in Apple, Borland and for now Satisfice. In addition, he had things to share from eBay, where his brother Jon Bach is a QE director.

I noticed those who didn’t attended RST course previously or weren’t active in Context-Driven/RST community, were easier to get into traps. RSTeers almost never asked directly and had questions for additional information. RST course makes you smarter. One must understand it’s a must to be passionate on problem solving, be an independent and open-minded thinker to ask tricky questions and have courage to act to succeed with RST.

Below are notes I made for myself. This is a mix of my learnings and (most part) course materials.

Bad estimation – it’s information!

Got onto Mike Cottmeyer’s article ‘The Real Reason We Estimate’ via XP Injection and couldn’t agree more. We often do underestimate, and reason is not that estimation as activity is broken, but that oracles we make our estimation upon are not informative enough.

Instead of skipping estimation, we should analyse why it’s failing and improve those areas.

Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem.

Shared understanding problems can result from any number of organizational dysfunction’s. Some of the most common are on the product side… insufficient business involvement, insufficient understanding of the business problem

The other big shared understanding problem comes from technical debt… poor architecture, quality problems, or even just teams that are unfamiliar with the code base

You really should read the article in full

100% test coverage

Recenlty there was a good tweet exchange between James Bach, Michael Bolton and Ben Simon on “100% coverage”. Good point worth writing down:

“100% test coverage” is a standard that lacks a standard. Might as well demand 100% pure programming. 100% of what? ‘code’ is an ambiguous denominator. Even if lines, branches and paths were finite, data isn’t.

Testing requires heuristic choices. 100% *check* coverage is a much smaller (infinite) set than 100% *test* coverage. This is a very important difference… unless you believe that the only important thing about a product is “100% functional correctness of the code you wrote”.

100% check/test coverage still does not save from buggy software.

Scrum Master role description

As a fresh scrum master missing my responsibilites description, I though I could compile one myself. I searched the web, made some notes from books and courses, and voilà. As this is done on free time and for personal use, I see it could be usefull up here in the web for others SMs too.

Support team members

• prevent distractions, identify and lead impediments solving process, escalate problems if needed
• help team to keep focus on results and commitments
• assist team with making appropriate commitments by challenging story selection and assuring everything is clear and understood same way by both sides
• be a single point of contact for external communication to the team
• communicate team velocity and sprint/release progress , be co-responsible for commitment delivery
• influence self-management and self-improvement to grow efficiency and velocity

Support business

• assist product owner with backlog maintenance . Assure top PBIs meet DoR
• ensure the team is focusing on high priority items and feels accountable for the product
• ensure visibility of the team’s velocity & sprint/release progress by leading improvment of transparency and quality of information radiators
• facilitate grooming, sprint and release planning sessions, daily standups, sprint demos and retrospectives

Support process improvement

• co-develop motivatinal, transparent, collaborative, open and trustful environment where Scrum team can work efficiently and business can deliver fast changes to a fast changing world
• instigate change, open mind thinking and honest discussions
• challenge and facilitate discussions on conflicting matters keeping those in productive and improving direction
• ensure improvement by constant attentive retrospective process and root cause analysis
• coach and educate team and product owner to practice core scrum principles and understand scrum/agile values

Last updated: 17 June 2011

/alertsoff

Recently I watched a TED on why work doesn’t happen in the office – “Jason Fried has a radical theory of working: that the office isn’t a good place to do it. At TEDxMidwest, he lays out the main problems (call them the M&Ms – mangers and meetings) and offers three suggestions to make work work.”

Jason suggests to avoid meetings and to invite as little people as possible when they are really needed. He also promotes to use IM and e-mail instead of direct communication to avoid distractions.

My experience tells that using IM and e-mail doesn’t help at all – you need to configure them very well. Otherwise you’ll miss important information and/or drown in notifications. On my previous workplace most of communication was done via e-mail and you had new mail notification few times per hour. I had to setup about a dosen filters to catch important mails and mute unimportant ones into different folders.

At the moment I only filter and silence VCS update mails as my present communication is done via Skype. And it is was too very annoyning. This TED inspired me to mark 99% of my Skype chats with /alertsoff which will mute all their sound and tray notifications. You’ll be able to see updated chats in ‘Recent’ list and you’ll read them when YOU are ready. Bye bye, annoying tray counter. After one month of using it I’m very very happy with this solution. Also, it’s a must have for vacation.

While e-mail and skype are good – direct communication is very important, especially in agile environment. But one should be really carefull not to annoy others and not to ruin one’s productivty flow. Just as Jason marked – I stay at home to do important things fast.

In my open space environment distractions are real problems for me – someone speaking very loudly, people walking behind my back, people chatting in the kitchen 5m away or even having a standup meeting there. I can runaway into a meeting room, but own table is still the best place for work. This is one of the reasons why I get in the office at twelve – you are in an empty office after 6 and can work happily.

To conclude, be reasonable and kind in open office space

Lessons learned from James Bach

Recently I was lucky enough to attend a full 3 day Rapid Software Testing course by James Bach himself. After the course I can say that course’s second name should be

• how to clear out communication, avoid false assumptions and activities based on false assumptions
• how to act good and avoid saying things you shouldn’t say
• how to avoid waste and lead work in productive  direction
• all this under peer and time pressure

According to James, it really is his goal to put participants think thoroughly before they act and to learn them not to fall for communication and logic traps.

This course would be useful not only to testers, but project managers, engineers and analysts too – all the people who have to make decision based on requirements and personal assumptions on this data. Moreover, James puts up nicely what testing is, what activities it consists of, and believe me – there are lots of hard, intellectual processes involved.

I can definitely say that it was very interesting to listen and observe – James speaks very good, he could become a good actor The course itself is interesting too – participants are asked lots of obvious, for a first look, questions and answer obvious answers, often while doing exercises. Then James comes in with his questions and you realise you acted on wrong assumption and didn’t communicate well – you fell into a trap. You will realise how some obvious things are very complicated and how this complications can be easily avoided.

On the first two days you will learn about assumptions, how to avoid giving poor answers and avoid answering inappropriate questions at all. The last day was the most interesting – you will learn about exploratory testing technique and methods. You will hear stories and advices on documentation, automation and team work.

On the first thought I had mixed feelings on the course and was thinking that I didn’t learn anything useful that would change how I test things. But as two weeks passed, I realised that the course made me a whole better man (not only a tester) and things I’ve heard are still being processed somewhere in background of my mind. James’ bio and attitude alone motivate to become a better tester, better speaker, to be more proactive person. And hey, I’ve started blogging again thanks to it!

So if you’ll have a chance to take part of the course – go for it!

CHDK install on ubuntu linux

NB! everything you do is done on your own risk and I don’t  bear any responsibility on possible damage

CHDK (Canon Hack Development Kit) is a neat way to extend functionality of your pocket digital Canon camera. You can read more on the project wiki. This guide is done for personal reference and should be treated as such. Based on CHDK FAQ and bootable card manual.

Steps:

1. insert memory card into the reader
2. open terminal and execute

   sudo dmesg

3. in the output you’ll see

   [82219.970240] mmc0: new high speed SDHC card at address 97b6
   [82219.975070] mmcblk0: mmc0:97b6 SD08G 7.42 GiB
   [82219.975167]  mmcblk0: p1

   Where mmcblk0 is the device name for MeMoryCard

4. run GParted in the terminal:

   sudo gparted /dev/mmcblk0

5. in GParted unmount the memory card: select partition, right click -> unmount
6. delete the partition from the card
7. create new FAT16 partition with size of 16Mb and label it as chdk
8. create new FAT32 partition on free space and label it canon
9. apply changes
10. Close GParted when
11. unmount the card (if needed), This time from desktop icons
12. remove and insert the card into the card reader
13. Determine partitions’ devices, run sudo dmesg command again
    you’ll see

    20593.542629]  mmcblk0: p1 p2

    where p1 and p2 are ids of new partitions. So the device of chdk partition is /dev/mmcblk0p1

14. Unmount the partitions (from the desktop)
15. make card’s first, chdk, partition bootable: open terminal and run following command combination

    echo -n BOOTDISK | sudo dd bs=1 count=8 seek=64 of=/dev/mmcblk0p1

16. mount the partitions again by removing and inserting the card into the card reader
17. find out the version of you firmaware
18. find the firmware you need, download and unpack it
19. copy Diskboot.bin to chdk partition and CHDK folder to the FAT32 canon partition
20. unmount the card, make it write protected by pulling the trigger on the card itself
21. insert the card in the camera and enjoy CHDK

So thats about it, you can find more info on the project wiki. Feel free to comment and share you experience

Useful mencoder commands

A note to self kind of post – useful mencoder commands to

1) convert huge digicam concert (and not only) videos to smaller ones
mencoder -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=2200:vhq:keyint=50 -oac mp3lame /media/ixus870/DCIM/120CANON/MVI_5241.MOV -o 3.avi

bonus – do this massivly:
#!/bin/bash

cd /media/ixus870/DCIM/120CANON

i=0
for file in *.MOV ; do
let i++
mencoder -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=2200:vhq:keyint=50 -oac mp3lame /media/ixus870/DCIM/120CANON/$file -o /home/ssergeje/$i.avi
done

2) merge several videos into one
mencoder -ovc copy -oac mp3lame  MVI_4675.MOV MVI_4676.MOV MVI_4677.MOV -o frontline.avi

3) split one video into two (00:08:01 and 00:07:45 is hh:mm:ss)
mencoder -endpos 00:08:01 -ovc copy -oac copy big_video.avi -o first_part.avi
mencoder -ss 00:07:45 -oac copy -ovc copy big_video.avi -o second_part.avi

You can check out my youtube channel here.