The path of knowledge

There was a curious thing my study partner said to me last year “I don't seem to be able to study like I used to when I was a teenager”.

I was on study leave myself at the time, and in a way was feeling the same thing.  I was working through a couple of textbooks – and found my process quite painfully slow.

Make no bones about it – self-study is hard.

But faced with a textbook we're all kind of guilty of trying to race to the finish.  Like knowledge is some kind of timed event.

We're also guilty of applying the worst kind of rose-coloured glasses when it comes to our school.  Few of us remember how bored we were in some classes, and how repetitive it was.

Fortunately I worked as a teacher, which gave me a different perspective.  And looking back, I think we learned a lot slower than we'd thing.

Teaching my class, we'd use a textbook as the basis of a lesson – introduce the topic, expand the ideas (sometimes building on another topic from last week), discuss them with students, maybe do a little bit of experimentation, then write them in a book.

All in all we'd perhaps cover the whole book over the period of a year, perhaps covering 2-4 pages an hour.  It's not the breakneck speed you'd think looking back.

And repetition was part of the key – I'd explain about a principle, we'd do an experiment about the principle, then we'd write the principle down.  So we'd go over the same piece of knowledge about 3 times in different ways so it would “stick”.

This is how we learn.  It's not about just reading new ideas, and going with them.  It's about looking at a new idea, examining your old ideas, and trying to build these new ideas on top/integrating with the old ones.

Something so complex mentally we can only take small bites at a time.  It's like watching a child develop.  When my son was born I thought he'd be crawling in weeks – didn't know what babies were like.

There's a chain of learning that goes on, where they develop new skills which expand what they can do.  They start out being about to do very little, just fragile.  But they develop the ability to move their limbs as they want to, they build up stomach muscles to allow them to sit up, they develop the ability to wriggle their legs, which eventually becomes crawling, which then becomes toddling, then they can walk, then they can run.

That's the sequence, and it takes over a year, and you can't “skip” a bit and just get to the walking – each ability is dependant on building the previous ability.  It's a kind of iterative piece of development.

The fascinating thing about babies as well is watching them develop and learn.  They learn as much from error what's not possible as from their successes.  But they're not afraid.  As adults we're terrified of failure to ridiculous levels, even though it offers us to learn from those mistakes and “do better”.

So what am I saying?  When it comes to education, it's a way of life, not a race, don't feel the need to put your "foot on the gas".  Try and learn just "a thing" a day, and build on it.  It's the way of successful learning.

Oh and don't be afraid to ask questions and try out the knowledge.  If you've got it wrong, it's best to kind of thing out your misconceptions early.

When “done” doesn't mean “ready”

Picking up a bit from yesterdays lament how in some companies the “unit test” is becoming a dying art on some software projects.

My original feeling – having worked on two projects now which called themselves “Agile” - was that Agile was a dangerous methodology indeed.  Many developers were building a kind of Kanban board with areas to show phases of development which included “Not started”, “Design”, “Coding”, “Done”.

And away they'd report to the project manager “oh yes this module is DONE”.  And so the project manager would come over to me as head of testing and it'd feel like we were put on the spot.

Because the developers version of “done” meant “finished writing coding” - it did not mean “unit tested”, “integrated into test environment” or even “ready for system testing”.


[It took Lisa Crispins book on Agile Testing to teach me that the aim of Agile development was to “bake in testing” and to test early and often]

I know from my own experience that code is just a lot of strange punctuation until you try and make it do something.  Saying code is “done” without executing it (ie testing) is like making a new recipe for a cake, baking it, but not really eating it to see if it's any good.

Mmmm – delicious cake!

I think one of the problems is Agile encourages people to adopt a “framework” and not a “rigid process”, and it means some people who say they're adopting Agile are really perhaps cutting things too far.

The way I see it – you have a process in place, and you have to look through it, and work out which elements add value, and need to be kept, and which are just unneeded overhead which add nothing.  And whatever we're using - Waterfall or Agile we need to be sure to try and strip down what we do, but be vigilant to keep the things that are adding value.

It would be a brave developer to tell me that testing does not add value to code, or that unit tests have never shown problems the developer did not foresee.


So developers beware – whether it's “Agile”, “waterfall” or “v-model”, your code is not “done” until it's “tested” ...


Erm not that I see developers as "the enemy", I just think some adopting Agile or whatever need to see the "bigger picture" of software development, and not just the coding segment.

Returning to the beginning …

I've had an interesting couple of days...  

I came across a book in my personal collection that's responsible for “starting it all” - my career in software engineering!

As I've been writing on this blog, I've found myself mentally referring to ideas I was sure originated from there.  And so I've decided it would be interesting 15 years on to return to the book, and compared “what I learned” from the book (ie pure theory) with “what I now know” (hard experience).

My education background is actually science/engineering/teaching – not “computers”, and it was during some PhD research I found myself more and more driven to use computers and write programs to analyse my data.

Originally I was using BASIC, but all the cool kids in the Department were using C++.  So I picked up a book by Michael J. Pont – Software Engineering with C++ and CASE Tools.  It's a mammoth book – 900 pages!

It's also kind of 3 books in one – it teaches you C++ language, it teaches you to use CASE Tools (not heard of them used since 2003) and then this thing called “software engineering”.  And it's the last area I've been revisiting.

For years this was the only book I'd read on testing, so opening it up, I was surprised to find no testing chapter.  In fact it covers testing in really only 4 pages.

That is – it only directly mentions testing in one spot – testing as a process.  However throughout as part of the discussion of software engineering there is a discussion about quality, about checking the quality of code at every level.  It's very similar to the Agile idea of “quality being baked in”, ie test early and ensure that any code meets at least basic functionality before passing it on.

I know as a developer I was very diligent about checking my code “worked” before passing it on.  I wouldn't do the obligatory developer “victory dance” until I was sure of this.

In recent years I'm somewhat alarmed on some projects how some development teams are in such a race to finish that this basic level of testing is just skipped.  It's almost going the way of “if it builds, it's good”.

Ironically in the “bad old days” test teams used to be made of developers with no coding to do.  Bad for testing, good for development.  As many developers would learn how their code would eventually be tested, and get their head around checks they needed to perform.

Maybe I need to start running a testing bootcamp with my developers.






[The book itself is probably a bit dated now - it's even got screenshots from Windows 3.1, C++ is now superceeded by C#, and CASE design tools replaced by Agile whiteboards.  It's still a very good book, Michael Pont having a superb writing style, and provides very detailed case studies to get your head around]

Pace

At school I used to hate running cross country/long distance.  Mainly this was because our sadistic gym teacher would leave cross country for the dead of winter, when the pitch was too frozen for Rugby.

I was dreadful – always at the back of the pack, keeping the asthma kid company.  My teacher used to tell me to beat the pain and the stitch by running faster.  Games teachers hey?

But that wasn't the whole story – don't write me completely off as the non-athletic science geek.  I was very good in Rugby, and also a fairly decent 100 metre runner.

But long distance – no way.

So I went through life convinced I couldn't run.  Until a few years ago an instructor at my local gym talked me into trying out a running program.  It was interesting – I told him “look I can't run”.  So he talked me through it …

The first week you run for just a minute, and then walk for a minute.  You do this for 20 minutes, three times a day.  “Hey”, I said, “I can run for just ONE minute”.  The week after you're running two minutes, walking for two.

Before you know it you're running 5 minutes, walking for 2, and doing this for 28 minutes.  Then two slots of 15 minutes, with a 1 minute walk between.  Then you're achieving a continuous run for 5km.

So this left me at 36 being a better runner than when I was 16.  On the face of it, it makes no sense – I don't feel fitter than when I was 16, I'm older, and certainly much heavier.

The difference was pace – pure and simple.

At school I never learned to moderate my pace – so I'd try and run cross country at 100m speeds.  Which is okay for 100m … maybe even 500.  But the pace isn't sustainable – and then it hurts.

The trick is to find a speed - and okay we're talking here about a slower speed - that's sustainable for your distance.

To be honest I tend to call any running I do “jogging” - it's faster than walking, even speed walking.  But it's no great speed – but heck I'm doing it.

At the Hutt City Triathlon (where the run segment is first), I was passed by a huge number of folk.  But then about half way around, I started to catch some of them up.  Their run pace was unsustainable, and they were now walking.  And as I say, I might not be lightening, but I'm faster than walking.

It was a good feeling – a kind of tortoise one-upmanship on a few hares.


Okay – so far so sporting anecdotes.  Why is this in a test blog?

In approaching testing for a big iteration, esp in a waterfall-esque project, we do tend to treat it as a race.  A race to test, a race to finish.

Unlike the hares on the triathlon we're probably more guilty of walk, walk, crawl, crawl … oh my God the deadline's nearly here – run, run, run!!!

The trick to avoid those last minute panic sprints is to try and work at a sustainable pace.  It's easy to say, but it's another thing to achieve it.

Especially in the early stages of a project, it's difficult to get hold of information or people – I'm getting at the moment for instance a lot of "look I'm too busy, I'll try and get back to you next week".  Which pretty much leaves the test group at an amber light – ready to move off, but not really able to.  And alas going around with thumbscrews only gets you so far ...


At the moment to keep up some kind of pace, we've identified we might need to use SOAP UI for testing the first iteration.  So we're trying to familiarise ourselves with that now, so we don't have to later.  Looking at what data we need, and preparing it – actions we might have left until a little later.

Keeping busy can feel a major occupation at times when the developers are running a month late, and you've nothing to test.  But it's an essential for a test team.  Lack of pace in a project is worse for the morale of a team than being overworked.

However giving team members tasks just to keep them busy and don't achieve things is also terrible for morale.  Some project managers I've known wouldn't give a hoot about team morale.

But in my book a team with good morale will feel more valued, be more engaged with their tasks, more creative with their solutions, but confident with interactions with other teams, and more diligent in their testing.

All that said – when it comes to running … I much prefer to be cycling.  Which let's face it is cheating!

Collaboration across the nation … *

Yesterday I was a profitable day.

I've been collaborating with a colleague in Auckland.  We're both trying to study a book on test management, and have formed a study group.  Though there were originally 6 of us, we're now just down to two.  But I have to say it's been a very positive experience.  And much better than reading the book on my own!

Basically every two weeks we take a chapter and we talk around the concepts.  More importantly we ask each other questions, and bring to the table our own experience of some of the issues.

I guess together we're brainstorming.  It's interesting because it takes us places I wouldn't have thought mentally to go.  As well as helping in my own mind to reinforce the bits that seem important.

What really surprises me is it also makes me have to think about my own experience, and I'm surprised the knowledge that comes out from me when my study partner asks questions.

It reminds me very much of something I read in Michael J. Pont's book on software engineering.  It's a slightly unknown book, but to me was THE book which taught me everything I know.  I'm still using bits of it.

In a section he talked about how collaborating with our peers when we hit problems can often bring out the answers from ourselves.  It's a bit like going to see a therapist, who doesn't tell you what's bothering you, but by being a good listener will ask the right questions, and before you know it, you're telling him what's wrong.

Just ten years ago, software was a very solitary activity.  You still had kind of “cave troll” programmers who would have their own cubicle cave, which you'd have to stop by with a mighty +1 defect (this is Dungeons and Dragons speak for the non-geek).

Today projects and environments are too big and complex to be kept in one persons head.  It's a more of a team activity, and as hinted at yesterday, the best teams are the ones who communicate to each other – yes even in Rugby with a gumshield.

Likewise, I've been talking to another colleague about the importance of social media to that ability to communicate to other testers, and hear other testers stories.  It helps sometimes to know how other people solve similar problems you face.


Heck sometimes it helps to just know it's not just you feeling like you're put through the wringer!




*  That title makes me smile – it was a song someone wrote in teaching college ...

Smells like team spirit ...

I was talking with another tester last week about team ethics.  Naturally as he's Indian based, he was talking cricket.

There is no doubt about the importance of teams – I'm going to approach it from the point of view of the “other scrum” (sorry Agilistas) – the Rugby kind.

My best Rugby days are behind me – but I still keep my hand in when I can and injuries persist.  Rugby is an amazing game because it has a lot of specialist roles – and indeed there's a role somewhere for anyone regardless of size and speed.  Big and slow?  We'll have you in the Scrum thankyou.  Fast as lightening?  We need you in the backs.

To get the most out of it, it helps to have trained with the guys you play with, and know they've got your back.  It helps to understand what everyone in the team does – the forwards and trying to get possession, and give the ball to the fleet footed backs to get the points.  It helps to have some experience in every position; prop, second row, number 8.

I always trained as a forward (the scrummers) until one game where I was a substitute, and we lost a back.  I got put into place as a winger – well outside my comfort zone – I had to ask “what am I supposed to do?”.  But it was a great game, I was out of position, and learning as I went – it kind of taught me a new respect for the backs, and an understanding of what they do.

We all know as a team, if we support each other, communicate when we have the ball, have each others backs, encourage and train together, it's going to be a positive experience, and we'll always do our best, even if we don't always win.  Believe me “communicating” when you have a gum shield is not very easy – but then sometimes all you need is “I'm here” and “c'mon with me”.

However if as in some teams, we don't know each other, we fail to communicate when passing the ball, and we constantly blame each other, we'll rarely win.


As with the team on the field, so for the team in the office …

I started a new testing assignment a couple of weeks ago.  It's good to get busy after a couple of months of idleness.

But there are things that concern me.  There is so much documentation to read – this is because the test team has in some ways been brought in last it feels … or at least my bit of the test team.

There is a 150 page test plan to plough through.  For anything that we want to think about tests – we have a business requirements document, a user case, an analysis document and a coding design document.

It's interesting in a way, as coming fresh into this environment I'm feeling that in a way having too much documentation can be as bad as having none-at-all.  And in this project's case is even worse.

Why?  One of the reasons is as testers we've been told business analysts and developers are “too busy” and not to be disturbed except by email questions.  This means we're unable to get any questions answered “in real time”, with usually a 2-day turn around time.

I have concerns when I start to hear the words “too busy”.  They're actually my most hated words on projects when I hear someone talk about being “too busy”.  There's almost an office expectation that when someone goes around saying they're “too busy” that they must be adding incredible value to the company.  I actually think the reverse is true.

If a key link in a project is “too busy” it means there are going to be a lot of people on a project who get sidelined or dead ended.  This isn't good.

It also reeks of self-importance.  I feel in a way that when we're told that developers and business analysts are “too busy”, we're actually being told that testing is really of less importance, weight and priority in the scheme of things on a project.

Of course there's a flip side to this – there are people who try and get work done, but they'd get so much more done if there were less interruptions.  I know I used to work occasional Saturdays and achieve in two hours just phenomenal amounts just due to the lack of distractions.  I've also known team leaders have lunch in their car in the car park as having it at their desk, they never get a break from people.

When you dismiss someone with “I'm too busy”, you're just putting a barrier to them.  Here I think are better ways of managing this,

• stand ups/daily meetings – call them what you will, but it gives a daily forum, and set time for people to be “approachable”
• “I'm in the middle of something right now – can we meet at 11?”.  You're getting them to acknowledge that you're busy right now, but there's a time you can catch up later.  You get to finish what you're doing, and they get their issue resolved.  There's compromise of both parts – you're going to have to give up time, they're going to have to just wait a little for a response.
• “I'm off to a meeting – but James is up to speed, and should be able to help you”.  Hopefully not one person has domain knowledge, it should be spread amongst your team.  Another member of staff should be able assist your co-worker.

The difference between these statements and the “too busy” dismissal is that (a) it communicates that you're in the middle of something but crucially (b) contains a compromise to resolve the issue your co-worker brings to you.


Would be nice to consign the words “too busy” to the medieval period of software development ...