Too Much Fun
I've had an absolutely crazy couple of weeks. Way too much to do in too short of a period of time. Along with that, there has been too many things that are "absolutely top priority." You know how that is - where there is a stack of "absolutely can not wait items."
Not just work stuff - but life stuff. Home and family stuff that needs to be addressed. People who need help with something. All of this is important, right? All of it takes energy.
In the mean time, there is stuff that seems, well, maybe too big to handle on your own? Problems that don't seem to have a solution?
Maybe you never had that issue. Maybe you never had a problem like that.
Spring
Ah well - Winter seems to be gone, in my neighborhood anyway. Most of the snow has melted. There are some very large piles of snow that are hanging around - and even they are a shadow of what they were a month or so ago.
It has been warm all week. Now, "warm" is relative. I do live in Michigan. (Today we reached the scorching high temperature of 48F/8C.)
The result is, I could spend time working in the garden on Saturday. Gardening is a wonderful thing. No, really. Saturday, I cleaned up the last of the Christmas decorations that were in the front garden.
Well, these were fake poinsettias set in garden pots in the front yard, that had, around Christmas time, small, lighted trees on them. There was 1 one each side of the front steps. The small, lighted trees and the garland came down some time ago. I also took down the red led "mini-lights" that were on the weeping cherry tree in the front garden.
The lights are kind of fun. The last several years we've wrapped lights up the stem and onto branches of the tree. When they are lighted at night, the tree looks like a red palm tree. Oh. We also wrap green lights around the tree. The green lights go on the tree first, then the red lights.
The red lights are turned on just before Christmas. They stay on until after Valentine's Day. My habit is to unplug the red lights and turn on the green lights on March 1 - St. David's Day. They stay on until sometime after St. Patrick's Day.
They need to come down shortly after that most years, because as the weather warms, the flowers in the garden begin awakening and the weeping cherry begins to bud out. We need to get the lights off the tree before that gets going full steam. So, the red lights came down Saturday. I left the green lights on for now. They may come down tomorrow.
Gardening
After putting the lights and fake flowers away, I got out the rake and gently raked around the plants in the front garden. The daffodils and other flowers beginning to poke out, if not blooming, were exposed from their layer of leaves that covered the garden all winter.
Scooping up those leaves is a very satisfying thing. Really. They are bagged up and the plants were exposed - and, to be perfectly frank. The garden looks really nice after this - in an early spring sort of way.
Working in the garden this time of year gives a certain level of satisfaction that may not be there at other times. The ground, as it awakens from its winter sleep, has a healthy scent of strength, growth and new life.
Clearing away the collected leaves and various bits of... stuff, that settled over the winter reveals new growth and a promise of beauty in a matter of weeks. Mind you, there is a certain beauty of the garden as it is.
It no longer looks as a wild, abandoned place. Instead, it looks like a place where the growing things can be seen for what they are and the promise that they have for beauty later in the year.
It is funny how satisfying a few minutes work can be. Obvious results and a sense of completion that often is missing in software. Sure. We can say we "finished" a project, but mostly we see evidence around that "finish." We don't actually see the results.
Seeing results is pretty cool. That is why I like gardening.
Another reason is, you can do it and completely relax your mind. There is no reason whatsoever to engage in deep thoughts on what is to be done or how - you just do it. And it is done. And it is a pleasure to look at.
Apple Pie
It is an excellent way to get something tangible done and free the mind. The thing is, sometimes the best thing you can do when you have a pile of work that "must get done," is to work on something unrelated. It helps clear the brain and rest the mind - even while working on something else.
Do you remember Men In Black? The movies with Will Smith and Tommy Lee Jones playing Agents in an unnamed, extra-governmental agency dealing with aliens? The third movie in the collection featured Will Smith going back in time to help a young Tommy Lee Jones deal with an evil alien before he can kill Tommy Lee Jones?
At one point, they wander into a diner for pie - well, because grand-daddy talked about the power of pie. Some debate, hemming and hawing - and -
Apple pie - with a slice of cheese on it.
And Will Smith's character goes off on how he always orders that and... the light goes on. The odd comment made earlier suddenly makes sense.
And there is a classic example of the point - Defocusing.
Stepping away from the problem at hand to work on something else. The mind is freed from what it has been mired in. While working on another problem, the solution sometimes (often) presents itself.
Why? In my case, it is because I let go and worked on something "mindless." This activity allows me to let off steam and mentally relax and let go.
This gives me two results.
One, a task I need to do gets done (like, work in the garden).
Two, in the midst of raking and pulling and cleaning, I find the answer I had been struggling to find while I was "working" on it.
I don't know if it will work work for everyone. I just know it works for me - and a lot of people I know.
Monday, March 23, 2015
Saturday, March 21, 2015
On Needs, Wants and Being Told What to Do
Brace yourself.
This is a bit of a rant.
For most of my 30+ years in software development, many of them have been working with companies where software is made to support their primary business. It might be Insurance or Manufacturing or Sales or Distribution & Transportation - but many of these companies, the people using the software don't pay for it. They really don't have an option. To do their jobs, they need to use whatever stuff they get from IT.
If this does not describe the type of organization you are working in, you might want to skip this. Of course, if you have worked in an organization like this, or might possibly work in an organization like this, or perhaps you're curious what has me so worked up - please read on. Thanks.
Sometimes IT people annoy me. Of course, sometimes Internal Business folks annoy me, too.
How often have we heard or heard about IT/software development folks, telling people in business units what they need from the software to do their jobs? After all - the IT folks know what the computer systems do and can do and so they are the experts.
Sorry.
The accounting and finance courses I had in school, longer ago than I want to admit, while it helped me work through and understand journal entries and balance sheets and other basic finance and accountancy stuff - These do not give me enough understanding to tell the Chief Financial Officer or Company Treasurer or whatever, what they need from the software their staff uses in order to make good, informed decisions.
I can, however, discuss with them the intent they have for using new or changed software. I can discuss the gain they hope to achieve from said software. I can listen and take into consideration what their desire for the end product should look like.
When I am working on making software do something, I can do something else to help the people who need this for their jobs.
I will do my level best to make software and work with the team making the software, that fills the needs and purpose described and discussed.
When possible, I will do my level best to have it work as they wanted.
However - that is not a promise.
Instead, I will do my best to fill their need first.
I've learned that IT people see their "wants" as "needs" (rather like the "business" folks they make software for.) Cool features or functionality are cool. They are pleasing to design and implement. Do the help the people they are intended to help? Sometimes, sure. Of course. Other times? I've seen too much time and effort put into something that business functional experts truly do not care about.
And what of the "Business" experts?
The people who use the software every day to do their jobs. The people who make use of the results of that work, every day, to do their jobs. The "decision makers" looking at reports or summaries or dashboards produced and built by IT - What about them?
Do these people understand the business rules the software is intended to follow? Do they understand what the software is intended to do and why? Do they understand the purpose of what it does now and what the change will be?
Do they understand or know this without asking IT folks for help?
When they do, can the IT folks help them without looking at the code?
Have people abdicated their responsibility and put others in place as their proxies?
Now, if these things sound familiar in your organization, is it any surprise that your software has problems?
None of us really like it when people with no clue what we need tell us what we should do next.
Do the people who are supposed to:
Someone has to decide what it will do. I suggest it be someone who knows what the purpose and needs are.
This is a bit of a rant.
For most of my 30+ years in software development, many of them have been working with companies where software is made to support their primary business. It might be Insurance or Manufacturing or Sales or Distribution & Transportation - but many of these companies, the people using the software don't pay for it. They really don't have an option. To do their jobs, they need to use whatever stuff they get from IT.
If this does not describe the type of organization you are working in, you might want to skip this. Of course, if you have worked in an organization like this, or might possibly work in an organization like this, or perhaps you're curious what has me so worked up - please read on. Thanks.
Sometimes IT people annoy me. Of course, sometimes Internal Business folks annoy me, too.
How often have we heard or heard about IT/software development folks, telling people in business units what they need from the software to do their jobs? After all - the IT folks know what the computer systems do and can do and so they are the experts.
Sorry.
The accounting and finance courses I had in school, longer ago than I want to admit, while it helped me work through and understand journal entries and balance sheets and other basic finance and accountancy stuff - These do not give me enough understanding to tell the Chief Financial Officer or Company Treasurer or whatever, what they need from the software their staff uses in order to make good, informed decisions.
I can, however, discuss with them the intent they have for using new or changed software. I can discuss the gain they hope to achieve from said software. I can listen and take into consideration what their desire for the end product should look like.
When I am working on making software do something, I can do something else to help the people who need this for their jobs.
I will do my level best to make software and work with the team making the software, that fills the needs and purpose described and discussed.
When possible, I will do my level best to have it work as they wanted.
However - that is not a promise.
Instead, I will do my best to fill their need first.
I've learned that IT people see their "wants" as "needs" (rather like the "business" folks they make software for.) Cool features or functionality are cool. They are pleasing to design and implement. Do the help the people they are intended to help? Sometimes, sure. Of course. Other times? I've seen too much time and effort put into something that business functional experts truly do not care about.
And what of the "Business" experts?
The people who use the software every day to do their jobs. The people who make use of the results of that work, every day, to do their jobs. The "decision makers" looking at reports or summaries or dashboards produced and built by IT - What about them?
Do these people understand the business rules the software is intended to follow? Do they understand what the software is intended to do and why? Do they understand the purpose of what it does now and what the change will be?
Do they understand or know this without asking IT folks for help?
When they do, can the IT folks help them without looking at the code?
Have people abdicated their responsibility and put others in place as their proxies?
Now, if these things sound familiar in your organization, is it any surprise that your software has problems?
None of us really like it when people with no clue what we need tell us what we should do next.
Do the people who are supposed to:
- Understand the purpose behind the changes;
- Understand the business rules that to be followed;
- Understand the why behind these things;
Someone has to decide what it will do. I suggest it be someone who knows what the purpose and needs are.
Sunday, March 15, 2015
On Tradition, Tribal Knowledge and "Everyone Knows..."
Interesting story I heard on NPR a couple of years ago. (Oh, for those not in the US, NPR is a privately and publicly funded
non-profit organization that serves as a national
syndicator for some 900 public radio stations in the U.S., often associated with universities or other forms of learning.) The story was around Holiday Traditions.
While the gist was the Winter holidays, Christmas, Hanukkuh, New Year's, etc., they talked about other Holidays as well. The guests being interviewed mentioned how family "traditions" are really, on average, a generation old. People associate doing something for a given Holiday if their family, when they were children, did that thing for the same Holiday. In turn, their children will associate doing what ever their family does for Holidays as "Traditional."
Whilst I was still actively competing in pipe bands and teaching workshops for drumming in pipe bands, I remember a panel discussion with a group of pipers and drummers from the US, Canada, Ireland and Scotland. We were talking about styles of drumming and interpreting music.
We got pulled in two significant directions, both of which I found fascinating and I wish I could have been in a place to take notes. We talked on how things can influence our interpretation of music and how we approach music. We talked about how jazz had influenced great drummers in the pipe band world from the 1940's and 50's. We talked about how emigration from Ireland and Scotland had brought musicians to the US and Canada and how they had taught people what they had learned.
The result was many people and pipe bands in the US and Canada tended to inherit an understanding that was, at best, behind the curve of leaders in the world of pipe band were by the 1960's and 70's. The Legion and Community pipe bands in North America tended to get taught "this is how we did it in..." one of the regiments in the British Army.
This got latched on to as "traditional." The people they taught said the same thing to others they in turn taught.
I remember teaching a band that intended to begin competing some basic technique for bass and tenor drumming. There was a fair amount of resistance because I was teaching them stuff that was "wrong." Their argument was "This is how the British Army does it." I asked which regiment - then pulled out video tapes of the Edinburgh Tattoo, massed Pipes and Drums of the Scottish Division beating retreat and the Scots Guards Trooping the Colours. None of the tenor drummers did anything remotely similar to what they were doing.
Tradition had shifted. Memories had failed as the knowledge was passed on.
Working with some testers a while back there was a problem. The parameters used to run the job they needed run to verify some changes made way up-stream in the process did not seem to be working.
I asked them what they were seeing. They were pretty confused. The people who had worked on this same set of parameters had given them instructions around what to do. Essentially, they needed to change the date in the command line and "that is all."
Except it wasn't "all."
The job, the one that had not changed at all, was failing on a bad parameter. It wasn't running "correctly," it simply wasn't running. Nothing was being processed. The people who had run it the last couple of times were looking at it. They were asking the people who had run it before them. They were looking at the notes and instructions.
They looked to see if "something had changed" that would prevent it from running. They looked at the configuration. The "unhelpful" error message gave them no information or guidance. Then, after several days of fits and starts, a light went on.
"Look. This says {blah blah blah} and has a period inside the quotes. What if we add a period?"
SHAZAM! POOF! A MIRACLE HAPPENED!
The combination of "everyone knows how to do this" and half-remembered meaning and importance of one thong effectively slowed work on this by several calendar days. Instead of sailing through as most people expected, we got hung up on people trusting to half remembered information because the entire team, except for the folks doing this the first time, knew exactly what needed to be done. The entire team knew that "all you had to do was..."
The entire team knew about the documentation. They knew the intent. They knew the "tradition."
They did not remember why.
Ya want an example of this, "tribal knowledge" in a "fun" vein? Go watch "The Lone Ranger" - the one with Johnny Depp as Tonto. All the weird stuff Tonto is telling the Ranger. All the stuff that makes people, including the Ranger, go "huh? what?"
Then, as the Ranger is sitting with the Comanche Elders and says something Tonto had told him. They look at each other and ask "Who told you this?"
The "tribal knowledge" the Ranger got from Tonto was ... accurate only for Tonto's interpretation and world view. No one else had that vision or interpretation. To everyone one else, it was not merely wrong. It was nonsense.
When you are sharing tribal knowledge with other people, how certain are you that you are sharing it accurately? How certain are you that the "why" is being understood?
Is the information you are sharing with other people on testing knowledge, wrong or nonsense?
While the gist was the Winter holidays, Christmas, Hanukkuh, New Year's, etc., they talked about other Holidays as well. The guests being interviewed mentioned how family "traditions" are really, on average, a generation old. People associate doing something for a given Holiday if their family, when they were children, did that thing for the same Holiday. In turn, their children will associate doing what ever their family does for Holidays as "Traditional."
Whilst I was still actively competing in pipe bands and teaching workshops for drumming in pipe bands, I remember a panel discussion with a group of pipers and drummers from the US, Canada, Ireland and Scotland. We were talking about styles of drumming and interpreting music.
We got pulled in two significant directions, both of which I found fascinating and I wish I could have been in a place to take notes. We talked on how things can influence our interpretation of music and how we approach music. We talked about how jazz had influenced great drummers in the pipe band world from the 1940's and 50's. We talked about how emigration from Ireland and Scotland had brought musicians to the US and Canada and how they had taught people what they had learned.
The result was many people and pipe bands in the US and Canada tended to inherit an understanding that was, at best, behind the curve of leaders in the world of pipe band were by the 1960's and 70's. The Legion and Community pipe bands in North America tended to get taught "this is how we did it in..." one of the regiments in the British Army.
This got latched on to as "traditional." The people they taught said the same thing to others they in turn taught.
I remember teaching a band that intended to begin competing some basic technique for bass and tenor drumming. There was a fair amount of resistance because I was teaching them stuff that was "wrong." Their argument was "This is how the British Army does it." I asked which regiment - then pulled out video tapes of the Edinburgh Tattoo, massed Pipes and Drums of the Scottish Division beating retreat and the Scots Guards Trooping the Colours. None of the tenor drummers did anything remotely similar to what they were doing.
Tradition had shifted. Memories had failed as the knowledge was passed on.
Working with some testers a while back there was a problem. The parameters used to run the job they needed run to verify some changes made way up-stream in the process did not seem to be working.
I asked them what they were seeing. They were pretty confused. The people who had worked on this same set of parameters had given them instructions around what to do. Essentially, they needed to change the date in the command line and "that is all."
Except it wasn't "all."
The job, the one that had not changed at all, was failing on a bad parameter. It wasn't running "correctly," it simply wasn't running. Nothing was being processed. The people who had run it the last couple of times were looking at it. They were asking the people who had run it before them. They were looking at the notes and instructions.
They looked to see if "something had changed" that would prevent it from running. They looked at the configuration. The "unhelpful" error message gave them no information or guidance. Then, after several days of fits and starts, a light went on.
"Look. This says {blah blah blah} and has a period inside the quotes. What if we add a period?"
SHAZAM! POOF! A MIRACLE HAPPENED!
The combination of "everyone knows how to do this" and half-remembered meaning and importance of one thong effectively slowed work on this by several calendar days. Instead of sailing through as most people expected, we got hung up on people trusting to half remembered information because the entire team, except for the folks doing this the first time, knew exactly what needed to be done. The entire team knew that "all you had to do was..."
The entire team knew about the documentation. They knew the intent. They knew the "tradition."
They did not remember why.
Ya want an example of this, "tribal knowledge" in a "fun" vein? Go watch "The Lone Ranger" - the one with Johnny Depp as Tonto. All the weird stuff Tonto is telling the Ranger. All the stuff that makes people, including the Ranger, go "huh? what?"
Then, as the Ranger is sitting with the Comanche Elders and says something Tonto had told him. They look at each other and ask "Who told you this?"
The "tribal knowledge" the Ranger got from Tonto was ... accurate only for Tonto's interpretation and world view. No one else had that vision or interpretation. To everyone one else, it was not merely wrong. It was nonsense.
When you are sharing tribal knowledge with other people, how certain are you that you are sharing it accurately? How certain are you that the "why" is being understood?
Is the information you are sharing with other people on testing knowledge, wrong or nonsense?
Saturday, March 7, 2015
What My Dogs Taught Me about Permanence
People who know me, or have seen some of my presentations on testing in an Agile environment, have seen pictures of the cats who live in the house with my me and my dear lady-wife. People who know me, or my lady-wife, a bit better know that we prefer dogs. The cats started to move in a couple of years after our last dog, Rosie, went to Rottweiler-Heaven.
Rosie was a wonderful critter and companion. She would mind the grandkids when they were sleeping. If there was high tension or a chance of what seemed to be violence, she would walk in between the people involved and nudge them away from each other until things calmed down. She weighed 100 pounds and had the strength to move most people, even if they don't really want to move. Slapping was not permitted when she was around.
Anyway. Rosie was a rescue. She came to us when she was not quite two years old. We suspect that part of the "issue" was that this cute little ball of puppy fun turned into a very VERY large dog in short order. The problem was, she was still mostly puppy. Translated - there was a lot of work to do with her, so she would behave in ways that were acceptable, even when we were not home.
We spent a lot of time working with her, training her to act in certain ways. Like, staying out of the garden, both vegetables and flowers. And staying off the furniture. It took a bit to convince her that simply because food, like vegetables draining in a colander, about to go on the dinner table, was NOT fair game, even if she could reach it easily.
There was the time we came home from a Christmas Party and found that the plates of cookies and bars and treats on the dining table had been disturbed, slightly. Looking around, we realized one plate was missing - a paper plate full of cookies my sister had made. These were cookies my paternal grandmother used to make, only for Christmas. Wonderful stuff.
They also smelled differently than any of the other cookies and treats that were set out, waiting for our grandkids to come over that evening.
We found Rosie, and the plate... and the plastic-wrap covering, in the crate she used as a dog-bed (it really was a dog crate for big dogs. her blankets and toys were in there. It was her safe haven - her "lair." So, here was the plastic wrap in front of the crate. The paper plate was in the crate -
Crumbs were everywhere. Apparently, she really enjoyed those cookies. Ah well.
As I was saying, it took a while to train her and get her so she'd be able to please as much as she wanted to.
By the time she was 8 or 9 or so, she knew the boundaries of the yard where she could go, and not. She knew what games were allowed - the type of play - and what were not. We could "call" her by simply whispering her name. Where ever she was, she came at a trot. If we called twice - she ran to us.
We could look at her and she knew what was going on - she'd go stand by her leash to go for a walk. Or, she'd go to the back door so she could go outside with us.
She never did like rain. One time, about this time, we had several days of rain - never seemed to stop. She disliked rain enough where she would not go outside to "do her business" because of it. As we were into the second day of rain, and she had still not gone to "do her business" - I got a large umbrella and took her outside.
She was wary of the idea of being outside when it was raining - then she realized that I was outside - AND NOT GETTING WET! HOW COOL WAS THAT!?!? So, she went out, I held the umbrella over her - and she was much happier after that.
Rottweilers are not long-lived animals. About the time she turned 9, her hips began to hurt. She could not play in the same way she always liked to. We put rubber-backed rugs around for her to lie down on and be comfortable (the house has hardwood floors, no carpeting in most of the rooms.) We gave her different food, food for "old, senior dogs." We found some supplements to give her that helped with her joint pain.
When the grandkids came over, she played like she was 3 again. But then she spent the next several days hurting as a result. We changed her "lair" - checked with the vet and put in a heating pad for cold nights, under her blanket of course.
By the time she was 10 or so, she could walk into the room and look at us and tilt her head in a given way and let us know what she wanted. She rarely barked. We took her on shorter walks. Her muzzle was all white now, not the black it was when she was young.
When she was 11, she quickly went downhill. Slower. She had a hard time getting up and down steps. Then she developed a large lump. Quickly.
We took her to the vet to be tested, but we knew what was going on. She always liked going to the Vet. She always like "going bye-bye in the car." So, he took a sample from the lump and sent it off to a lab. Before we had an answer we knew it was time for her to go on. That last trip to the vet she had a really hard time getting into the van. She whimpered for the first time as we helped her in.
When we got there, she looked up and got out (getting down was easier than up.) We walked in and she nuzzled us, leaned against us, as she always did. We went in with her as she drifted off to sleep that last time. We got home and hung up her collar and leash, put her food and water dishes in the sink to be washed and put away.
We sat down in the living room feeling very sad. My lady-wife said "The problem with dogs is, once they are perfect for the family and perfectly trained, you need to start getting ready to say good-bye. Because they don't live nearly as long as we do. Just as they get to be perfectly trained, it is time for them to go away and leave us."
Last July, I started a new phase in my adventure in testing.
I went to work for a company that was looking for someone to help improve their testing. They were looking for an experienced person who could guide and coach them in how they could do testing better.
In the interview process, the people I met seemed to "get it." They knew they needed help. They knew the company needed help. They knew they did not have the experience or understanding of testing to get beyond very simple, basic ideas.
One of the had the title "Quality Architect" - meaning he was not a tester. He never claimed to be. He, like I am, is a member of ASQ - the American Society for Quality. He was a process hound - but not a model hound. The idea of "best practices" in software was "not a best practice" in his description. There are good ideas, but none of them work all the time.
One was a Manager of Application Services. He had a bunch of diverse groups reporting to him. I was struck that this was a bit like the "Island of Misfit Toys." People with skills that were needed by the organization but did not fit in with a single project development team - or in a tool specific team.
We talked. There was common ground we could work on. There were some differences in views, mostly related to experiences.
I took the gig. It has been a lot of work. (Maybe you noticed how my blog has been less active lately?) It has been good though. My immediate team has been willing to embrace some new ideas and carry them out into the broader community. The Manager has embraced ideas that he initially found challenging - and in talking about them and working through what they could look like at this company, he became a champion to other Managers and Directors.
We built a good working relationship. Quickly. He even came to the local tester meetup on a fairly regular basis.
During the interview process, in the "describe the company and your experiences" discussion, he said he had been there for ... a long time. His role had changed. He had taken on greater responsibilities and challenges. Then he said "The only way I can see myself leaving here is if {Large International Organization Not Known for Software} had an opening I could fill."
That company did. He applied - interviewed - accepted the position.
Just as he was "perfectly trained" - he left. Friday, yesterday, was his last day at the company.
He "moved on." Of course, this was for a new job opportunity and not a "moved on" like Rosie did (or Hilde-beast before her... or Honz before her...) Still he's going on an adventure. Relocation - New City - New State - New Company.
Good luck Brian - Enjoy the new adventure!
I still think my tweet yesterday applies...
Rosie was a wonderful critter and companion. She would mind the grandkids when they were sleeping. If there was high tension or a chance of what seemed to be violence, she would walk in between the people involved and nudge them away from each other until things calmed down. She weighed 100 pounds and had the strength to move most people, even if they don't really want to move. Slapping was not permitted when she was around.
Anyway. Rosie was a rescue. She came to us when she was not quite two years old. We suspect that part of the "issue" was that this cute little ball of puppy fun turned into a very VERY large dog in short order. The problem was, she was still mostly puppy. Translated - there was a lot of work to do with her, so she would behave in ways that were acceptable, even when we were not home.
We spent a lot of time working with her, training her to act in certain ways. Like, staying out of the garden, both vegetables and flowers. And staying off the furniture. It took a bit to convince her that simply because food, like vegetables draining in a colander, about to go on the dinner table, was NOT fair game, even if she could reach it easily.
There was the time we came home from a Christmas Party and found that the plates of cookies and bars and treats on the dining table had been disturbed, slightly. Looking around, we realized one plate was missing - a paper plate full of cookies my sister had made. These were cookies my paternal grandmother used to make, only for Christmas. Wonderful stuff.
They also smelled differently than any of the other cookies and treats that were set out, waiting for our grandkids to come over that evening.
We found Rosie, and the plate... and the plastic-wrap covering, in the crate she used as a dog-bed (it really was a dog crate for big dogs. her blankets and toys were in there. It was her safe haven - her "lair." So, here was the plastic wrap in front of the crate. The paper plate was in the crate -
Crumbs were everywhere. Apparently, she really enjoyed those cookies. Ah well.
As I was saying, it took a while to train her and get her so she'd be able to please as much as she wanted to.
By the time she was 8 or 9 or so, she knew the boundaries of the yard where she could go, and not. She knew what games were allowed - the type of play - and what were not. We could "call" her by simply whispering her name. Where ever she was, she came at a trot. If we called twice - she ran to us.
We could look at her and she knew what was going on - she'd go stand by her leash to go for a walk. Or, she'd go to the back door so she could go outside with us.
She never did like rain. One time, about this time, we had several days of rain - never seemed to stop. She disliked rain enough where she would not go outside to "do her business" because of it. As we were into the second day of rain, and she had still not gone to "do her business" - I got a large umbrella and took her outside.
She was wary of the idea of being outside when it was raining - then she realized that I was outside - AND NOT GETTING WET! HOW COOL WAS THAT!?!? So, she went out, I held the umbrella over her - and she was much happier after that.
Rottweilers are not long-lived animals. About the time she turned 9, her hips began to hurt. She could not play in the same way she always liked to. We put rubber-backed rugs around for her to lie down on and be comfortable (the house has hardwood floors, no carpeting in most of the rooms.) We gave her different food, food for "old, senior dogs." We found some supplements to give her that helped with her joint pain.
When the grandkids came over, she played like she was 3 again. But then she spent the next several days hurting as a result. We changed her "lair" - checked with the vet and put in a heating pad for cold nights, under her blanket of course.
By the time she was 10 or so, she could walk into the room and look at us and tilt her head in a given way and let us know what she wanted. She rarely barked. We took her on shorter walks. Her muzzle was all white now, not the black it was when she was young.
When she was 11, she quickly went downhill. Slower. She had a hard time getting up and down steps. Then she developed a large lump. Quickly.
We took her to the vet to be tested, but we knew what was going on. She always liked going to the Vet. She always like "going bye-bye in the car." So, he took a sample from the lump and sent it off to a lab. Before we had an answer we knew it was time for her to go on. That last trip to the vet she had a really hard time getting into the van. She whimpered for the first time as we helped her in.
When we got there, she looked up and got out (getting down was easier than up.) We walked in and she nuzzled us, leaned against us, as she always did. We went in with her as she drifted off to sleep that last time. We got home and hung up her collar and leash, put her food and water dishes in the sink to be washed and put away.
We sat down in the living room feeling very sad. My lady-wife said "The problem with dogs is, once they are perfect for the family and perfectly trained, you need to start getting ready to say good-bye. Because they don't live nearly as long as we do. Just as they get to be perfectly trained, it is time for them to go away and leave us."
Last July, I started a new phase in my adventure in testing.
I went to work for a company that was looking for someone to help improve their testing. They were looking for an experienced person who could guide and coach them in how they could do testing better.
In the interview process, the people I met seemed to "get it." They knew they needed help. They knew the company needed help. They knew they did not have the experience or understanding of testing to get beyond very simple, basic ideas.
One of the had the title "Quality Architect" - meaning he was not a tester. He never claimed to be. He, like I am, is a member of ASQ - the American Society for Quality. He was a process hound - but not a model hound. The idea of "best practices" in software was "not a best practice" in his description. There are good ideas, but none of them work all the time.
One was a Manager of Application Services. He had a bunch of diverse groups reporting to him. I was struck that this was a bit like the "Island of Misfit Toys." People with skills that were needed by the organization but did not fit in with a single project development team - or in a tool specific team.
We talked. There was common ground we could work on. There were some differences in views, mostly related to experiences.
I took the gig. It has been a lot of work. (Maybe you noticed how my blog has been less active lately?) It has been good though. My immediate team has been willing to embrace some new ideas and carry them out into the broader community. The Manager has embraced ideas that he initially found challenging - and in talking about them and working through what they could look like at this company, he became a champion to other Managers and Directors.
We built a good working relationship. Quickly. He even came to the local tester meetup on a fairly regular basis.
During the interview process, in the "describe the company and your experiences" discussion, he said he had been there for ... a long time. His role had changed. He had taken on greater responsibilities and challenges. Then he said "The only way I can see myself leaving here is if {Large International Organization Not Known for Software} had an opening I could fill."
That company did. He applied - interviewed - accepted the position.
Just as he was "perfectly trained" - he left. Friday, yesterday, was his last day at the company.
He "moved on." Of course, this was for a new job opportunity and not a "moved on" like Rosie did (or Hilde-beast before her... or Honz before her...) Still he's going on an adventure. Relocation - New City - New State - New Company.
Good luck Brian - Enjoy the new adventure!
I still think my tweet yesterday applies...
"Didja ever notice that Managers are a bit like dogs -
get them perfectly trained & it is time for them to go away?"
Subscribe to:
Posts (Atom)
