In my previous post on software quality, I talked about how quality has an indirect, nevertheless beneficial effect on costs and time.
Now I want to continue with the next most important factor of a project, that is the most important from the customer's perspective.
(Functionality) How improved quality helps to deliver better functionality? Interestingly enough, asking that question is already the first part of answering it. Really, there is no magic answer here: it's plain to see, that once you concentrate on quality from day one you will deliver better functionality. Your testers can focus on usabilty instead of checking and tracking trivial bugs and scenarios. Instead of the i-click-here-and-it-crahses type of bugs, you will get more of the it's difficult-to-find-that-menu-item or this-messagebox-makes-no-sense kind of bugs. Your customer also can effectively participate in the developing process, once he's not stuck trying to only install and start your program. In short it's similar to the Maslow for Programmers, but on the project's scale. If customers, product managers, developers and testers don't have to spend precious time on finding, documenting and fixing trivial bugs, they all of a sudden have time for something else, and unless they hooked up on porn beyond the avarage amount they can spend it on creating software of real value.
(Developer Team)And last but not least, I'd like to mention DeMarco's take on quality. He advocates that quality is more important for the dev team, than anyone else involved in the project. It's for the programmers' self-esteem. If you deliver quality software as a rule, you can be proud of every day's work. If you are proud, you can and want to take credit, if you take credit, you will be even more motivated to deliver quality. It's a positive feedback loop, but according to Wikipedia, it's not a bad thing:
"Positive feedback amplifies possibilities of divergences; it is the condition to change, evolution, growth; it gives the system the ability to access new points of equilibrium." It also helps team culture, and creates an atmosphere where the constant urge to improve is a common and selfexplaining thing.
Read full post...
Thursday, 8 April 2010
Sunday, 4 April 2010
Quality: another agile buzzword?
Agile literature is full of explanations and techniques as of how to improve software quality. There is lot less talk about why quality is important in the first place. Even K. Beck goes only so far that quality improves trust, and that with trust everything is more simple.
I think an important issue is rarely or never addressed. The fact that users and customers don't seem to care about quality all that much.
As DeMarco puts it, if you present to your client that the software right now has a Mean Time Between Failures of 1.2 hours, and with three extra weeks of work you could reach an MTBF as high as 2000 hours, then after some hemming and hawing "the users will explain that they are as quality-conscious as the next fellow, but three weeks is real money." [1]
This is another classic example of why software industry has way less in common with more traditional industries(cars, architecture, etc) than we've been told. What is quality in other areas, if not the longevity of things? One considers a car or a watch of good quality if it lasts long without the need of repair. Well, in that sense software is always perfect, you can use it as much as you want its parts won't break or fray. Of course there is a minimum quality required, but only to the extent that poor quality doesn't render the software utterly useless, and anything above that is a bonus, that clients aren't willing to pay for.
So why are agile teams so hung up on quality then? - Well, you should ask them, but my guess is that they don't know. [if you are in agile development take a minute here and try to answer that]
I get back to that in a minute, but first I'd like to point out, that when selling your agile methodolgy to your clients, quality shouldn't be high on your list of arguments, or not at all. Quality 'per se' has little to no value to your clients. What you should try instead is to explain to them, how quality will be beneficial for the factors that they do care about, i.e. costs and time and functionality.
(Costs and time) The cost of a software in general is made up of two - not all that independent - parts: development and maintenance. It is easy to see that improved quality brings the cost of maintenance to a minimum. But what's often overlooked, that quality doesn't increase the cost of development in turn. In fact, many times it lowers that too. How is this possible? You just need to recall all the times when you were happily coding away and away, until all of sudden you hit a wall, a wall made of all sorts of different "materials": badly designed, badly laid out code; bugs hiding other bugs that have been lurking around for months only to surface at the worst time possible; performance issues that can only be resolved by completely restructuring your code which - now that you think about it - doesn't really have a structure; endless email/bugtracking ping-pong, between you and the test department; so on and so forth. That is the moment, when development cost and time estimates go out the window, and unfortunately this moment comes almost always nearing the end of the project when it is no more possible to rethink scope, deadline or effort.
I'm not saying that quality is a silver bullet, and that you will never hit a wall with agile, but I can say with confidence, that
a) chances of hitting a wall are much lower
b) even when you hit a wall, it's less dense (is made up of fewer things)
c) and the end of the project is typically not near at all
I'm saying that if you constantly strive for quality the inevitable walls of software development will become more like bumps. And that's your selling argument right there.
[Next time I'll talk about the third factor (functionality), as well as why quality is important for the developer team.]
[1] DeMarco - Lister: Peopleware
Read full post...
I think an important issue is rarely or never addressed. The fact that users and customers don't seem to care about quality all that much.
As DeMarco puts it, if you present to your client that the software right now has a Mean Time Between Failures of 1.2 hours, and with three extra weeks of work you could reach an MTBF as high as 2000 hours, then after some hemming and hawing "the users will explain that they are as quality-conscious as the next fellow, but three weeks is real money." [1]
This is another classic example of why software industry has way less in common with more traditional industries(cars, architecture, etc) than we've been told. What is quality in other areas, if not the longevity of things? One considers a car or a watch of good quality if it lasts long without the need of repair. Well, in that sense software is always perfect, you can use it as much as you want its parts won't break or fray. Of course there is a minimum quality required, but only to the extent that poor quality doesn't render the software utterly useless, and anything above that is a bonus, that clients aren't willing to pay for.
So why are agile teams so hung up on quality then? - Well, you should ask them, but my guess is that they don't know. [if you are in agile development take a minute here and try to answer that]
I get back to that in a minute, but first I'd like to point out, that when selling your agile methodolgy to your clients, quality shouldn't be high on your list of arguments, or not at all. Quality 'per se' has little to no value to your clients. What you should try instead is to explain to them, how quality will be beneficial for the factors that they do care about, i.e. costs and time and functionality.
(Costs and time) The cost of a software in general is made up of two - not all that independent - parts: development and maintenance. It is easy to see that improved quality brings the cost of maintenance to a minimum. But what's often overlooked, that quality doesn't increase the cost of development in turn. In fact, many times it lowers that too. How is this possible? You just need to recall all the times when you were happily coding away and away, until all of sudden you hit a wall, a wall made of all sorts of different "materials": badly designed, badly laid out code; bugs hiding other bugs that have been lurking around for months only to surface at the worst time possible; performance issues that can only be resolved by completely restructuring your code which - now that you think about it - doesn't really have a structure; endless email/bugtracking ping-pong, between you and the test department; so on and so forth. That is the moment, when development cost and time estimates go out the window, and unfortunately this moment comes almost always nearing the end of the project when it is no more possible to rethink scope, deadline or effort.
I'm not saying that quality is a silver bullet, and that you will never hit a wall with agile, but I can say with confidence, that
a) chances of hitting a wall are much lower
b) even when you hit a wall, it's less dense (is made up of fewer things)
c) and the end of the project is typically not near at all
I'm saying that if you constantly strive for quality the inevitable walls of software development will become more like bumps. And that's your selling argument right there.
[Next time I'll talk about the third factor (functionality), as well as why quality is important for the developer team.]
[1] DeMarco - Lister: Peopleware
Read full post...
Friday, 12 March 2010
Maslow for Programmers
What would the Maslow-pyramid look like if we applied it to programmers?
(Physiological Need) The starting layer is the fundamental knowledge to implement something in a given environment with given tools. This doesn't need further explanation, without this the rest has no meaning.
(Safety) The basic security of your program; that is a relatively bug-free level, where you can think of, and prepare your software for many of the exceptional situations that could arise.
(Love, Belonging) The awareness of the user and the explicit intention of creating software that has value for its users. This level also includes the intention of writing code that others can understand, designing software with aproved and well-spread concepts in mind, following industry standards and guidelines.
(Esteem) When you don't only care about clean code and design, but also about the process by which you achieve those things. Reflection is a great part of this. Through honest and regular reflection you regularly arrive to the conclusion that you need to learn more, and so you do just that. Without continuous improvement, you can't reach the fifth level
(Self-actualization) Where you can make your own contributions to the software world let they be books, theories or techniques. They could also be development tools, SDK's that aid others' work or have beneficial influence on the way others implement things.
Are you still with me? If you are, you could say, "It's all very nice, but is there a point to all this?" There might.
You have to know your tools and the programming language you use before you can look any further. This sounds trivial, but it's actually quite difficult to achieve. The problem is that many of today's development tools are so sophisticated, sport so many features, offer so many options and solutions in syntax and in libraries, that you just can't learn it from a book. You have to work on many projects, preferably in different problem domains, so that you can come across all particular features of your tool that solve your particular problems perfectly. This takes time, and luck is also a factor here. The good news is that once you have acquired that knowledge, it's only up to you to move up in the pyramid:
* You can start to think about the value of the software you develop.
* You can start looking up literature on how to design, create and test software. It's all out there.
* You can start reflecting on yourself(on your team), you can start improving your process, you can strive to become better at what you do.
Okay, the top level may be out of reach for most us. Not everyone can think as originally as Kent Beck, or write about software as systematically and meticuluosly as Frederick Brooks. But who knows? Maybe, one day you will write the next, all new version of Rhino.Mocks for all the .Net-developers to awe.
Read full post...
(Physiological Need) The starting layer is the fundamental knowledge to implement something in a given environment with given tools. This doesn't need further explanation, without this the rest has no meaning.
(Safety) The basic security of your program; that is a relatively bug-free level, where you can think of, and prepare your software for many of the exceptional situations that could arise.
(Love, Belonging) The awareness of the user and the explicit intention of creating software that has value for its users. This level also includes the intention of writing code that others can understand, designing software with aproved and well-spread concepts in mind, following industry standards and guidelines.
(Esteem) When you don't only care about clean code and design, but also about the process by which you achieve those things. Reflection is a great part of this. Through honest and regular reflection you regularly arrive to the conclusion that you need to learn more, and so you do just that. Without continuous improvement, you can't reach the fifth level
(Self-actualization) Where you can make your own contributions to the software world let they be books, theories or techniques. They could also be development tools, SDK's that aid others' work or have beneficial influence on the way others implement things.
Are you still with me? If you are, you could say, "It's all very nice, but is there a point to all this?" There might.
You have to know your tools and the programming language you use before you can look any further. This sounds trivial, but it's actually quite difficult to achieve. The problem is that many of today's development tools are so sophisticated, sport so many features, offer so many options and solutions in syntax and in libraries, that you just can't learn it from a book. You have to work on many projects, preferably in different problem domains, so that you can come across all particular features of your tool that solve your particular problems perfectly. This takes time, and luck is also a factor here. The good news is that once you have acquired that knowledge, it's only up to you to move up in the pyramid:
* You can start to think about the value of the software you develop.
* You can start looking up literature on how to design, create and test software. It's all out there.
* You can start reflecting on yourself(on your team), you can start improving your process, you can strive to become better at what you do.
Okay, the top level may be out of reach for most us. Not everyone can think as originally as Kent Beck, or write about software as systematically and meticuluosly as Frederick Brooks. But who knows? Maybe, one day you will write the next, all new version of Rhino.Mocks for all the .Net-developers to awe.
Read full post...
Subscribe to:
Posts (Atom)