I've just read a great article from Gartner Resources on hiring the right IT personnel. It speaks of the dangers that hiring managers encounter when they focus on technical expertise without considering the abilities of the individual's ability to learn, ramp up and contribute to the overall business.
My first entry regarded how to discern technical depth. Gartner addresses how important technical depth should be when hiring. When you are examining a resume and interviewing a candidate, look for their accomplishments, especially as it relates to their previous job. How did they adjust to the new job? How quickly did they make an impact? How different was the new job to the previous job? This can give you a sense of how well someone will adjust to your environment. It can also be something to consider when you are thinking of moving someone within your organization to a new organization. Or filling a new position. Do you need to look outside? Or is there someone inside that loves a new challenge -- and most importantly, succeeds at it.
Friday, June 27, 2008
Thursday, June 19, 2008
Motivation
I recently received one of those lovely (and I mean that) emails that tells you you're special. Like most of them, however, it's only goal seems to be propagation. This one goes something like this:
"If you've received this, it is because someone cares for you...
So please, tell the people you love and care for, before it is too late.
Though it purports to praise, the receiver gets the message that they don't do nice things because they are too busy.
Now, what if, instead, it said this:
"So please, tell the people you love and care for, before it is too late.
The more people that you send this to, the better you'll be at reaching out to those you care about. "
How does this relate to quality? Because quality software is not just about the end product, but the motivation to create quality software. Many of these emails touch us because we need to know that people appreciate us. In the case of software development, those with the responsibility of making the schedules and testing the software need to be aware of the impact of 'how' they communicate to those who create the software.
Next time a project manager is determining the schedule for the next release, avoid phrases like 'never hits the date anyway' and 'It is just a minor addition'. (I have a whole list of forbidden words I'll post soon.) Next time a tester needs to report a bug, listen for the developer's response and tailor the next test and report for how the developer receives your communication.
I have seen teams with a reputation of chronically late delivery and bug laden code turned around because of good communication.
Just remember to avoid compliments that have threats and putdowns imbedded in them - undoing the good that they are intended to accomplish. These insidious messages wear us down. Who knows? Maybe they account for the industry statistic of computer professionals changing jobs every 3 years. Doesn't that lead to a brain drain, denying us the quality of someone very knowledgeable staying with the product?
"If you've received this, it is because someone cares for you...
So please, tell the people you love and care for, before it is too late.
If you do not send it, you will have, once again passed up the opportunity to do something nice and beautiful. If you're 'too busy' to take those few minutes..."
Though it purports to praise, the receiver gets the message that they don't do nice things because they are too busy.
Now, what if, instead, it said this:
"So please, tell the people you love and care for, before it is too late.
The more people that you send this to, the better you'll be at reaching out to those you care about. "
How does this relate to quality? Because quality software is not just about the end product, but the motivation to create quality software. Many of these emails touch us because we need to know that people appreciate us. In the case of software development, those with the responsibility of making the schedules and testing the software need to be aware of the impact of 'how' they communicate to those who create the software.
Next time a project manager is determining the schedule for the next release, avoid phrases like 'never hits the date anyway' and 'It is just a minor addition'. (I have a whole list of forbidden words I'll post soon.) Next time a tester needs to report a bug, listen for the developer's response and tailor the next test and report for how the developer receives your communication.
I have seen teams with a reputation of chronically late delivery and bug laden code turned around because of good communication.
Just remember to avoid compliments that have threats and putdowns imbedded in them - undoing the good that they are intended to accomplish. These insidious messages wear us down. Who knows? Maybe they account for the industry statistic of computer professionals changing jobs every 3 years. Doesn't that lead to a brain drain, denying us the quality of someone very knowledgeable staying with the product?
Thursday, June 12, 2008
Symbiosis - Making the Clever Beautiful
In one of my recent posts, I may have left the impression that OpenSource doesn't greatly enhance our software experience. But that's just not true. OpenSource is a great place to innovate and discover how to fulfill the needs of the software user. The initial OpenSource software is normally quite technical and clever, and one of the reasons I started this blog is that software pervades our life, and the true benefits of innovation are realized as it enters mainstream use. For that, the clever must be made beautiful.
So why did I title this symbiosis? I read a great article in Make magazine called "Make Like Picasso". It says that Picasso said that when you first make complicated things, they are ugly, and someone follows who makes them pretty. The article goes on: "functionally clever things deserve to be pretty". And I agree. I believe that we need symbiosis to achieve that.
Symbiosis is more than a complementary relationship. Two are dependent on one another. Without both, each fails.
Some of our best innovations have failed when this is not understood. In order to be successful, General Motor's original electric car, the EV1, needed California to pass a law that they were necessary. This happened. Further, the car needed to be useful to the public. This happened. Then GM needed to continue to find value in the car, expand it to the rest of the states and other markets. This didn't happen.
The Greeks believed that you could determine beauty through the Golden Ratio. With the Golden Ratio you can measure harmony. Harmony requires balance.
After the initial roll out of the EV1, GM did not have the same level of commitment to its success as the users. Balance did not exist. Without it, symbiosis did not exist. Without that, the EV1 failed. What that meant was that instead of GM being ahead of everyone as this gas crisis has hit, we have had limited choices in auto alternatives. Neither of us has been as successful as we could have been.
In contrast, as Open Source, and the Linux operating system especially, became more popular, companies like Red Hat understood that a partnership was needed to allow the mainstream to achieve the full benefits of Open Source. Software development is benefiting greatly from the symbiosis relationships developing between Open Source innovation and its application.
So why did I title this symbiosis? I read a great article in Make magazine called "Make Like Picasso". It says that Picasso said that when you first make complicated things, they are ugly, and someone follows who makes them pretty. The article goes on: "functionally clever things deserve to be pretty". And I agree. I believe that we need symbiosis to achieve that.
Symbiosis is more than a complementary relationship. Two are dependent on one another. Without both, each fails.
Some of our best innovations have failed when this is not understood. In order to be successful, General Motor's original electric car, the EV1, needed California to pass a law that they were necessary. This happened. Further, the car needed to be useful to the public. This happened. Then GM needed to continue to find value in the car, expand it to the rest of the states and other markets. This didn't happen.
The Greeks believed that you could determine beauty through the Golden Ratio. With the Golden Ratio you can measure harmony. Harmony requires balance.
After the initial roll out of the EV1, GM did not have the same level of commitment to its success as the users. Balance did not exist. Without it, symbiosis did not exist. Without that, the EV1 failed. What that meant was that instead of GM being ahead of everyone as this gas crisis has hit, we have had limited choices in auto alternatives. Neither of us has been as successful as we could have been.
In contrast, as Open Source, and the Linux operating system especially, became more popular, companies like Red Hat understood that a partnership was needed to allow the mainstream to achieve the full benefits of Open Source. Software development is benefiting greatly from the symbiosis relationships developing between Open Source innovation and its application.
Monday, June 9, 2008
Finding design flaws
When it comes to quality software, sometimes it isn't immediately apparent that the quality has a flaw. It seems to work. It does what we need it to do. In fact, we're pretty happy with our software. Right up until the point that it has become integral to our lives, and it stops working. In this case, I"m talking about the underlying systems.
Security software, print drivers, disk drivers, document readers. Most of these pieces of software are written not to be noticed. And they do their jobs pretty well. And for them, we only notice them when they fail. And when they do, it can have a big impact.
In this entry, you'll find 7 principles for addressing design flaws for better quality.
The bridge collapse in Minneapolis was the result of a design flaw, they said. Budgets weren't put in place to address critical flaws once they had been discovered. The infrastructure of any country needs to be reliable, and unnoticed. And that costs money.
As software impacts more and more of our lives, the same level of rigor that used to go into evaluating our infrastructure needs to go into our software.
Borrowing from the discipline of building a bridge, infrastructure software design must be measured against standards and evaluated by independent experts who sign off on the design. Now it is reasonable to consider cost impact when evaluating designs. But as this article suggests, cost impact is weighed within the context of the design goals.
Where I live, the investigation into Boston Big Dig's tunnel failure cited: poor design specifications, paying contractors to test improperly installed anchor bolts and lack of consultation with tunnel designers before allowing contractors to drill through steel reinforcements in the tunnel roof.
What it identifies is three places where you can find design flaws:
1. review design specifications
2. use the proper test procedures
3. consult with original designers before making design changes
To these can be added lessons from the bridge collapse:
4. review old designs based on new information
5. identify time criticality for corrective action
6. budget for corrective action
7. publish findings
Security software, print drivers, disk drivers, document readers. Most of these pieces of software are written not to be noticed. And they do their jobs pretty well. And for them, we only notice them when they fail. And when they do, it can have a big impact.
In this entry, you'll find 7 principles for addressing design flaws for better quality.
The bridge collapse in Minneapolis was the result of a design flaw, they said. Budgets weren't put in place to address critical flaws once they had been discovered. The infrastructure of any country needs to be reliable, and unnoticed. And that costs money.
As software impacts more and more of our lives, the same level of rigor that used to go into evaluating our infrastructure needs to go into our software.
Borrowing from the discipline of building a bridge, infrastructure software design must be measured against standards and evaluated by independent experts who sign off on the design. Now it is reasonable to consider cost impact when evaluating designs. But as this article suggests, cost impact is weighed within the context of the design goals.
Where I live, the investigation into Boston Big Dig's tunnel failure cited: poor design specifications, paying contractors to test improperly installed anchor bolts and lack of consultation with tunnel designers before allowing contractors to drill through steel reinforcements in the tunnel roof.
What it identifies is three places where you can find design flaws:
1. review design specifications
2. use the proper test procedures
3. consult with original designers before making design changes
To these can be added lessons from the bridge collapse:
4. review old designs based on new information
5. identify time criticality for corrective action
6. budget for corrective action
7. publish findings
Monday, June 2, 2008
Expectations
A great deal of quality can relate to expectations. For example, I recently visited a new "New York Style Deli". Now, for anyone who has been to New York City, the deli could be expected to have fresh bagels, rolls and breads, a wide variety of cold cuts and hot meats, peppers, etc. all able to be put together quickly. Often, you can see what you are going to be getting. Apparently, the people who named this place had never been to a New York Deli. We found a display case with some bagels in plastic bags, obviously purchased from somewhere, the cooks not in sight, and a menu that didn't have all the items or prices. Hmmm.
As you might expect, the prices and food weren't that great either. When a customer makes a decision to buy something, it is based on what they might reasonably expect to get. In software, we talk about 'managing expectations', which normally translates into schedules, but I'm talking about actual quality expectations. What do I want, and will I get what I want? So, let's eliminate 'when' for a second.
And let's not even go to the fine print type of thing ("no setup required." "works out of the box.")Because there is meaning that can convey not just a feature, but an entire experience. What do you think of when you get a product from Apple Computers, for example. Ok, in that case, you do expect the "no setup required".
Here's another example. What do you think when you see this ad with the bathtubs outside? I'll tell you what I think. How can they possibly accomplish what the drug maker says is the purpose of the drug? Don't have your customers thinking that.
They can't be thinking "this isn't what it purports to be", nor can they be thinking "but I can't do what I want to do if it works this way." One of the biggest challenges for quality software is knowing what you really want to make and whether you can indeed make it work. And that is more than just a list of requirements. It requires seeing the picture and keeping it in mind while developing the product.
As you might expect, the prices and food weren't that great either. When a customer makes a decision to buy something, it is based on what they might reasonably expect to get. In software, we talk about 'managing expectations', which normally translates into schedules, but I'm talking about actual quality expectations. What do I want, and will I get what I want? So, let's eliminate 'when' for a second.
And let's not even go to the fine print type of thing ("no setup required." "works out of the box.")Because there is meaning that can convey not just a feature, but an entire experience. What do you think of when you get a product from Apple Computers, for example. Ok, in that case, you do expect the "no setup required".
Here's another example. What do you think when you see this ad with the bathtubs outside? I'll tell you what I think. How can they possibly accomplish what the drug maker says is the purpose of the drug? Don't have your customers thinking that.
They can't be thinking "this isn't what it purports to be", nor can they be thinking "but I can't do what I want to do if it works this way." One of the biggest challenges for quality software is knowing what you really want to make and whether you can indeed make it work. And that is more than just a list of requirements. It requires seeing the picture and keeping it in mind while developing the product.
Subscribe to:
Posts (Atom)