Greg Finzer asked the question on a Linedin Group "What practices do you use to improve the quality of an application?". Greg shared is ideas on improving application quality here, and focuses on developer practices to increase quality. I have my own ideas on what quality means, and how to improve it. Here's my take on it.
How do you define quality?
Quality is hard to define, and I don't know of any satisfactory description (much like architecture). In Zen and The Art of Motorcycle Maintenance, the narrator (Pirsig) spends a great deal to time trying to define quality, which eventually drove him insane (requiring shock therapy).
One way you can define quality might be how close the item comes to ideal, when viewed through different perspectives.
For example, for a software project, we can look at quality from the perspective of the end user - does the application work? How easy is it to use?
We can look at code quality - How complex is the code? How much of the complexity is inherent to the problem, and how much is accidental? Is the code well factored? Is the code layered?
We might look at quality through the eyes of a tester. How many bugs are being found? How often are bugs being found? How testable is the system?
We might look at quality through the eyes of a graphic designer. How well is the UI laid out? Is terminology appropriate and consistent?
There are many other ways of looking at quality. Many of these views on quality are subjective. You can find quality issues by applying some heuristics from each point of view. For example, developers would apply SOLID principles to determine how clean codes is. Graphic designers can use design heuristics to spot issues with the design.
Of course there are some ways of quantifying quality. From a developer perspective, we might use static analysis tools to identify issues with our code bases. We might use automated testing tools to run regression tests to validate the application functions as expected. We might perform performance measurements to verify latency and responsiveness are within tolerances.
Regardless of which view of quality you take or how you quantify it, the only way to improve "Quality" is to have passionate people devoted to improving it. You need to have quality as a core value.
I don't think any particular coding practice will lead to better quality. It takes skilled developers applying good design skills to deliver quality products.
If I had to pick, automated testing (any flavour, I don't believe in being dogmatic about any one technique) and good old design skills would be the practices to focus on.
Rich Hickey has a good talk called "Simple Made Easy" that I'd recommendhttp://www.infoq.com/presentations/Simple-Made-Easy
Here are a few books I'd recommend.
"The Software Craftsman" by Sandro Mancuso http://www.amazon.ca/The-Software-Craftsman-Professionalism-Pragmatism/dp/0134052501
"The Pragmatic Programmer" by Dave Thomas and Andy Hunt http://www.amazon.ca/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X
"Domain Driven Design" by Eric Evans http://www.amazon.ca/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
"Clean Code" by Robert C. Martin (aka Uncle Bob) http://www.amazon.ca/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
"Working Effectively With Legacy Code" by Michael Feathers is a great book.http://www.amazon.ca/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
How do you define quality?
Quality is hard to define, and I don't know of any satisfactory description (much like architecture). In Zen and The Art of Motorcycle Maintenance, the narrator (Pirsig) spends a great deal to time trying to define quality, which eventually drove him insane (requiring shock therapy).
One way you can define quality might be how close the item comes to ideal, when viewed through different perspectives.
For example, for a software project, we can look at quality from the perspective of the end user - does the application work? How easy is it to use?
We can look at code quality - How complex is the code? How much of the complexity is inherent to the problem, and how much is accidental? Is the code well factored? Is the code layered?
We might look at quality through the eyes of a tester. How many bugs are being found? How often are bugs being found? How testable is the system?
We might look at quality through the eyes of a graphic designer. How well is the UI laid out? Is terminology appropriate and consistent?
There are many other ways of looking at quality. Many of these views on quality are subjective. You can find quality issues by applying some heuristics from each point of view. For example, developers would apply SOLID principles to determine how clean codes is. Graphic designers can use design heuristics to spot issues with the design.
Of course there are some ways of quantifying quality. From a developer perspective, we might use static analysis tools to identify issues with our code bases. We might use automated testing tools to run regression tests to validate the application functions as expected. We might perform performance measurements to verify latency and responsiveness are within tolerances.
Regardless of which view of quality you take or how you quantify it, the only way to improve "Quality" is to have passionate people devoted to improving it. You need to have quality as a core value.
I don't think any particular coding practice will lead to better quality. It takes skilled developers applying good design skills to deliver quality products.
If I had to pick, automated testing (any flavour, I don't believe in being dogmatic about any one technique) and good old design skills would be the practices to focus on.
Rich Hickey has a good talk called "Simple Made Easy" that I'd recommendhttp://www.infoq.com/presentations/Simple-Made-Easy
Here are a few books I'd recommend.
"The Software Craftsman" by Sandro Mancuso http://www.amazon.ca/The-Software-Craftsman-Professionalism-Pragmatism/dp/0134052501
"The Pragmatic Programmer" by Dave Thomas and Andy Hunt http://www.amazon.ca/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X
"Domain Driven Design" by Eric Evans http://www.amazon.ca/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
"Clean Code" by Robert C. Martin (aka Uncle Bob) http://www.amazon.ca/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
"Working Effectively With Legacy Code" by Michael Feathers is a great book.http://www.amazon.ca/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Very helpful tips, thank you! https://www.appliancekitchener.com
ReplyDelete