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.