I just read this amazing blog post by Steve Blank, and felt compelled to share it.
I'll just post a link now, though I suspect my own spin on it may be coming ...
The Difference Between Motion and Action
Tuesday, November 10, 2009
Monday, November 9, 2009
Making Quality a Priority
Here is a quick PowerPoint presentation I think may be useful to some other people, too.
The intended audience is business people or executives who still need a little bit of understanding in what it means for "quality" to be baked into every part of software development, from inception through to release, and in what it takes as a team to have the best collaboration between developers and testers.
Please feel free to use it, modify it, etc. And as always, if you have feedback, let me know!
Wednesday, October 21, 2009
What if you could design your ideal "software creation" plan?
So, a special situation has been presented to me, and I'm going to try to solve it in a collaborative way. It's short notice, but I have what I have, you know?
I've been given an opportunity to develop out a roadmap for ensuring that our very LARGE legacy product heads in the right direction from this point out. Their current focus is apparently centering on the word "stability" Roughly, stability, to them, means that what we have designed our product to do, *works* and is satisfactory to the customer (things like performance cannot be ignored here, for example).
This team (people/process/infrastructure) roughly works on the level of a bunch of unorganized college kids, so there is a lot of room for improvement. They need some fundamentals put in place, for sure -- Automatic builds, CI, unit testing ... (clearly the list goes on from there). Although I specialize in testing, I believe that our executives now understand that "we can't test quality into our product" -- we have to be doing things with quality from the beginning. As I think about all the things this team needs in order to be working in a fashion that does actually move them forward, I want to be sure to optimize such a transition.
I want to hear from others, however, about what *they* would do, if given such an opportunity. I want to brainstorm as a group how people *wish* their teams worked. Let's draw up an ideal "software creation" plan -- beginning to end, all of the pieces.
I have a space available for a physical location, for those who are local. Please send me an email (address at the top right of the blog) for specifics.
I'll be offering a remote-in ability, too. I've created a GoTo meeting that offers both VOIP connection and phone-in connection.
I'll tentatively plan on holding this at 7:00pm EST today, Thursday, October 22 (Sorry! I meant the 22nd!).
1. Please join my meeting.
I've been given an opportunity to develop out a roadmap for ensuring that our very LARGE legacy product heads in the right direction from this point out. Their current focus is apparently centering on the word "stability" Roughly, stability, to them, means that what we have designed our product to do, *works* and is satisfactory to the customer (things like performance cannot be ignored here, for example).
This team (people/process/infrastructure) roughly works on the level of a bunch of unorganized college kids, so there is a lot of room for improvement. They need some fundamentals put in place, for sure -- Automatic builds, CI, unit testing ... (clearly the list goes on from there). Although I specialize in testing, I believe that our executives now understand that "we can't test quality into our product" -- we have to be doing things with quality from the beginning. As I think about all the things this team needs in order to be working in a fashion that does actually move them forward, I want to be sure to optimize such a transition.
I want to hear from others, however, about what *they* would do, if given such an opportunity. I want to brainstorm as a group how people *wish* their teams worked. Let's draw up an ideal "software creation" plan -- beginning to end, all of the pieces.
I have a space available for a physical location, for those who are local. Please send me an email (address at the top right of the blog) for specifics.
I'll be offering a remote-in ability, too. I've created a GoTo meeting that offers both VOIP connection and phone-in connection.
I'll tentatively plan on holding this at 7:00pm EST today, Thursday, October 22 (Sorry! I meant the 22nd!).
1. Please join my meeting.
https://www2.gotomeeting.com/
2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.
Dial 630-869-1014
Access Code: 604-606-915
Audio PIN: Shown after joining the meeting
Meeting ID: 604-606-915
Monday, October 12, 2009
Getting Started with White
I've recently decided to dive into the world of Project White and MS UI Automation, since this is relevant to my current project. I had to create a tutorial for a team to get set up to use white to begin with, so I decided that I could share that tutorial with everyone else as well. It goes into some detail about Visual Studio as well, and is intended for an audience that has not necessarily done automated testing through Visual Studio before.
The tutorial uses MS Visual Studio, C#, White, and UI Spy to create an *extremely* simple test. My intent was just to show how to set it up. Next time, I will describe starting to write tests, including common functions in White and writing good tests.
Please, please offer feedback. I would love to be sure that I am doing things the best way possible!
White Tutorial
The tutorial uses MS Visual Studio, C#, White, and UI Spy to create an *extremely* simple test. My intent was just to show how to set it up. Next time, I will describe starting to write tests, including common functions in White and writing good tests.
Please, please offer feedback. I would love to be sure that I am doing things the best way possible!
White Tutorial
Wednesday, October 7, 2009
*be the worst*
Huh? Did I just say "be the worst"? Yep, I sure did. But before you go telling your boss that I told you to be the worst tester you can be, let me finish the phrase!
First and foremost, I have to give credit where credit is due. I saw this phrase first from Chris McMahon -- he says that this meme has been around the music business for a long time. He credits Pat Metheny, who said, "...try to be the worst guy in whatever band you're in. That's the secret."
Given the context, what I am saying is "be the worst of the people you are surrounded by", or "surround yourself with really great people."
At Agile 2009, someone told me that Elisabeth Hendrickson decided to learn by inserting herself into the best teams she could find. Even before I encountered the "be the worst" quote, I had begun bouncing around the idea of how I perceive myself versus those I work with.
I think back to an early job in my career, straight out of college. At this place, I remember thinking to myself with some frequency, "These people are *SO* *SMART*! I feel SO DUMB when I am around them!" I often tried to just keep up with conversation, hoping to fake it long enough to avoid appearing dumb, too! Looking back, how I wish I could have gotten over my own insecurity and taken the opportunity for exactly the opportunity it was! What I should have been thinking was "Wow, these people are *SO* *SMART*! I want to learn everything I *can* from them!"
What can we get out of "being the worst", and why would anyone suggest that?
I think we can get a *lot* out of it: learning, experience, growth ... In working with people who have a set of skills that you wish to expand for yourself, you can see first-hand, on a day-to-day basis, and under a whole slew of circumstances how that quality is manifested. Sometimes it might be a technical skill. Maybe it's a communication skill.
As I have grown in my career, I have begun to feel like the "dumb one" less and less. I think that my passion to get better and better at the things I want to be good at, have made it more and more difficult for me to *be the worst*. What have I done in response?
I've become *way* more active in the agile community. In that way, I can surround myself (though not as frequently as I would like) with those people I see as *way* more skilled than I am in certain things. I found this out with certainty at Agile 2009. I love talking to Elisabeth Hendrickson for her insight into agile testing and human relationships at work. I enjoy Lisa Crispin's company for her amazing ability to be a great agile tester, without falling back on programming the hard things (like I do!). I met Patrick Wilson-Welsh, and admired his passion, sense of humor, and ideas on good, clean TDD. I had conversations with Michael Feathers and Bob Martin to try to gain some insight into my specific legacy code issues. I had great conversations with Antony Marcano and Andy Palmer about testing tools and frameworks. I *pair programmed* with Abby Fichtner to gain from her development experience. Of course, there were many others ....
In this way, I forged relationships and surrounded myself in a way that I could *be the worst*. I'll keep saving my pennies to go to conferences and keep being active in the agile community so that I can keep *being the worst*.
Do others try to put themselves into situations where they can *be the worst*? How do you keep yourself always learning and always surrounded by those you can learn from?
First and foremost, I have to give credit where credit is due. I saw this phrase first from Chris McMahon -- he says that this meme has been around the music business for a long time. He credits Pat Metheny, who said, "...try to be the worst guy in whatever band you're in. That's the secret."
Given the context, what I am saying is "be the worst of the people you are surrounded by", or "surround yourself with really great people."
At Agile 2009, someone told me that Elisabeth Hendrickson decided to learn by inserting herself into the best teams she could find. Even before I encountered the "be the worst" quote, I had begun bouncing around the idea of how I perceive myself versus those I work with.
I think back to an early job in my career, straight out of college. At this place, I remember thinking to myself with some frequency, "These people are *SO* *SMART*! I feel SO DUMB when I am around them!" I often tried to just keep up with conversation, hoping to fake it long enough to avoid appearing dumb, too! Looking back, how I wish I could have gotten over my own insecurity and taken the opportunity for exactly the opportunity it was! What I should have been thinking was "Wow, these people are *SO* *SMART*! I want to learn everything I *can* from them!"
What can we get out of "being the worst", and why would anyone suggest that?
I think we can get a *lot* out of it: learning, experience, growth ... In working with people who have a set of skills that you wish to expand for yourself, you can see first-hand, on a day-to-day basis, and under a whole slew of circumstances how that quality is manifested. Sometimes it might be a technical skill. Maybe it's a communication skill.
As I have grown in my career, I have begun to feel like the "dumb one" less and less. I think that my passion to get better and better at the things I want to be good at, have made it more and more difficult for me to *be the worst*. What have I done in response?
I've become *way* more active in the agile community. In that way, I can surround myself (though not as frequently as I would like) with those people I see as *way* more skilled than I am in certain things. I found this out with certainty at Agile 2009. I love talking to Elisabeth Hendrickson for her insight into agile testing and human relationships at work. I enjoy Lisa Crispin's company for her amazing ability to be a great agile tester, without falling back on programming the hard things (like I do!). I met Patrick Wilson-Welsh, and admired his passion, sense of humor, and ideas on good, clean TDD. I had conversations with Michael Feathers and Bob Martin to try to gain some insight into my specific legacy code issues. I had great conversations with Antony Marcano and Andy Palmer about testing tools and frameworks. I *pair programmed* with Abby Fichtner to gain from her development experience. Of course, there were many others ....
In this way, I forged relationships and surrounded myself in a way that I could *be the worst*. I'll keep saving my pennies to go to conferences and keep being active in the agile community so that I can keep *being the worst*.
Do others try to put themselves into situations where they can *be the worst*? How do you keep yourself always learning and always surrounded by those you can learn from?
Monday, October 5, 2009
Does having a separate maintenance team hurt efforts toward accountability?
I was recently thinking about a situation that puzzled me, and came to a realization that makes me a bit nervous ....
I have had exposure to some teams where even though they are in firefighting mode more often that is comfortable, and/or even though their customers are unhappy, and/or even though their software has a *lot* of bugs, they still don't seem to "get it" and try to do things in a better way.
I have sat, baffled, looking at people who lead these teams, my jaw on the floor, wondering why the people leading these teams are passing the buck on the team's responsibility for problems, and instead presenting a magic show to prove why the problem is not theirs.
And today, something hit me: I was thinking about what would cause someone to change; what would make it so that they finally felt the need to do something different, and the term "the wall of pain" came to mind. This term comes from a blog post I read a few months ago, "Fighting Technical Debt with the Wall of Pain". What would instigate change? Enough pain that it feels necessary, in order to escape the pain.
This reminds me of Parenting 101: How do I stop my 12-year-old from making irresponsible decisions? I make them painful enough that he will be sure to avoid the pain. Luckily, these days that is as easy as "Oops! Your PSP ran away! I can't find it!", or "Where are your Playstation controllers? Gee, I don't know ... I guess maybe they will return when you start doing the chores that you are responsible for."
BUT ... BUT ... what about companies where the new development team is a separate entity from a maintenance team? What if the developers who are writing new code are sheltered and protected from the results of poorly written code? In some cases, it goes something like this:
- Development team writes software ... Maybe they fix a few bugs along the way. Sometimes, if bugs come up and it can be proven that they existed in previously written code, they may shrug them off as not the result of current work, so not their problem right now.
- Development team's schedule gets squished, and as it gets closer to release time, only the *most* important bugs that are proven to be the result of their current work, are even looked at by the team.
- Release happens. At this point, product is a released product, and the workflow now looks like this:
- Customer has an issue, customer calls Support. Support tries to reproduce it, and if they can, they file a bug. Bug gets reported to Maintenance team, and they work on it.
In the above scenario (which exists in some companies), the team that originally wrote the aforementioned poorly written code never sees the wall of pain. Seriously, for the most part, there is absolutely zero repercussion to them directly for bad code.
In a case like this, the responsibility for well-written code falls upon those who are internally motivated to do their best, and strong enough personalities that they fight the push to get *something* out *faster*, well-written or not. I believe that this type of personality does not describe the majority, and the whole team falls into a pattern of continuing to write poorly written code. What is there to stop them?
Has anyone had any experience helping a team to transition into a more agile-like process from a situation that looked like this one? How do companies like this adjust to fight this pattern?
I wonder if it would help to break up the idea of "new dev" versus "maintenance" teams, and instead cross-pollinate into functional teams. In this case, there would be a team for one specific module, component, or module, and they would handle both new work and bug fixing/maintenance. Would this strategy work?
I have had exposure to some teams where even though they are in firefighting mode more often that is comfortable, and/or even though their customers are unhappy, and/or even though their software has a *lot* of bugs, they still don't seem to "get it" and try to do things in a better way.
I have sat, baffled, looking at people who lead these teams, my jaw on the floor, wondering why the people leading these teams are passing the buck on the team's responsibility for problems, and instead presenting a magic show to prove why the problem is not theirs.
And today, something hit me: I was thinking about what would cause someone to change; what would make it so that they finally felt the need to do something different, and the term "the wall of pain" came to mind. This term comes from a blog post I read a few months ago, "Fighting Technical Debt with the Wall of Pain". What would instigate change? Enough pain that it feels necessary, in order to escape the pain.
This reminds me of Parenting 101: How do I stop my 12-year-old from making irresponsible decisions? I make them painful enough that he will be sure to avoid the pain. Luckily, these days that is as easy as "Oops! Your PSP ran away! I can't find it!", or "Where are your Playstation controllers? Gee, I don't know ... I guess maybe they will return when you start doing the chores that you are responsible for."
BUT ... BUT ... what about companies where the new development team is a separate entity from a maintenance team? What if the developers who are writing new code are sheltered and protected from the results of poorly written code? In some cases, it goes something like this:
- Development team writes software ... Maybe they fix a few bugs along the way. Sometimes, if bugs come up and it can be proven that they existed in previously written code, they may shrug them off as not the result of current work, so not their problem right now.
- Development team's schedule gets squished, and as it gets closer to release time, only the *most* important bugs that are proven to be the result of their current work, are even looked at by the team.
- Release happens. At this point, product is a released product, and the workflow now looks like this:
- Customer has an issue, customer calls Support. Support tries to reproduce it, and if they can, they file a bug. Bug gets reported to Maintenance team, and they work on it.
In the above scenario (which exists in some companies), the team that originally wrote the aforementioned poorly written code never sees the wall of pain. Seriously, for the most part, there is absolutely zero repercussion to them directly for bad code.
In a case like this, the responsibility for well-written code falls upon those who are internally motivated to do their best, and strong enough personalities that they fight the push to get *something* out *faster*, well-written or not. I believe that this type of personality does not describe the majority, and the whole team falls into a pattern of continuing to write poorly written code. What is there to stop them?
Has anyone had any experience helping a team to transition into a more agile-like process from a situation that looked like this one? How do companies like this adjust to fight this pattern?
I wonder if it would help to break up the idea of "new dev" versus "maintenance" teams, and instead cross-pollinate into functional teams. In this case, there would be a team for one specific module, component, or module, and they would handle both new work and bug fixing/maintenance. Would this strategy work?
Friday, September 25, 2009
Work to make a company successful, or work for a successful company?
Once in a while, I think we all find some statement we read somewhere, while doing something, that sticks with us. I have *definitely* found that to be true very recently, mostly because it puts into words a concept that has rolled around in my head for quite some time.
First, some background .... If you read my blog, then you know that I have been known to rant, at times. Really, I try not to, but it happens. Sometimes, it is just that I want *so badly* for others to change, and I have a hard time understanding why people don't just *do* things the best way, all the time. Often, when I find others to talk through the issues I am encountering, they ask me questions like "Why do you still work for that place! It's hopeless!" (Sometimes, I believe it is, and I leave, as I did in 2008.)
Sometimes, however, I stick around for a while, and I have a hard time explaining why. And then, recently, I saw a sentence that resonated with me.
Twitter was all abuzz recently with responses to Joel Spolsky's recent blog about "The Duct Tape Programmer". He quotes Jamie Zawinski, and Elisabeth Hendrickson (@testobsessed) pulled out Zawinski's resignation letter from AOL.
This one quote resonated with me, and continued bouncing around in my head:
"...you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company."
It rolled around in my head for a few days .... Did I agree? Did I think that people could generally be so easily divided up into just those 2 groups? Probably not quite *that* easily, but for many people that I have encountered in my career, I could place most of them into one of those pretty quickly.
For a while, I have described these groups in the following way: people either seem to come to work because it's a job, and they do their job, and that's it, OR they seem to be really passionate about *what* they do, and are constantly striving to make things better. I fall into the latter of those 2 categories. I most certainly do what I love and love what I do.
But Jamie's sentence looked at things from just a slightly different point of view, and after thinking about it for a bit, I believe, describes *me* just a little bit better. I have *always* wanted to work to make things great, and not so much wanted to work for/with/on things that were *already* great.
This can be applied to many aspects of my life. I was the single mom who put herself through college, working full-time and taking full-time classes in CompSci. I am the vocal advocate of a high functioning autistic child who wrote to the local newspapers when the school district was failing at its job. I chose to bring a Siberian Husky into my home (this sounds silly, but Husky owners will tell you .... WOW).
I THRIVE ON THE CHALLENGE.
That's it, that's me. That's why I like testing over development. I have said for years that developers have to find one way to solve a problem and testers have to find ALL ways to un-solve the problem. Testing gives me the challenge of being creative, being technical, being analytical, speaking in at least 2 different languages, juggling an obscene number of balls in the air and being squeezed and sometimes disrespected along the way. But, it's a challenge, and I like a challenge.
In the same way, companies that are struggling, companies that don't "get it", and have fallen into the proven patterns that destroy great ideas, are a CHALLENGE. They are high-risk, for sure, and sometimes they offer little reward other than knowing I am doing my best, but *if* I can affect change, *if* I can help, the reward is incredible.
I believe that for "successful" companies (I place "successful" in quotes because this is a relative term .... for me, in this context, it is mostly about doing things the best way possible), I would personally gain little reward because there would not be *enough* of a challenge.
I wonder, then ... how many other great testers that I know are like-minded? Do other people enjoy testing because they enjoy a challenge? Would they generally choose to work to make a company successful, or choose to work for a successful company?
First, some background .... If you read my blog, then you know that I have been known to rant, at times. Really, I try not to, but it happens. Sometimes, it is just that I want *so badly* for others to change, and I have a hard time understanding why people don't just *do* things the best way, all the time. Often, when I find others to talk through the issues I am encountering, they ask me questions like "Why do you still work for that place! It's hopeless!" (Sometimes, I believe it is, and I leave, as I did in 2008.)
Sometimes, however, I stick around for a while, and I have a hard time explaining why. And then, recently, I saw a sentence that resonated with me.
Twitter was all abuzz recently with responses to Joel Spolsky's recent blog about "The Duct Tape Programmer". He quotes Jamie Zawinski, and Elisabeth Hendrickson (@testobsessed) pulled out Zawinski's resignation letter from AOL.
This one quote resonated with me, and continued bouncing around in my head:
"...you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company."
It rolled around in my head for a few days .... Did I agree? Did I think that people could generally be so easily divided up into just those 2 groups? Probably not quite *that* easily, but for many people that I have encountered in my career, I could place most of them into one of those pretty quickly.
For a while, I have described these groups in the following way: people either seem to come to work because it's a job, and they do their job, and that's it, OR they seem to be really passionate about *what* they do, and are constantly striving to make things better. I fall into the latter of those 2 categories. I most certainly do what I love and love what I do.
But Jamie's sentence looked at things from just a slightly different point of view, and after thinking about it for a bit, I believe, describes *me* just a little bit better. I have *always* wanted to work to make things great, and not so much wanted to work for/with/on things that were *already* great.
This can be applied to many aspects of my life. I was the single mom who put herself through college, working full-time and taking full-time classes in CompSci. I am the vocal advocate of a high functioning autistic child who wrote to the local newspapers when the school district was failing at its job. I chose to bring a Siberian Husky into my home (this sounds silly, but Husky owners will tell you .... WOW).
I THRIVE ON THE CHALLENGE.
That's it, that's me. That's why I like testing over development. I have said for years that developers have to find one way to solve a problem and testers have to find ALL ways to un-solve the problem. Testing gives me the challenge of being creative, being technical, being analytical, speaking in at least 2 different languages, juggling an obscene number of balls in the air and being squeezed and sometimes disrespected along the way. But, it's a challenge, and I like a challenge.
In the same way, companies that are struggling, companies that don't "get it", and have fallen into the proven patterns that destroy great ideas, are a CHALLENGE. They are high-risk, for sure, and sometimes they offer little reward other than knowing I am doing my best, but *if* I can affect change, *if* I can help, the reward is incredible.
I believe that for "successful" companies (I place "successful" in quotes because this is a relative term .... for me, in this context, it is mostly about doing things the best way possible), I would personally gain little reward because there would not be *enough* of a challenge.
I wonder, then ... how many other great testers that I know are like-minded? Do other people enjoy testing because they enjoy a challenge? Would they generally choose to work to make a company successful, or choose to work for a successful company?
Subscribe to:
Posts (Atom)