Not long ago I had a late night discussion concerning Myers-Briggs and the "pseudo-science" behind it (it is based on Jung's work, which is admittedly a bit outdated, but it wasn't when M & B did their work). A few days later I came across independent tweets, one telling awful stories about how companies abuse the MBTI and the other about "how to deal with your introvert in your team", or something similar to that.
So now I feel a bit compelled to post something about how I see MBTI and in particular introverts.
I will give you 3 statements to go with, to moderate anything anyone ever say or claim about MBTI.
1. You are not your type.
Insanely important to understand: whatever your MBTI profile turns out to be, it's not you. Or the whole of you. The 4 parameters that the test measures you on each have 2 possible outcomes. So the test says you are either introvert or extravert. Intuitive or Sensitive. Thinking or Feeling. Judging or Perceiving.
So if your profile turns out to be ESTP - or any other - then that's not you. You do not tackle all of life from an extravert position. You can feel still. You can even judge. It simply means that you preference is ESTP, or we could call it your preferred mode of operation.
You feel good in this profile, so this is where you are probably most relaxed. But you can do all the others too. They are just harder for you. That's all.
Some people like to put their MBTI profile on their conference name badge. It's okay, I think. It tells others something about you, and whether you know about MBTI or not, that's a conversation starter - which is exactly what you would want at a conference.. Right? It's called conference for a reason.
If you put your MBTI (or worse: if others do) profile on your door to your office, it's wrong. It implies that you are ESTP (or whatever) always and must therefore always be treated to optimise that profile. The people who would walk in and out of that door would likely get to know you. They will not need a conversation starter. They won't even need a reminder of your type. Because they know you.
2. You can do all the profiles, if you want to
Yes, introverts can act as extraverts. And when I say 'act' I do not mean faking it. I mean using the extravert mode. And vice versa. So why have a MBTI profile? Because, there's a preference to a single one. You can learn to use the others, and it's easier once you recognise your starting point.
I have heard a lot of times how batteries are depleted when introverts are with other people, and charged again when the introvert is alone. I once even believed it, until I could no longer find truth in it. I suggest we change that model a bit (so meta now - a model for understanding a model.. hehehe):
Imagine that everything you do deplete you batteries. You have 4 batteries - corresponding to your four parameters in MBTI (no, not really, but this is a model.. play along).
Say your profile is ESTP. When you are acting in an extraverted way, your first battery will still discharge, slowly.
Sometimes you act in an introvert fashion. Your first battery will now discharge faster.
You recharge when you rest - either asleep or during a recreational activity.
Likewise you discharge a battery when you work from your thinking mode, and also - but much faster - when you operate from your feelings. And so on.
For some people, one or more of these modes are bordering to being impossible to use. If you are very very very much a "T" - thinking - then operating from your feelings - "F" - becomes difficult. Maybe even so that you try to shut that down completely inside you (mind you, in this case you will have very little control over your feelings - they will control you, as you have little experience with them). But it doesn't mean you cannot learn to get in touch with your "F" mode.
This is how we grow through life, learning more and more, and becoming less 'binary'. The MBTI is not binary as in exclusive. It just points to your preference.
3. Introverts are not shy, silent creatures
I have to be honest - it pisses me off when introverts are being presented as someone who cannot speak up in a group, who hates to be with other people and in all ways is a kind of sad person, just longing for solitude.
While it's true that introverts are dealing with solitude much easier than extraverts, introverts don't have to be tormented by shyness and insecurity. And if you - an introvert - think of yourself in that way you are doing yourself a disservice.
Being shy or insecure comes from your thinking: what can I add to this - am I worth anything in this context? It's a terrible question to ask again and again, especially if you arrive at a "nothing/no" for an answer frequently. But it's not the same as introvertness.
Being introvert does not mean you hate being with people. I am introvert, and I like being with people. I don't always appreciate to be the center of discussion, or the one who has to speak up - but I can do this if I want to, and regardless, I do like being in the company of others.
From my observations many introverts do. Being together is better than being alone, after all.
I find that to explain introvertness I need yet another model. Imagine you have something to say in a particular situation. Your brain forms a statement, but before it is being sent to your mouth for articulation, the uttering is being thrown in front of the internal board of directors. Here it is being weighed for relevance, importance (to you as well as to others), degree of funniness (oh, can we make other people laugh at the right time - so good ...) and some other things.
This process obviously takes time, even if your brain is quite fast.
And so, at last your brain may allow you to speak - or discard. And perhaps someone else said it just before you. So you keep quiet - slightly frustrated that you didn't just speak up but had to think about it. Or the moment went away before your sentence was ready to speak. Damnation.
Extraverts do not have this inner board of directors for censoring your speech. They just babble out whatever and feel perfectly happy about it.
Why it is so, I don't know. I also don't know if the model is accurate, but to me it makes sense.
I find that with alcohol, the internal board of directors seem to choose to party instead of doing censoring (that's not a recommendation to drink), and also when the topics are not very important (not a recommendation to not care about anything), this process flows easier and faster.
And also when in company with people who shares trust and the environment is very safe, this censorship goes away (this I recommend getting).
So it could be, that this introvert mechanism is simply for defense: do not put yourself or others at risk by saying the wrong thing at the wrong time. I don't know. But I do know, that being an introvert does not equate to hating being with other people.
So - what is MBTI for then?
I had a lot of struggle to find out what my preference is. I took the test over and over and with varying results. Every time I found that something just didn't add up.
Maybe you know, or maybe you don't, but there's one more step in taking the test, which can be done for free online - or paid if you prefer that: to have the test result validated through an interview. The test is crude. Only by interacting with another human being, trained to observe you, can the profile be determined.
Since I couldn't find an interviewer close by - and wasn't desperate enough to pay for it - I resorted to reading books about MBTI. It took me about 3 years to crack it, until I could see everything fall into place. I would recommend studying, as it gives you a more nuanced insight into how it works.
And also what you can use MBTI for.
For me, it's a tool to primarily understand that we as people are individuals and different, yet - somewhat similar. Some of the things we experience other people do strikes us as odd. Reminding yourself that there are other profiles around you than your own can be helpful in understanding where the others are coming from and why they may act as they do.
But in my humble opinion, if you take this further to expect people to act their type all the time, or hire people based on type - you're off the track. That's just wrong.
Instead you should accept the other humans you share a part of your life's journey with as they are and if it is helpful to you, use MBTI to understand them - and yourself - as one tiny piece of the puzzle.
Monday, 3 July 2017
Monday, 2 February 2015
I'm officially a mentor
I am proud to have become a mentor on the Speak Easy program.
Over the years I have spent a bit of my spare time to coach and consult with primarily younger testers from around the world, and I have enjoyed that immensely. When I found the Speak-Easy program. I simply thought: this is for me, this is what I do.
One of the best project managers I ever worked with had a saying, that there is only one thing in the world that can give you five years worth of experience, and that is 5 years of experience. You cannot cheat on this, you have to work your way through. Well, that was many years ago now, and I have an addition to make: you also need a push once in a while. I'm here for you to do just that.
I know how frightening it is to get up on the stage at a conference and how insecure it feels: do I have a message anyone even bothers to listen to? Will there be anyone left when I finish? Will they ask nasty questions or laugh?
Well, I intend to be the friend I needed back when I found myself writing proposals, doubting their worth myself, and then suddenly found myself with a ticket to a major conference. I was so nervous despite having rehearsed and rehearsed in my hotel room at least twenty times that last evening and morning. My heart was pounding when I got down to the room and partly disappointed and partly relieved that there were only a few people there. But once I had ensured myself that my slide deck was in place and had the microphone wrapped around my ears I turned around and saw that it was a packed room. I nearly died of nerves and I remember hearing my voice stutter and break up a bit on the first words. Then it calmed down somehow magically and I got through it, and the rest of the conference was a celebration.
I belong to a community where discussion matters and where opinions need to be defended. That becomes boring when only a few voices are present. The more diverse views and the more ideas that are brought into the debates - and conferences are a great place for that - the better. I'd like to do my bit for that.
Saturday, 9 November 2013
Observations from EuroSTAR 2013
Only just returned and with the first cup of coffee - mostly still in the cup - my head is buzzing with impressions, images of people I met, presentations, quotes and all. This post will try to capture as much of this as possible.
Friday morning I happened to eat breakfast with Dot Graham and John Stevenson and of course we reflected upon the conference. I put forward a notion of feeling that "testing is slowly coming out of the years of adolescence". With that I mean, we're getting more critical to what is being said, what is being thrown our way and better at taking a stance for our profession.
I think several keynotes represented this view. Laurent Bossavit's opening keynote, which essentially dissected myths about for instance the higher cost of fixing a defect if found late. Pretty much all testers I know can recite actually found real-life counter-examples of this myth, so I was not surprised to learn that there's practically no evidence behind it. Ironically the only data that could be found did not support the theory. The urge to delve into the matter, which I got from that great keynote, and which I hope others got as well, resonates fairly strong with me.
And it was backed quite a bit also with keynotes from Keith Klain and Martin Pol, with messages of being persistent, professional and keeping on calling 'bullshit' whenever appropriate.
One prominent example was reading aloud some of the promotion statements collected at the EuroSTAR EXPO, promising that the tools would do everything for us, and guarantee fantastic results - claims the tools cannot ever fulfill.
And this in contrast to the Tuesday afternoon keynote (by Harry Collin's last-minute replacement), stating that when computers started doing less and leave more options and decisions to humans, they often helped the most - oh the irony.
The final taking stance urge came from Fiona Charles' keynote: get in there and argue! It's our job, it's our responsibility as professional testers to ask questions and probe deep into whatever knowledge is presented. One very good question was asked during the open season of that keynote: doesn't that require quite a lot of bravery from a tester ? And the answer was shockingly clear: yes! But it's our job to be brave in these matters.
What else did I take away from the conference? As a facilitator I of course was very much aware of how the facilitated open seasons (15-20 minutes after each presentation) with K-cards worked. Overall, it worked well, I think. Anyway it felt way more fair and inviting to ask questions than at previous EuroSTAR's I attended where there was only a few minutes after each presentation to ask questions, and it always seemed to be someone loudmouthed who got to ask the one question that there was time for. Now, if only the sessions could get a little longer than 45 minutes, we could get deeper into each subject.
The EXPO seemed different this time. I don't know what it was, but my take on it was that the sales guys were getting a bit tired of their own messages. Anybody else got that impression too ? It may be overly interpreting - but it was like they had taken so much criticism and hardly now could straighten up and give the normal pitch again. Maybe they heard the keynotes as well.
Summing up for me - this was one of the better EuroSTAR's I've attended. The presentations I saw were diverse and interesting. Good subjects. Thank you EuroSTAR.
PS: putting a half-hour feedback session in the middle of the workshops is.not.a.good.idea!
Friday morning I happened to eat breakfast with Dot Graham and John Stevenson and of course we reflected upon the conference. I put forward a notion of feeling that "testing is slowly coming out of the years of adolescence". With that I mean, we're getting more critical to what is being said, what is being thrown our way and better at taking a stance for our profession.
I think several keynotes represented this view. Laurent Bossavit's opening keynote, which essentially dissected myths about for instance the higher cost of fixing a defect if found late. Pretty much all testers I know can recite actually found real-life counter-examples of this myth, so I was not surprised to learn that there's practically no evidence behind it. Ironically the only data that could be found did not support the theory. The urge to delve into the matter, which I got from that great keynote, and which I hope others got as well, resonates fairly strong with me.
And it was backed quite a bit also with keynotes from Keith Klain and Martin Pol, with messages of being persistent, professional and keeping on calling 'bullshit' whenever appropriate.
One prominent example was reading aloud some of the promotion statements collected at the EuroSTAR EXPO, promising that the tools would do everything for us, and guarantee fantastic results - claims the tools cannot ever fulfill.
And this in contrast to the Tuesday afternoon keynote (by Harry Collin's last-minute replacement), stating that when computers started doing less and leave more options and decisions to humans, they often helped the most - oh the irony.
The final taking stance urge came from Fiona Charles' keynote: get in there and argue! It's our job, it's our responsibility as professional testers to ask questions and probe deep into whatever knowledge is presented. One very good question was asked during the open season of that keynote: doesn't that require quite a lot of bravery from a tester ? And the answer was shockingly clear: yes! But it's our job to be brave in these matters.
What else did I take away from the conference? As a facilitator I of course was very much aware of how the facilitated open seasons (15-20 minutes after each presentation) with K-cards worked. Overall, it worked well, I think. Anyway it felt way more fair and inviting to ask questions than at previous EuroSTAR's I attended where there was only a few minutes after each presentation to ask questions, and it always seemed to be someone loudmouthed who got to ask the one question that there was time for. Now, if only the sessions could get a little longer than 45 minutes, we could get deeper into each subject.
The EXPO seemed different this time. I don't know what it was, but my take on it was that the sales guys were getting a bit tired of their own messages. Anybody else got that impression too ? It may be overly interpreting - but it was like they had taken so much criticism and hardly now could straighten up and give the normal pitch again. Maybe they heard the keynotes as well.
Summing up for me - this was one of the better EuroSTAR's I've attended. The presentations I saw were diverse and interesting. Good subjects. Thank you EuroSTAR.
PS: putting a half-hour feedback session in the middle of the workshops is.not.a.good.idea!
Sunday, 20 October 2013
Problems computers (still) don't solve for us
This is a rant. Be warned.
I'm constantly using computers for professional and leisure purposes, and spread over several technologies. And it strikes me so often nowadays, that they have all come to suffer from the same troubles.
In more cases than not, computers are taking up our time by requiring us, their lords and masters (aka human beings), to do a lot of different things, that we really shouldn't be bothered with. We have enslaved ourselves so deeply in the need for computing services that we accept doing this!
One thing that bothers me mostly these days is the insatiable need to organise files and folders. I am old enough to remember a time without folders. No need since the storage was limited to a 5,25 inch floppy. The floppy itself was a folder. With added storage room came the "folder".
Of course, some people older than me, or more pedantic, may now turn their attention to telling me off, since there was in fact folders before then. Sure, this is just how I remember it on early, sort-of-publicly-accessible computers in the beginning of the 1980'ies. The question to ponder though, is - why do we still have folders ?
Let me ask you: aren't computers getting better at searching ? (yes, google and bing are very good examples). Aren't computers having enough cpu cycles per second to be able to organise our relatively few files (I'm talking about the files we humans produce, not the files f.ex. a compiler produces) ? (yes, they ought to). So - why should a human being even bother to name files and place them in a folder structure ? Why can't the computer take care of that ?
(But - how could we fnd the files again?) - well, from content, circumstances, date and time, ownership, lists or tree structures produced, presented and maintained by the computer in it's plentiful spare, idle cpu cycles.. We're so hung up on the ANCIENT concpet that a file can have for instance only one name - often with a postfix "surname", denoting it's "type". Why can't a file have more names ? Tags ? Even my ("#€)(€ - sorry) samsung blueray cannot cope with recordings of tv programs, if they span more than 1 tv program. It only has a huge 1 TB hd space.. should be possible to store more than 40 chars per recording, right ? It's a terrible piece of machinery... but I digress.
The entire concept of a file system lacks updating to the 21st century. We are sort of stuck in the way we had to do things 30-40 years ago.
Why does this bother me ? Well, I had my eyes opened a couple of years back, when I decided I wanted to invest a few bucks in my writing. I like writing, but I needed a good tool to help me. I found a gem called PageFour. It's cheap enough for anyone serious about writing to invest in, and IT HAS A MAGNIFICENT TAKE ON DOCUMENTS! First, they made the program in a way that you will never loose what you type in. You could just type and close down the program. It would have saved your text (actually they added a save button because human beings, their users, mistrusted computers so much, they felt better having a save button... that's so sad ...)
Secondly they decided to put the folder and file problem out of the world. Instead the user can organise their writing in "notebooks" and "pages". Not too different you think ? Well, the words are different and much more human understandable. Their users are writers, not techies.
But the beautiful thing is, to write something you pick a notebook - maybe the nearest one - fling open a new page and start writing. Yes - that sounds like something you do without a computer, but in PageFour, this is what you do - click on a notebook, click on the +page button, start writing. No hassle of navigating through a file structure, and then ponder what the filename should be.
(Yes! that actually takes up a lot of my brain cycles and they should be busy doing the writing...)
PageFour is a bless to use. It's low in features, yes, by frigging design! It's about writing, not styling.
Another big thing (with me at least) is that computers still take up like 1-2 minutes to start up. My pc's have grown in capacity, cpu cycles, memory, hd size and all over the years, but since the 1990'ies, they have consistently taken minutes out of my life for starting up. Why ?
Well, luckily, I got pushed into buying a Mac. Wow. Problem solved.
Only, now I can't use PageFour anymore.
Yes, I know this is more ranting than any other thing, but what I really want YOU to think of, is - why do we put up with all this crap that computers (and the humans behind the OS's and user interfaces) still don't solve for us ? They are still supposed to be our tools, right ? We shouldn't let them demand things from us that they are perfectly capable of solving themselves!
Tuesday, 1 October 2013
Problem patterns
I had a puzzling problem. I had noted for some time that one particular automated scenario often failed and yesterday it was time to dig deeper into that. The scenario was very simple: it searched for and displayed a persons name and address, then it checked that the persons name matched the search criteria. Not a revolutionary or even finished scenario, which is why it had been ignored earlier on. We are still building this thing up.
When it failed it could be confirmed from the screen dumps, that were automatically saved whenever a scenario failed, that another persons name in fact was shown on the screen - not just name, but a totally different person had been found instead.
Debugging I created a special command to take a screen dump whenever I wanted, which I thought would come in handy anyway, and then plastered it all over the scenario so I could follow each step.
I was baffled that the next test run showed that the right person was found and displayed. Aha, I thought, this was probably like following a link. An internet posting suggested to give the web page focus before activating a link. I guessed that taking a screen dump could have that effect.
Quickly I disabled all the screen dump commands, and ran it again. Theory confirmed, the scenario found the wrong person this time.
Back to the code: I enabled the screen dump right before the search thinking that that would focus the page and make it catch the search criteria correctly - and ran the whole thing again. I was confirmed - it really did find the right person now.
But - saving a screen dump unnecessarily was not really what I wanted, so instead I used the set-focus command, and checked that it worked.. It failed dramatically - a quick inspection showed that I had screwed up with my simple copy-pasting ruining the scenario. Dammit. After fixing this the right person was found and happily I leaned back, victory!
All I needed to do now was simply to build the whole thing and I was ready to finish up. My mandatory test run came out as a surprise. It failed again. Flabbergasted I decided to run it again, just for the heck of it and to give me time to think it over once again. I lost my breath... it passed.
Suddenly it dawned on me. I had not bothered to investigate the pattern for the bug. I could possible have guessed that something funny was going on since I knew that it didn't fail all the time. But I just didn't follow that thread.
After running the scenario 20 times in a row without changing anything, the pattern was clear. Failure happened every second time, exactly. Reviewing my efforts, fleshed out above, it was clear to me that actually I had matched this pattern exactly in my efforts, and drawn false conclusions on that basis. In fact, none of my efforts had probably had any effect. Shoot.
I thought it was a valuable lesson to learn about making a few more investigations before trying to fix a bug. I mean, had I bothered to run the scenario just two or three times in a row, I had seen it right away.. Probably..
And the bug ? It evaporated with the next Get Latest... another funny day in automation land, eh?
Tuesday, 11 June 2013
New tools
I bought a new pair of running shoes yesterday.
Tried them today.
I look awesome, they feel really great to wear.
But in the end it's still my legs and lungs that must deliver the running.
Think about that before you invest money and time in a new tool for testing, running or whatever. What exactly do you want it to help you with?
Tried them today.
I look awesome, they feel really great to wear.
But in the end it's still my legs and lungs that must deliver the running.
Think about that before you invest money and time in a new tool for testing, running or whatever. What exactly do you want it to help you with?
Friday, 24 May 2013
#LetsTest 2013 - it was HUGE!
Be there or be square - on of the first clichés I learned in english, and the most fitting description I can find for the question: What was LetsTest like this year ?
I don't know exactly what made it such a huge experience. Was it that the venue place (Runö, near Stockholm, Sweden) was so beautiful ? That everyone was living there and had no other place to go (not that I figure anyone would want that) ? It certainly played in. A conference shouldn't be spread out and provide invitations to do anything other than conferring.
And conferring means conversation, chatter, exchange of ideas, questioning and thinking a bit hard before answering - sometimes. Also laughter and - for Scandinavian standards - a very high level of cheering and applause. You people from outside Scandinavia have no idea how extraverted and passionated this was :-)
It could be that the K-cards were used and all sessions were facilitated - providing equal opportunities for all to participate and comment or question the speaker - or the previous one who spoke. Despite some did swear a bit when asked for a card, it did become a good habit (as it was last year also..)
There's a youtube channel (LetsTestConference) where various video clips are posted, and one might just look at them and conclude that it was more or less a party. It really was. But watch again and listen closely. There's talking - in pretty much all of them (not so much in the workout one, but hey, no ones perfect). The talking never seized and the videos shows highly diversed groups of people talkingtalkingtalkingtalkingtalking.. Probably that also has a thing to do with why my head is rumbling today.. it's way too silent where I am now :-)
An element which is subtle, but highly important: LetsTest is for testers, and by testers. All facilitators where testers. The activities were run by testers, the organisers are testers too. I think it made all the difference, keeping things relevant. Especially in testing we don't need more people outside testing "helping" us, making money on our behalf. This was a testing event, for testers and celebrating the testing craft. And when we decide to do that, we rock!
Next year, be there!
I don't know exactly what made it such a huge experience. Was it that the venue place (Runö, near Stockholm, Sweden) was so beautiful ? That everyone was living there and had no other place to go (not that I figure anyone would want that) ? It certainly played in. A conference shouldn't be spread out and provide invitations to do anything other than conferring.
And conferring means conversation, chatter, exchange of ideas, questioning and thinking a bit hard before answering - sometimes. Also laughter and - for Scandinavian standards - a very high level of cheering and applause. You people from outside Scandinavia have no idea how extraverted and passionated this was :-)
It could be that the K-cards were used and all sessions were facilitated - providing equal opportunities for all to participate and comment or question the speaker - or the previous one who spoke. Despite some did swear a bit when asked for a card, it did become a good habit (as it was last year also..)
There's a youtube channel (LetsTestConference) where various video clips are posted, and one might just look at them and conclude that it was more or less a party. It really was. But watch again and listen closely. There's talking - in pretty much all of them (not so much in the workout one, but hey, no ones perfect). The talking never seized and the videos shows highly diversed groups of people talkingtalkingtalkingtalkingtalking.. Probably that also has a thing to do with why my head is rumbling today.. it's way too silent where I am now :-)
An element which is subtle, but highly important: LetsTest is for testers, and by testers. All facilitators where testers. The activities were run by testers, the organisers are testers too. I think it made all the difference, keeping things relevant. Especially in testing we don't need more people outside testing "helping" us, making money on our behalf. This was a testing event, for testers and celebrating the testing craft. And when we decide to do that, we rock!
Next year, be there!
Wednesday, 24 April 2013
Go DaRE=M - a heuristic for testing plans
It suddenly struck me, that I might need to put this one out in the blog space. For years I have used this heuristic, and although it might contain influences from others, I actually consider this my very own, home-made heuristic. Since forming it I've taught it in classes and even presented it in a Lightening Talk once - so it's high time to put it more on "print"!
So, what is DaRE=M ? It's a heuristic I use for testing a plan, like when someone tosses you a bunch of papers: "can't you drop an eye on this plan I made, just to see if I left anything obvious out?"
That's when I start on the "D" - which of course is for Deliverables. It's the first letter in the heuristic and also the most important one. I readily flunk plans that do not highlight the deliverables in a clear and consistent way. And why shouldn't I ? The plan is supposed to bring us somewhere so if we cannot read "where" from the plan, I don't have high regards for anything else in it.
The next letter is "a" - notice, it's not a capital A - it's minuscule and stands for activities. Surely there may be some activities in a plan, sometimes we just have to point them out - but: they are not as important as Deliverables and furthermore must always "hang on" to a deliverable (otherwise: why are we doing this activity ?). Clearly, if the activities are so overwhelming in the plan, that you cannot figure the deliverables, the plan is probably not going to work (it should be minuscule, not capitalized).
"Da" is a set - unseparable. Funnily if you open up a project planning tool, guess what's the first thing you are invited to put into it is ? Yup - an activity..
I think that's backwards - figure what you want, then plan your steps to get there!
The R and the E are of course Resources and Estimates, and yes, I put machinery and people under the same label here, although it seems to annoy some people. I consider it an honour to be "resourceful", but maybe my command of the english language isn't good enough to pick up the subtle insult in this. Never mind that now - for this purpose we need something to represent the limitations and constraints we experience in regard to who and what we can utilize for obtaining the Deliverables, and the estimated time/money/whatever we have to live by. I won't go to great lengths about estimation for now, as usually it's in fact pretty much a constant, not a variable, anyway. Again, the importance lies in whether any constraints in these matters have been considered, or not.
SO - we find ourselves at the "=".. it's there to make it look like a mathematical equation, although mathematical speaking it's rubbish. It's a heuristic only, folks, no time for accuracy as long as it lights up a synapse or two in your brain.
The idea is to invite you to balance the two sides of the equation - here the Deliverables, Resources and Estimates with the M, which represents the Milestones.
In other words: when someone asks: "when can this be done" they actually ask for the M's, and they are deductable from the set of DaRE.
If they asked a different question, like: "how many people do you need", you will have to rearrange the equation, isolating R: DaME = R.
And if they ask: "what can you do before [insert date]" - it will become REM=Da - or: it's a function of how many people and machines and rooms and stuff I got (since the E and M are practically given).
Yes, this resembles pretty much the famous project triangle of time, cost and deliverables, but I still think this elaboration is "mine".. well, now it's in the blog space, it's more like.. ours :-)
I remember it by pronouncing it "Dare'em", like in "Dare them to show me the plan", which in my curly brain makes sense, while native english speakers may wince..
As I started out with, I have been using this for a long time, and an addition came to it a few years ago: what if we have great unknowns ? This could be a testing plan, not a production plan, so we may not be able to put in the D's from the start, right ?
Not entirely right, as I see it. Over to the Dark Side you mustn't go, Luke - and you: - don't fall for the attempt to replace Deliverables with Activities; it will bring you only harm and suffering!
For exploration you still need a road map, although some or most of it is foggy and unclear. The absence of a goal is the major reason to object against exploratory testing, giving it labels like "hapsy-flapsy" and "unaccountable". What we do in this case is actually so simple most people would ignore it: we name our first steps as deliverables - still not the activity of taking a step, but if you imagine yourself with a pretty blank piece of paper as a roadmap in a very foggy world, what you do is look up and around and say something along the line of: "Let's travel to that stone over there and that rock down there. From those points we can look further into the shadows and figure what's on the other side. We're looking for a place to cross the river and a shelter for the night - let's go, guys!".
If you're lost in the wilderness this would probably make sense - and though we don't know too much about what we might find, we are still determining deliverables like "a place to cross river", and "a shelter".
The activities are "going to the stone" and "going to the rock" - the deliverable they belong to is: "further outlook".
Figuring that what we need is a shelter and a place to cross the river comes from your understanding of your situation - the "why you are here" question. You need some kind of overall goal to pursue, and the clearer the goal, the easier it is to create a plan. Often I've seen plans that are way too generic, almost text book-ish, and leaves me with only questions about what the entire purpose of the plan might be. So an appropriate addition to the heuristic would be adding a Go for "Goal", so it becomes
So, what is DaRE=M ? It's a heuristic I use for testing a plan, like when someone tosses you a bunch of papers: "can't you drop an eye on this plan I made, just to see if I left anything obvious out?"
That's when I start on the "D" - which of course is for Deliverables. It's the first letter in the heuristic and also the most important one. I readily flunk plans that do not highlight the deliverables in a clear and consistent way. And why shouldn't I ? The plan is supposed to bring us somewhere so if we cannot read "where" from the plan, I don't have high regards for anything else in it.
The next letter is "a" - notice, it's not a capital A - it's minuscule and stands for activities. Surely there may be some activities in a plan, sometimes we just have to point them out - but: they are not as important as Deliverables and furthermore must always "hang on" to a deliverable (otherwise: why are we doing this activity ?). Clearly, if the activities are so overwhelming in the plan, that you cannot figure the deliverables, the plan is probably not going to work (it should be minuscule, not capitalized).
"Da" is a set - unseparable. Funnily if you open up a project planning tool, guess what's the first thing you are invited to put into it is ? Yup - an activity..
I think that's backwards - figure what you want, then plan your steps to get there!
The R and the E are of course Resources and Estimates, and yes, I put machinery and people under the same label here, although it seems to annoy some people. I consider it an honour to be "resourceful", but maybe my command of the english language isn't good enough to pick up the subtle insult in this. Never mind that now - for this purpose we need something to represent the limitations and constraints we experience in regard to who and what we can utilize for obtaining the Deliverables, and the estimated time/money/whatever we have to live by. I won't go to great lengths about estimation for now, as usually it's in fact pretty much a constant, not a variable, anyway. Again, the importance lies in whether any constraints in these matters have been considered, or not.
SO - we find ourselves at the "=".. it's there to make it look like a mathematical equation, although mathematical speaking it's rubbish. It's a heuristic only, folks, no time for accuracy as long as it lights up a synapse or two in your brain.
The idea is to invite you to balance the two sides of the equation - here the Deliverables, Resources and Estimates with the M, which represents the Milestones.
In other words: when someone asks: "when can this be done" they actually ask for the M's, and they are deductable from the set of DaRE.
If they asked a different question, like: "how many people do you need", you will have to rearrange the equation, isolating R: DaME = R.
And if they ask: "what can you do before [insert date]" - it will become REM=Da - or: it's a function of how many people and machines and rooms and stuff I got (since the E and M are practically given).
Yes, this resembles pretty much the famous project triangle of time, cost and deliverables, but I still think this elaboration is "mine".. well, now it's in the blog space, it's more like.. ours :-)
I remember it by pronouncing it "Dare'em", like in "Dare them to show me the plan", which in my curly brain makes sense, while native english speakers may wince..
As I started out with, I have been using this for a long time, and an addition came to it a few years ago: what if we have great unknowns ? This could be a testing plan, not a production plan, so we may not be able to put in the D's from the start, right ?
Not entirely right, as I see it. Over to the Dark Side you mustn't go, Luke - and you: - don't fall for the attempt to replace Deliverables with Activities; it will bring you only harm and suffering!
For exploration you still need a road map, although some or most of it is foggy and unclear. The absence of a goal is the major reason to object against exploratory testing, giving it labels like "hapsy-flapsy" and "unaccountable". What we do in this case is actually so simple most people would ignore it: we name our first steps as deliverables - still not the activity of taking a step, but if you imagine yourself with a pretty blank piece of paper as a roadmap in a very foggy world, what you do is look up and around and say something along the line of: "Let's travel to that stone over there and that rock down there. From those points we can look further into the shadows and figure what's on the other side. We're looking for a place to cross the river and a shelter for the night - let's go, guys!".
If you're lost in the wilderness this would probably make sense - and though we don't know too much about what we might find, we are still determining deliverables like "a place to cross river", and "a shelter".
The activities are "going to the stone" and "going to the rock" - the deliverable they belong to is: "further outlook".
Figuring that what we need is a shelter and a place to cross the river comes from your understanding of your situation - the "why you are here" question. You need some kind of overall goal to pursue, and the clearer the goal, the easier it is to create a plan. Often I've seen plans that are way too generic, almost text book-ish, and leaves me with only questions about what the entire purpose of the plan might be. So an appropriate addition to the heuristic would be adding a Go for "Goal", so it becomes
Go DaRE=M
Sunday, 2 January 2011
(One of) The most important question in testing
.. is not about the testing itself, but:
I think, with such reactions, that this is truly an important question to ask:
I find this question to be very valuable to ask, though. It gives some insight into why testers are called onboard a project. It might be, that a project manager just realised that the project manual called for testing to be done (in which case the project manager would probably be surprised and perhaps even angry when you present her/him with the bug list after testing... this was supposed to be the last activity in the project, right ?). Or that a customer have huge problems with a delivery and wants some input to throw in the face of the developers. Or that the scrum master needs to get his demos to actually not crash - or wants to feed his team with tasks that stabilize the code.
Testing comes in multiple varieties - so does the usage of test results.
The best advice I can give you is: ask the question and debate the answer.
In a way, this is where testing really starts...
"What are you going to do about the information that testing will provide you with ?"This is the kind of question that really shoves lots of stakeholders out of their comfort zone. I've seen more than one with flickering eyebrows, when I've asked this question.
I think, with such reactions, that this is truly an important question to ask:
- If there's no answer to this question, is the testing we do going to be useful ? - to anyone ?
- If there is one answer to this question, we might forget to debate it to figure whether it's the right answer (one could be reminded of Jerry Weinberg's Rule of Three here..)
- If there are more answers, they are bound to be in conflict with each other. Which are more important for now ? - and later ? (oh yes, priorities do change over time ;-)
I find this question to be very valuable to ask, though. It gives some insight into why testers are called onboard a project. It might be, that a project manager just realised that the project manual called for testing to be done (in which case the project manager would probably be surprised and perhaps even angry when you present her/him with the bug list after testing... this was supposed to be the last activity in the project, right ?). Or that a customer have huge problems with a delivery and wants some input to throw in the face of the developers. Or that the scrum master needs to get his demos to actually not crash - or wants to feed his team with tasks that stabilize the code.
Testing comes in multiple varieties - so does the usage of test results.
The best advice I can give you is: ask the question and debate the answer.
In a way, this is where testing really starts...
Monday, 1 November 2010
Organizing test ideas with mind maps
I forgot when I started to draw my first mind maps.
Like I'm sure many others do, I'm thinking slightly chaotic, in the sense, that I get inspiration and ideas after I finished something.
Mind maps are, as far as I know, created for that kind of thinking. So - if you're not one of those rare and rather strange persons who thinks everything sequentially and forward, you'd benefit from it too.
My preference tool is paper and pencil. Yes, I'm bloody old fashioned, but that always works and batteries don't wear out.
However, sometimes it's practical to have stuff on a computer and I've been using FreeMind for years. It's free, it's easy to use and though it's got its fair amount of really hilarious bugs, it's stable and reliable.
So - Paul Carvalho inspired me to write about how I use FreeMind to organise test ideas. I can't show you examples from real life, as they would both be way too big to show and I guess my clients would mind if I map their business (pun intended...).
Of course I would never reveal that, but I am willing to reveal a mockup example to show how I do it.
Here's an example we all know: Google. I only used the front page and followed a few links.
You may recognize that I 'factored' the front page. We all know it as a simple text field and a search button. Most of us remember that there's also an 'I feel lucky'-button, that we only use when we're bored. But in fact there's quite a lot of other features, and they are a bit more advanced than it looks like. For instance the redirection function that shows you a localized front page.
Take a look at the real thing and compare with my little mind map here.
Factoring is a skill of it's own, I learned it from James Bach. Factoring is really about finding 'dimensions' to test. Here I just put in the functions I found, but I did make a note that there's performance in a search operation. I put it in and maybe I want to later expand that node.
Notice I reused the response time sub-tree for the advanced search as well. Is that good organizing ? Well, it's okay for a preliminary stage. But later - if we get to reuse it a lot, it's better to move it out among the common elements or something and simply refer to it. The good thing is that there are no rules. Whatever works for you - well, it works for you.
One note of warning though: if you fall into the same trap as PM's do when they repeat a block of activities in their plan - you'll get lost. Don't do that. I find that it's mostly not only convenient but also sufficient that you realise that something is repeating. There's little value in documenting everything. The real value comes from you having learned about the repetition.
So - start it up. Extend and expand as you get more information and inspiration. Extend and reuse by referring. Use icons to add some meaning or overview. Ask questions (very easy this way because you always ask the question in context of a node).
I can test directly from this and extend it while I do so. I put in ideas, functions and non-functions to look out for. A map of the system.
I can mark out branches and sub branches and put them on charters. I can readily show what works and where the problems (bugs) are. I can also show what isn't tested yet.
In short - I can communicate this and keep a great overview.
You should try it too.
Please let me know what you think.
Like I'm sure many others do, I'm thinking slightly chaotic, in the sense, that I get inspiration and ideas after I finished something.
Mind maps are, as far as I know, created for that kind of thinking. So - if you're not one of those rare and rather strange persons who thinks everything sequentially and forward, you'd benefit from it too.
My preference tool is paper and pencil. Yes, I'm bloody old fashioned, but that always works and batteries don't wear out.
However, sometimes it's practical to have stuff on a computer and I've been using FreeMind for years. It's free, it's easy to use and though it's got its fair amount of really hilarious bugs, it's stable and reliable.
So - Paul Carvalho inspired me to write about how I use FreeMind to organise test ideas. I can't show you examples from real life, as they would both be way too big to show and I guess my clients would mind if I map their business (pun intended...).
Of course I would never reveal that, but I am willing to reveal a mockup example to show how I do it.
Here's an example we all know: Google. I only used the front page and followed a few links.
You may recognize that I 'factored' the front page. We all know it as a simple text field and a search button. Most of us remember that there's also an 'I feel lucky'-button, that we only use when we're bored. But in fact there's quite a lot of other features, and they are a bit more advanced than it looks like. For instance the redirection function that shows you a localized front page.
Factoring is a skill of it's own, I learned it from James Bach. Factoring is really about finding 'dimensions' to test. Here I just put in the functions I found, but I did make a note that there's performance in a search operation. I put it in and maybe I want to later expand that node.
Notice I reused the response time sub-tree for the advanced search as well. Is that good organizing ? Well, it's okay for a preliminary stage. But later - if we get to reuse it a lot, it's better to move it out among the common elements or something and simply refer to it. The good thing is that there are no rules. Whatever works for you - well, it works for you.
One note of warning though: if you fall into the same trap as PM's do when they repeat a block of activities in their plan - you'll get lost. Don't do that. I find that it's mostly not only convenient but also sufficient that you realise that something is repeating. There's little value in documenting everything. The real value comes from you having learned about the repetition.
So - start it up. Extend and expand as you get more information and inspiration. Extend and reuse by referring. Use icons to add some meaning or overview. Ask questions (very easy this way because you always ask the question in context of a node).
I can test directly from this and extend it while I do so. I put in ideas, functions and non-functions to look out for. A map of the system.
I can mark out branches and sub branches and put them on charters. I can readily show what works and where the problems (bugs) are. I can also show what isn't tested yet.
In short - I can communicate this and keep a great overview.
You should try it too.
Thursday, 2 September 2010
CAST2010 was a blast
So I went to CAST 2010 in Michigan. It was a blast. Although, not so many people this year.
You never heard of CAST ?
Why - it is a wonderful conference, with a huge emphasis on CONFERring. So it's sold, and so it is also. I've been going three years in a row now and I keep learning from this conference.
One of the special things is that all the sessions are about half presentation, and half discussion. And discussions run far and deep too. In comparison to other conferences, you could actually attend them and not really speak a lot, except in the hasty breaks in between sessions. One or two guys would get to ask questions. Maybe they are not even good questions, but there's no more time. Then there's lunch, where you usually sit among total strangers, and you first need to find rapport and common grounds - usually small talk about the weather and the subway is the only conversation.
I mean, there's nothing particular bad in this. You hopefully get to listen to great presentations by smart people. Only - at CAST you get to participate.
I know this is described in different places, but I repeat it here: At CAST discussions are facilitated. That means that everybody (yeah - EVERYbody) get's a red, a yellow and a green card. One for commenting on the current thread. One for signalling that I've got a new thread. And the red card for: I really, really need to speak right now!
And you probably think: ...a forest of red cards.. Oh no. You forget - CAST is facilitated. The facilitator (and they are pretty good at this) keeps track of who wants to speak (and will take away your red card if it is abused). If you've got something to say you get your place in the queue. It works. Threads are followed as long as there's energy and if you raise a card, you get to speak.
Again: this works. People talk. A lot. Even for long. Questions are never: yes/no. It's always a looong story. Seems like all have something to say. And the conference is truly trying to support this.
Lunch is pretty interesting too. You probably met people before. Maybe even argued with them. Makes talking to them much more interesting and fun.
This year I was lucky to present myself. Twice, even (which is a bit more stressful than I expected). We got pretty good reviews (I wasn't alone on either talk). One talk - Dealing with passionless testers (with Henrik Andersson) - ended with a great discussion. We didn't get through all the stuff we planned, and I was kinda sorry for that - then. Now when I think about it - we did trigger a very deep, valuable, sometimes very personal, debate. We used a small film to kickstart it. It's on youtube. Find it! If you're a good tester, you can! :-)
The other talk - Nice words are not enough (with Louise Perold) - about introducing session-based testing and exploratory testing in projects, went great, but I think it suffered a bit by being the last thing on the schedule - apart from the ending session. People was just a bit tired - or maybe exhausted ? But we still had a good, long discussion.
I do hope I can make it to CAST next year again. I don't know if it's possible but I hope. Because I am anxious to learn more and meet more cool people.
Meanwhile I will have to settle for EuroSTAR - in Copenhagen this year. I hope you signed up! I'm talking there too! "Session-based testing in practice". A sort of SBTM 101. I'm excited. It's just about my favorite subject in testing.
You never heard of CAST ?
Why - it is a wonderful conference, with a huge emphasis on CONFERring. So it's sold, and so it is also. I've been going three years in a row now and I keep learning from this conference.
One of the special things is that all the sessions are about half presentation, and half discussion. And discussions run far and deep too. In comparison to other conferences, you could actually attend them and not really speak a lot, except in the hasty breaks in between sessions. One or two guys would get to ask questions. Maybe they are not even good questions, but there's no more time. Then there's lunch, where you usually sit among total strangers, and you first need to find rapport and common grounds - usually small talk about the weather and the subway is the only conversation.
I mean, there's nothing particular bad in this. You hopefully get to listen to great presentations by smart people. Only - at CAST you get to participate.
I know this is described in different places, but I repeat it here: At CAST discussions are facilitated. That means that everybody (yeah - EVERYbody) get's a red, a yellow and a green card. One for commenting on the current thread. One for signalling that I've got a new thread. And the red card for: I really, really need to speak right now!
And you probably think: ...a forest of red cards.. Oh no. You forget - CAST is facilitated. The facilitator (and they are pretty good at this) keeps track of who wants to speak (and will take away your red card if it is abused). If you've got something to say you get your place in the queue. It works. Threads are followed as long as there's energy and if you raise a card, you get to speak.
Again: this works. People talk. A lot. Even for long. Questions are never: yes/no. It's always a looong story. Seems like all have something to say. And the conference is truly trying to support this.
Lunch is pretty interesting too. You probably met people before. Maybe even argued with them. Makes talking to them much more interesting and fun.
This year I was lucky to present myself. Twice, even (which is a bit more stressful than I expected). We got pretty good reviews (I wasn't alone on either talk). One talk - Dealing with passionless testers (with Henrik Andersson) - ended with a great discussion. We didn't get through all the stuff we planned, and I was kinda sorry for that - then. Now when I think about it - we did trigger a very deep, valuable, sometimes very personal, debate. We used a small film to kickstart it. It's on youtube. Find it! If you're a good tester, you can! :-)
The other talk - Nice words are not enough (with Louise Perold) - about introducing session-based testing and exploratory testing in projects, went great, but I think it suffered a bit by being the last thing on the schedule - apart from the ending session. People was just a bit tired - or maybe exhausted ? But we still had a good, long discussion.
I do hope I can make it to CAST next year again. I don't know if it's possible but I hope. Because I am anxious to learn more and meet more cool people.
Meanwhile I will have to settle for EuroSTAR - in Copenhagen this year. I hope you signed up! I'm talking there too! "Session-based testing in practice". A sort of SBTM 101. I'm excited. It's just about my favorite subject in testing.
Sunday, 7 March 2010
Software testing and amphibious attacks
Once in a while it's difficult to hit the kill-button on the remote while show after show rolls over the screen. Occassionally something interesting comes along. This time it was an analysis and review of two famous marine assaults, their planning, strategy and outcome.
What struck me in particular was the strategy, which resembles very much what we do in software testing.
The strategy for the marine assaults was laid out to contain objective, intelligence, approach, assault, lodging and break-out.
Here's how that goes for software testing:
Objective
This is what we want to accomplish, in short our mission statement - the entire purpose of the operation. Usually we talk of it as a want of demonstrating the systems functionality, or that it will break, or figuring whether it is or isn't vulnarable to a certain threat or risk. But like an army we actually want to conquer and gain control. Marines deals with territory. Software testers deals with information and knowledge.
Intelligence
Once we put our eye to what we want to do, we need to start gathering intelligence, or information. We need to figure whether it's actually possible. No good landing on a beach full of quicksand, right ? Just as bad to base your test on getting data from an external system you can't reach in the test environment. In a way this represents our first test results, but it's just what is needed to sanity check our plan.
Approach
Sure if you're about to land an army at position X, you need to transport it there, without getting sunk, hit or devastated before you reach X.
Likewise in testing - we need to find a way to approach what we're searching for, in a way so we will have all the necessary power and initiatives ready for the actual assault. In other words, we need to prepare test data, user priviliges, test environment and so forth. If we've decided to try to print 1.000 tickets, then we should make sure that the system contains 1.000 tickets in a state where they are ready to be printed.
Assault
How do we do it ? Land the full force in one go ? Establish a single, narrow bridgehead, or spreadout for a simultanous attack on several weak spots at the same time ? It's different from approach, which we can plan ahead and even refine in detail. During the assault we must be agile, open, observant and ready to change direction, method and toolset. Until now we've only modelled the 'landscape', so when we set our foot there, surprises are to be expected. This is also what makes this very interesting.
Lodging
We never really think of it, but of course we have to settle down in the newly won territory. We need to make ourselves safe and enable logistics. We need to transport data (troops and supplies) to the frontline. We need to examine the new ground we conquered. Isn't that what we do ? The first login is always a bit trembling. Soon we login and go much further without blinking. And while some testers will be operating on the frontline, others will have to take on the tasks of creating more test data, hooking up new equipment etc etc. Logistics necessary to keep the operation going.
Break-out
This is the one that makes it all fit together - we can't stay on the beach forever. We can't live with a frontline three miles into the country. We need to 'break through' and finally accomplish our goal. Marines don't establish a bridgehead on a beach just to claim the beach. They do that in order to accomplish something more. Now we've invaded the system, we need to find the weak spots and/or the opportunities to carry on, to conquer the remaining part of the system, so to speak.
I think this is a brilliant way of putting together a strategy, also for software testing.
Don't you ?
What struck me in particular was the strategy, which resembles very much what we do in software testing.
The strategy for the marine assaults was laid out to contain objective, intelligence, approach, assault, lodging and break-out.
Here's how that goes for software testing:
Objective
This is what we want to accomplish, in short our mission statement - the entire purpose of the operation. Usually we talk of it as a want of demonstrating the systems functionality, or that it will break, or figuring whether it is or isn't vulnarable to a certain threat or risk. But like an army we actually want to conquer and gain control. Marines deals with territory. Software testers deals with information and knowledge.
Intelligence
Once we put our eye to what we want to do, we need to start gathering intelligence, or information. We need to figure whether it's actually possible. No good landing on a beach full of quicksand, right ? Just as bad to base your test on getting data from an external system you can't reach in the test environment. In a way this represents our first test results, but it's just what is needed to sanity check our plan.
Approach
Sure if you're about to land an army at position X, you need to transport it there, without getting sunk, hit or devastated before you reach X.
Likewise in testing - we need to find a way to approach what we're searching for, in a way so we will have all the necessary power and initiatives ready for the actual assault. In other words, we need to prepare test data, user priviliges, test environment and so forth. If we've decided to try to print 1.000 tickets, then we should make sure that the system contains 1.000 tickets in a state where they are ready to be printed.
Assault
How do we do it ? Land the full force in one go ? Establish a single, narrow bridgehead, or spreadout for a simultanous attack on several weak spots at the same time ? It's different from approach, which we can plan ahead and even refine in detail. During the assault we must be agile, open, observant and ready to change direction, method and toolset. Until now we've only modelled the 'landscape', so when we set our foot there, surprises are to be expected. This is also what makes this very interesting.
Lodging
We never really think of it, but of course we have to settle down in the newly won territory. We need to make ourselves safe and enable logistics. We need to transport data (troops and supplies) to the frontline. We need to examine the new ground we conquered. Isn't that what we do ? The first login is always a bit trembling. Soon we login and go much further without blinking. And while some testers will be operating on the frontline, others will have to take on the tasks of creating more test data, hooking up new equipment etc etc. Logistics necessary to keep the operation going.
Break-out
This is the one that makes it all fit together - we can't stay on the beach forever. We can't live with a frontline three miles into the country. We need to 'break through' and finally accomplish our goal. Marines don't establish a bridgehead on a beach just to claim the beach. They do that in order to accomplish something more. Now we've invaded the system, we need to find the weak spots and/or the opportunities to carry on, to conquer the remaining part of the system, so to speak.
I think this is a brilliant way of putting together a strategy, also for software testing.
Don't you ?
Saturday, 19 December 2009
Book reviews
I 'ate' a lot of Jerry-books lately. I decided to write something about them.
They are all recommendable and in the following I will tell you why. Overall I enjoyed reading them very much.
Becoming a Technical Leader, by Gerald Weinberg
This is a great book because it tells the reader a lot about what leadership is, how to work towards it and what to be observant about on that road. It's clearly closely connected to the PSL workshop, though being on PSL greatly enhances the experience of reading this book.
As in most of Jerry's books there's some questions for the reader along the way, some of them quite hard. One of the toughest is to start a personal log, a diary. I'm personally succeeding (this far) in my third attempt. It's a book which will dig into the reader and reveal things you either weren't aware of, or don't want to know about. It easily becomes very personal, but I like that. As a professional guide to elaborating on your own self, I think it's a must. As a nice, interesting read, I would say: yes. As something to read and toss away and forget all about, I'd say: I wonder if you can do that. Somethings are bound to touch you.
Introduction to General Systems Thinking, by Gerald Weinberg
This is, I think, the most referred-to book of Jerry's. A lot of people praise it. I found it perhaps the most difficult of his books to read this far. I crashed after the first few chapters in my first attempt, and left it on the shelf for months. Not that I didn't like what I read, but somehow I found it hard to concentrate and perhaps find all the time needed to really work with the text. The second attempt was better, knowing that I should put some effort into it and taking the time to do it.
One of the things I particular like is how it asks questions like 'it's an XXX - how do you know ? what do you understand by "XXX" '. So it sort of starts off from the basics and put things into perspective.
Often it works on the english semantics and words and I at least really feels that english is not my first language. I think I do well on average, but some of the stuff in this book is over my abilities.
Upon finishing the book I have to admit to myself: maybe I didn't quite grasp it all. I intend to give it a second (third) try next year.
Are your lights on ?, by Don Gause and Gerald Weinberg
This is quite a different book. It's smaller and has fewer words per page than the other books. But the content is in top. Everybody can readily identify themselves with the 'hero' in each situation and probably also the villain(s). It takes you through some very ordinary situations and asks simple questions like: whose problem is it ? Questions, which are simple to ask, but very difficult sometimes to answer. And isn't that so in most situations we get ourselves into.
I enjoyed this book a lot, perhaps mostly because it made me think a lot.
Exploring Requirements, by Don Gause and Gerald Weinberg
I actually avoided this book for some time, thinking that 'requirements' - I know that and anyway, isn't it a bit boring ? Well, - no. This is a wonderful read, which gives you a lot of tools, hints and tricks when you try to describe to yourself or others what you want done. It's obviously really applicable if you're writing requirements, but also if you just want to be very clear about what you tell people.
I found lots of gems in this book (and thank you for the recommendation, Leo).
Secrets of Consulting, by Jerry Weinberg
This is a book full of Jerry-stories. If you have ever met Jerry, you'll know that he thinks it's always time for a story. And he's got so many of them. Some got written down in this perl of a book, which tells you important stuff in a nice, informal way. Things to do, consider and remember if you're 'consulting' - which we all are from time to time.
I'm looking forward to start on 'More secrets of consulting', which is one of the new ones in my collection (although none of these books were very recently published...)
Mistress of Molecules, by Gerald Weinberg
This is a fiction book. However, I was fortunate (and fast) enough to buy it as a real book at AYE, which Jerry himself had ordered printed, because, as I heard Jerry mumble: people want real books. I agree.
It's available for a few bucks as a pdf on Jerry's online shop (try google a bit and you'll find it within minutes).
It's a fascinating story, set on distant planets in a future which seems not only foreign and strange, but also strangely familiar. Admitted, it's not completely realistic on some points, but hey, it's fiction and the story works!
I enjoyed reading it for the story, the characters, the science and the many surprises I got along the way.
All good books - get them for x-mas, birthdays or just to fill up on your shelf - but make sure you get to read them too ;-)
They are all recommendable and in the following I will tell you why. Overall I enjoyed reading them very much.
Becoming a Technical Leader, by Gerald Weinberg
This is a great book because it tells the reader a lot about what leadership is, how to work towards it and what to be observant about on that road. It's clearly closely connected to the PSL workshop, though being on PSL greatly enhances the experience of reading this book.
As in most of Jerry's books there's some questions for the reader along the way, some of them quite hard. One of the toughest is to start a personal log, a diary. I'm personally succeeding (this far) in my third attempt. It's a book which will dig into the reader and reveal things you either weren't aware of, or don't want to know about. It easily becomes very personal, but I like that. As a professional guide to elaborating on your own self, I think it's a must. As a nice, interesting read, I would say: yes. As something to read and toss away and forget all about, I'd say: I wonder if you can do that. Somethings are bound to touch you.
Introduction to General Systems Thinking, by Gerald Weinberg
This is, I think, the most referred-to book of Jerry's. A lot of people praise it. I found it perhaps the most difficult of his books to read this far. I crashed after the first few chapters in my first attempt, and left it on the shelf for months. Not that I didn't like what I read, but somehow I found it hard to concentrate and perhaps find all the time needed to really work with the text. The second attempt was better, knowing that I should put some effort into it and taking the time to do it.
One of the things I particular like is how it asks questions like 'it's an XXX - how do you know ? what do you understand by "XXX" '. So it sort of starts off from the basics and put things into perspective.
Often it works on the english semantics and words and I at least really feels that english is not my first language. I think I do well on average, but some of the stuff in this book is over my abilities.
Upon finishing the book I have to admit to myself: maybe I didn't quite grasp it all. I intend to give it a second (third) try next year.
Are your lights on ?, by Don Gause and Gerald Weinberg
This is quite a different book. It's smaller and has fewer words per page than the other books. But the content is in top. Everybody can readily identify themselves with the 'hero' in each situation and probably also the villain(s). It takes you through some very ordinary situations and asks simple questions like: whose problem is it ? Questions, which are simple to ask, but very difficult sometimes to answer. And isn't that so in most situations we get ourselves into.
I enjoyed this book a lot, perhaps mostly because it made me think a lot.
Exploring Requirements, by Don Gause and Gerald Weinberg
I actually avoided this book for some time, thinking that 'requirements' - I know that and anyway, isn't it a bit boring ? Well, - no. This is a wonderful read, which gives you a lot of tools, hints and tricks when you try to describe to yourself or others what you want done. It's obviously really applicable if you're writing requirements, but also if you just want to be very clear about what you tell people.
I found lots of gems in this book (and thank you for the recommendation, Leo).
Secrets of Consulting, by Jerry Weinberg
This is a book full of Jerry-stories. If you have ever met Jerry, you'll know that he thinks it's always time for a story. And he's got so many of them. Some got written down in this perl of a book, which tells you important stuff in a nice, informal way. Things to do, consider and remember if you're 'consulting' - which we all are from time to time.
I'm looking forward to start on 'More secrets of consulting', which is one of the new ones in my collection (although none of these books were very recently published...)
Mistress of Molecules, by Gerald Weinberg
This is a fiction book. However, I was fortunate (and fast) enough to buy it as a real book at AYE, which Jerry himself had ordered printed, because, as I heard Jerry mumble: people want real books. I agree.
It's available for a few bucks as a pdf on Jerry's online shop (try google a bit and you'll find it within minutes).
It's a fascinating story, set on distant planets in a future which seems not only foreign and strange, but also strangely familiar. Admitted, it's not completely realistic on some points, but hey, it's fiction and the story works!
I enjoyed reading it for the story, the characters, the science and the many surprises I got along the way.
All good books - get them for x-mas, birthdays or just to fill up on your shelf - but make sure you get to read them too ;-)
Monday, 22 June 2009
Exploring old skills and fun games
I've once again stumpled across a Sinclair ZX Spectrum Emulator. I have no clue as to how I got on to that, but now it's here. And I'm amazed by all I still know and remember of this magnificent machine and it's broad range of software, dating back around 27 years ago.
On www.worldofspectrum.org you can find a fine collection of both software, documentation and emulators and much more. Most of the software is regarded as 'abandonware', which I think is not legally justified, but on the other hand - if I dig hard enough I can possibly find the original cassettes on the attic along with the machine itself. And they continue to amuse and amaze me. I think that's 'quality', to me at least.
The standard spectrum game is not in itself breathtaking. I mean, some of them were and I remember some of them actually being way ahead of (their) time. Today the graphics and especially sound is crude, simple and a bit strange.
But they pertain something else: gameplay, fun and originality.
This goes along with one of my theories of software development: that if you're forced to work under severe constraints, your work will become better. One of my fanciful ideas is to restrain developers from compiling more than once a day or just have one pc with the development tool per four developers. I've yet to try and pull that off in real life, but in my mind it would work and create better software faster. More on that on another blog entry.
The 'speccy', as we who've known it for all those years often call it, has it's own restrictions. Standard memory was 48 Kb RAM. That's 48 * 1024 bytes. No megabyte here.. All program, data, system variables and stuff should be fit within this size. And your mass storage was a tape recorder. Slow and painful. I used to buy tapes of 45 mins per side, because they were cheaper. Trying to find where I had stored a program of 4 mins time somewhere was painfully tedious.
And graphics... not that many pixels either. 32 characters across the screen, each representing 8 bytes. By 'stacking' them, the bits would make it out as pixels. So you had the enourmous amount of 32 * 8 pixels across screen. But - colors were restricted to the character's size.
Still software developers of the time made fantastic measures to overcome this. For instance, some games where held in the same colors, like black and cyan, to create a certain style or atmosphere. It worked (sometimes).
Some made their own character rendering, and accomplished 45 characters across. I myself created a machine code routine that could print 64 chars across screen - by making each character maximum 3 pixels wide (and the fourth would be the space between characters).
The game play reminds me of the Wii Sports Game. It's nothing graphically compared to other games, but it's the one that's still fun to play after some time. The game play is what makes people return to it.
And originality was in top. Back then everything was made for the first time. Take one of my favorites from then: Juggernaut (see picture of cassette inlay). Steering a large truck around a small city infested with roundabouts, road work and tricky turns to accomplish a days work of collection goods is still fun. Back then I didn't know how to drive. I do now, and I'm doing better, but it's still relentlessly hard.
Another favorite is Dark Empire, which graphically is so simple noone would give it a chance. It's probably one the games I've played for the longest time ever. It's a strategic war game and you have to discover the world first. At the beginning all is clouded. As your ships and armies move around you'll discover island (or continent) after island with new cities - and enemies, of course :-)
Graphically it sucks. The sound must be turned off or you'll go crazy (and you can do that on an emulator ;-) But the game is so fun.
There. I had to get it out of my chest :-) I will always keep a special place in my heart for the speccy, my long lost companion - and now again. I find that I've actually preferred these games to modern top games, with stunning graphics and orchestral sound. They just don't have the game play, that let's you spend the tiny bit of your own imagination and which keeps these games alive and interesting.
A need to mention the MESS team, who created the free emulator, that can emulate an astounding amount of personal computers back from then.
On www.worldofspectrum.org you can find a fine collection of both software, documentation and emulators and much more. Most of the software is regarded as 'abandonware', which I think is not legally justified, but on the other hand - if I dig hard enough I can possibly find the original cassettes on the attic along with the machine itself. And they continue to amuse and amaze me. I think that's 'quality', to me at least.
The standard spectrum game is not in itself breathtaking. I mean, some of them were and I remember some of them actually being way ahead of (their) time. Today the graphics and especially sound is crude, simple and a bit strange.
But they pertain something else: gameplay, fun and originality.
This goes along with one of my theories of software development: that if you're forced to work under severe constraints, your work will become better. One of my fanciful ideas is to restrain developers from compiling more than once a day or just have one pc with the development tool per four developers. I've yet to try and pull that off in real life, but in my mind it would work and create better software faster. More on that on another blog entry.
The 'speccy', as we who've known it for all those years often call it, has it's own restrictions. Standard memory was 48 Kb RAM. That's 48 * 1024 bytes. No megabyte here.. All program, data, system variables and stuff should be fit within this size. And your mass storage was a tape recorder. Slow and painful. I used to buy tapes of 45 mins per side, because they were cheaper. Trying to find where I had stored a program of 4 mins time somewhere was painfully tedious.
And graphics... not that many pixels either. 32 characters across the screen, each representing 8 bytes. By 'stacking' them, the bits would make it out as pixels. So you had the enourmous amount of 32 * 8 pixels across screen. But - colors were restricted to the character's size.
Still software developers of the time made fantastic measures to overcome this. For instance, some games where held in the same colors, like black and cyan, to create a certain style or atmosphere. It worked (sometimes).
Some made their own character rendering, and accomplished 45 characters across. I myself created a machine code routine that could print 64 chars across screen - by making each character maximum 3 pixels wide (and the fourth would be the space between characters).
The game play reminds me of the Wii Sports Game. It's nothing graphically compared to other games, but it's the one that's still fun to play after some time. The game play is what makes people return to it.
And originality was in top. Back then everything was made for the first time. Take one of my favorites from then: Juggernaut (see picture of cassette inlay). Steering a large truck around a small city infested with roundabouts, road work and tricky turns to accomplish a days work of collection goods is still fun. Back then I didn't know how to drive. I do now, and I'm doing better, but it's still relentlessly hard.
Another favorite is Dark Empire, which graphically is so simple noone would give it a chance. It's probably one the games I've played for the longest time ever. It's a strategic war game and you have to discover the world first. At the beginning all is clouded. As your ships and armies move around you'll discover island (or continent) after island with new cities - and enemies, of course :-)
Graphically it sucks. The sound must be turned off or you'll go crazy (and you can do that on an emulator ;-) But the game is so fun.
There. I had to get it out of my chest :-) I will always keep a special place in my heart for the speccy, my long lost companion - and now again. I find that I've actually preferred these games to modern top games, with stunning graphics and orchestral sound. They just don't have the game play, that let's you spend the tiny bit of your own imagination and which keeps these games alive and interesting.
A need to mention the MESS team, who created the free emulator, that can emulate an astounding amount of personal computers back from then.
Tuesday, 31 March 2009
Back from PSL
I have just returned - that is, I came back yesterday - from the Problem Solving Leadership workshop in Albuquerque. My body is still on USA time, and exhausted from travelling almost 20 hours, all included. But my mind is energized, and having these two feelings simultanously is pretty weird.
A lot of things are going around in my mind now. Usually I keep a lot of stuff in it, but right now it's way more than the usual level. I wonder if I will ever stop learning from this experience.
I went through my notes from the workshop just prior to checking out from the hotel. I've got more notes than I use to, but also - most of the notes are written between the lines. I've never seen that happen in something I've written myself.
Now - what is this blog post about. I don't know really. It may be irrelevant and perhaps annoying to you, but for me I guess it's the first step out of the workshop, trying to figure out what hit me. For example: I remember the lady in the hotel reception, too busy typing something into the computer to help us acquire a taxi. Something that would normally be annoying. But now, I'm not not annoyed, but I understand more of why she would behave like this and how I could react to it. And that's a great feeling.
Okay, enough of this emotional stuff. Albuquerque struck me as being completely different from anything I'd expected from a large, american city. Only a few tall buildings, everything else laid out as small, low establishments. I would not have blinked if Clint Eastwood would have strolled out of the Saloon, with a riffel in his hands, whistling for his horse. :-)
I think I stop here, take another cup of coffee and process a little more on all the great people I met, the great insights I gained, the learning points I acquired and probably provided.
That's all - for now.
A lot of things are going around in my mind now. Usually I keep a lot of stuff in it, but right now it's way more than the usual level. I wonder if I will ever stop learning from this experience.
I went through my notes from the workshop just prior to checking out from the hotel. I've got more notes than I use to, but also - most of the notes are written between the lines. I've never seen that happen in something I've written myself.
Now - what is this blog post about. I don't know really. It may be irrelevant and perhaps annoying to you, but for me I guess it's the first step out of the workshop, trying to figure out what hit me. For example: I remember the lady in the hotel reception, too busy typing something into the computer to help us acquire a taxi. Something that would normally be annoying. But now, I'm not not annoyed, but I understand more of why she would behave like this and how I could react to it. And that's a great feeling.
Okay, enough of this emotional stuff. Albuquerque struck me as being completely different from anything I'd expected from a large, american city. Only a few tall buildings, everything else laid out as small, low establishments. I would not have blinked if Clint Eastwood would have strolled out of the Saloon, with a riffel in his hands, whistling for his horse. :-)
I think I stop here, take another cup of coffee and process a little more on all the great people I met, the great insights I gained, the learning points I acquired and probably provided.
That's all - for now.
Subscribe to:
Posts (Atom)