- Elastic Search another key/value store that allows multiple servers to cluster Lucene and uses a simple JSON API.
- Katta a project for using Hadoop and Lucene together.
- ElephantDB which uses MapReduce to produce indexes for key/values.
- How SimpleGeo Built a Scalable Geospatial Database with Apache Cassandra using Geohash (to flatten a 2d space into 1d) and Cassandra to provide a GIS database for exact match, range and proximity searching. Claims that rebalancing isn't necessary
- Google's Percolator paper about providing incremental updates to search indexes instead of using MapReduce.
- End of IPv4 or is it: IPocalypse and Vint Cerf and Geoff Huston at the recent Linx Conf Australia
- Efficient SPARQL joins, ontologies as games, IOS Semantic Web Journal
- TDD as a way of getting things done, Testing Javascript with Jasmine and The fallacy of trading quality in software.
- Brisbane Functional Users Group videos
Showing posts with label quality. Show all posts
Showing posts with label quality. Show all posts
Monday, February 28, 2011
Linkage
Friday, February 02, 2007
Within Specification
The definition of quality is that it meets a certain specification. What a bunch of bollocks! I have a Holden Vectra (a rebadged Opel which people say is a very bad brand in its own country, Germany) - it requires more oil (about 1 litre) every 3,000-4,000 kilometer ever since I've bought it. It has only done 30,000 kilometers in 3 years but in that time it's run out of oil 4 times (between services). Now I ring up Holden support and say that this is an unacceptable specification. They say the car is fine, it is within the oil consumption specification.
Quality is excellence and that's not Holden.
Update: So here's a bit more, based on what Matthew wrote in the comments.
So the quality of the specification comes out of a process. And if that process doesn't have "the quality of excellence" in it, at all levels, then you're not achieving quality yet.
One of these aspects to this quality is a sort of self similarity - like well designed code - each bit of code does a small bit and does it in an understandable way and is roughly the same as the other bits - independent of which level of the system you're at.
If you can't raise an "IT Strategy Defect" then your organizational processes (which your lower processes are a part of) lack that aspect of quality. Now maybe that has to come out of high costs, failed projects or whatever.
From the perspective of the software industry, it seems that we've got a much higher expectation on what can be done. There aren't that many industries where the customer, project manager, support, maintenance, engineer, tester, etc. are even able to say (let alone expected or encouraged) "there's something wrong, fix it".
The guy at Holden support says, "I wouldn't buy a car with those specs" and so on - they know it sucks but they can't change it.
Now that isn't to say software should produce the equivalent of bubble domed cars that play "La Cucaracha". I'd like a flying car but at the moment I'd settle for something that doesn't need to be checked every 3,000 km and isn't going to destroy the planet.
Quality is excellence and that's not Holden.
Update: So here's a bit more, based on what Matthew wrote in the comments.
So the quality of the specification comes out of a process. And if that process doesn't have "the quality of excellence" in it, at all levels, then you're not achieving quality yet.
One of these aspects to this quality is a sort of self similarity - like well designed code - each bit of code does a small bit and does it in an understandable way and is roughly the same as the other bits - independent of which level of the system you're at.
If you can't raise an "IT Strategy Defect" then your organizational processes (which your lower processes are a part of) lack that aspect of quality. Now maybe that has to come out of high costs, failed projects or whatever.
From the perspective of the software industry, it seems that we've got a much higher expectation on what can be done. There aren't that many industries where the customer, project manager, support, maintenance, engineer, tester, etc. are even able to say (let alone expected or encouraged) "there's something wrong, fix it".
The guy at Holden support says, "I wouldn't buy a car with those specs" and so on - they know it sucks but they can't change it.
Now that isn't to say software should produce the equivalent of bubble domed cars that play "La Cucaracha". I'd like a flying car but at the moment I'd settle for something that doesn't need to be checked every 3,000 km and isn't going to destroy the planet.
Monday, January 15, 2007
Quality is Free
The business value of software quality "Organizations that develop low-quality software, whether for internal use or for sale, are always looking backward, spending time and money on fixing defects in "finished" products."
"One common misconception about quality is that it can be traded for improved development speed, reduced development budgets, or added functionality. In practice, however, most organizations find the opposite is true. In the long run, improved quality enables teams to deliver more projects on time, at lower cost, with more features. We should realize that Meskimen's law -- "There's never time to do it right, but always time to do it over" -- is a tongue-in-cheek adage for a reason. A development team that continuously ensures quality does it right the first time. By not introducing defects into the system throughout the entire development process, a team eliminates the time and cost required to find and fix those defects later on."
And why don't customers care about quality: "The simple answer is: “Because defective software works.” The reason it works, however, is because software doesn’t wear out, rot, or otherwise deteriorate. Once it is fixed, it will continue to work as long as it is used in precisely the same way."
"One common misconception about quality is that it can be traded for improved development speed, reduced development budgets, or added functionality. In practice, however, most organizations find the opposite is true. In the long run, improved quality enables teams to deliver more projects on time, at lower cost, with more features. We should realize that Meskimen's law -- "There's never time to do it right, but always time to do it over" -- is a tongue-in-cheek adage for a reason. A development team that continuously ensures quality does it right the first time. By not introducing defects into the system throughout the entire development process, a team eliminates the time and cost required to find and fix those defects later on."
And why don't customers care about quality: "The simple answer is: “Because defective software works.” The reason it works, however, is because software doesn’t wear out, rot, or otherwise deteriorate. Once it is fixed, it will continue to work as long as it is used in precisely the same way."
Monday, July 17, 2006
Achieving Quality
Technology: Can You Automate Software Quality? "A lot of the debate has been focused on testing. Total Quality, however, would suggest that although testing is necessary, it's not sufficient. Testing focuses on inspection, not on prevention. To over-simplify, you test in hopes of demonstrating that the software has no defects (because you have a good high-quality development process), not to detect the defects that are present, but should not be there (because you don't have a good high quality development process). After several years of significant effort, the code my client was developing (and testing) still isn't of the high quality they are looking for. So we decided to go back, start from some basics, and look again at the issue of software quality."
Goes through the processes to ensure quality software: code quality (using TDD), functional quality (giving the customer what they want), non-functional quality (security, privacy, compliance, etc), deployment and production quality, and maintenance.
"This probably seems like a lot of additional work for the development organization. And it is. But the costs of defective code in the production environment (both direct, in terms of sustaining engineering, and indirect, in terms of lost revenue and reputation) was becoming significant. Management felt it had no choice but to focus on improved quality, and turn to the productivity issues later. So far, despite the added burden of all these quality–related activities (many of which already took place, but simply weren't very effective) we have not seen a slowdown in software availability. Some teams are actually moving faster than before, despite the new work they have to perform, because they spend much less time and effort on remediation and last-minute adjustments to code to fix issues that only show up as the code is transitioned to production."
Goes through the processes to ensure quality software: code quality (using TDD), functional quality (giving the customer what they want), non-functional quality (security, privacy, compliance, etc), deployment and production quality, and maintenance.
"This probably seems like a lot of additional work for the development organization. And it is. But the costs of defective code in the production environment (both direct, in terms of sustaining engineering, and indirect, in terms of lost revenue and reputation) was becoming significant. Management felt it had no choice but to focus on improved quality, and turn to the productivity issues later. So far, despite the added burden of all these quality–related activities (many of which already took place, but simply weren't very effective) we have not seen a slowdown in software availability. Some teams are actually moving faster than before, despite the new work they have to perform, because they spend much less time and effort on remediation and last-minute adjustments to code to fix issues that only show up as the code is transitioned to production."
Thursday, June 15, 2006
Mule with a Spinning Wheel
For some time now, I've been reading Jeff Langr's series on TDD (including testing equality, refactoring tests, and driving UIs). I now feel compelled to make sure I link to it as it's up to the 13th installment "Nine Reasons Why You Should Be Using TDD".
"A lot of the duplication in a system isn’t evident until you start refactoring. Once you begin refactoring, you start recognizing potential for reuse. You’re more likely to recognize that a small, newly extracted method could be called by another method, which in turn simplifies the other method. You start to build simpler classes that do fewer things. Often, having a smaller class increases the likelihood that other classes can reuse it."
I'd like to call this the "Tetris effect" of refactoring code. You get methods/classes/lines of code looking the same, all at the same level of abstraction and any extra complexity can then be easily removed.
"I used to think that I was a pretty good coder. I would spend an afternoon slamming out code. I’d integrate the code and run some manual tests late in the afternoon. Sometimes it wouldn’t work—imagine that! I’d then be forced to spend another few hours unraveling the mess I’d built."
"With TDD, every piece of code exists because it was required by a test. That rule, in turn, means that we have solid unit test coverage. (We don’t have exhaustive coverage, which would be virtually impossible to provide.) Defect rates should come down significantly. Martin Fowler and Ron Jeffries talk about shops that severely reduced their numbers of defects. Most teams working on moderate-sized applications (several hundred thousand lines of code) have defect rates in the hundreds or even thousands per year. Shops doing TDD can achieve rates of less than a dozen per year (but they probably need to be adhering to other proven disciplines as well)."
"The amount of time I feel compelled to go off into a dark cube and think about a problem has been minimal since I’ve been doing TDD."
"A lot of the duplication in a system isn’t evident until you start refactoring. Once you begin refactoring, you start recognizing potential for reuse. You’re more likely to recognize that a small, newly extracted method could be called by another method, which in turn simplifies the other method. You start to build simpler classes that do fewer things. Often, having a smaller class increases the likelihood that other classes can reuse it."
I'd like to call this the "Tetris effect" of refactoring code. You get methods/classes/lines of code looking the same, all at the same level of abstraction and any extra complexity can then be easily removed.
"I used to think that I was a pretty good coder. I would spend an afternoon slamming out code. I’d integrate the code and run some manual tests late in the afternoon. Sometimes it wouldn’t work—imagine that! I’d then be forced to spend another few hours unraveling the mess I’d built."
"With TDD, every piece of code exists because it was required by a test. That rule, in turn, means that we have solid unit test coverage. (We don’t have exhaustive coverage, which would be virtually impossible to provide.) Defect rates should come down significantly. Martin Fowler and Ron Jeffries talk about shops that severely reduced their numbers of defects. Most teams working on moderate-sized applications (several hundred thousand lines of code) have defect rates in the hundreds or even thousands per year. Shops doing TDD can achieve rates of less than a dozen per year (but they probably need to be adhering to other proven disciplines as well)."
"The amount of time I feel compelled to go off into a dark cube and think about a problem has been minimal since I’ve been doing TDD."
Tuesday, May 30, 2006
The Greyness of Gold
Steve McMcConnell's Software Project Survival Guide mentions gold plating a project, specifically: "Implement only what is required. Developers, managers, and customers often think of small, easy changes that seem to make the software better. These changes often have much more far-reaching impacts than anticipated by the specific developer who will implement the change. Do not let additional complexity creep into the project through gold-plating."
This may fly in the face of ideas like refactoring (although refactoring is generally an attempt to remove complexity not add it). To put this into context, though, the team that he's talking about is well above the quality curve: "...the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a 100,000 line-of-code MIS system, and it would typically contain about 850 defects when delivered. The NASA SEL [the team in question] would deliver a system of that size with about the same amount of time and effort, but it would contain only about 50 defects."
So when you have a manager talking about not wanting to have a gold plated solution check to see if your project is delivering on the 50 defects/100,000 lines of code first.
Of course, the original point is true too - you can continually seek the perfect solution to a business problem, probably forever, and in doing so add complexity to a system. Business processes aren't always rational so there may not be a good solution to the problem. So continually swapping ways of solving a problem can be an untenable situation.
I know that some people want to refactor code forever and others are happy just to write code and see if it works somehow. There's obviously a balance.
To me saying, "I don't want a gold plated solution" is asking not try to achieve a certain level of quality and certainly most IT shops should be trying to do more not less.
This may fly in the face of ideas like refactoring (although refactoring is generally an attempt to remove complexity not add it). To put this into context, though, the team that he's talking about is well above the quality curve: "...the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a 100,000 line-of-code MIS system, and it would typically contain about 850 defects when delivered. The NASA SEL [the team in question] would deliver a system of that size with about the same amount of time and effort, but it would contain only about 50 defects."
So when you have a manager talking about not wanting to have a gold plated solution check to see if your project is delivering on the 50 defects/100,000 lines of code first.
Of course, the original point is true too - you can continually seek the perfect solution to a business problem, probably forever, and in doing so add complexity to a system. Business processes aren't always rational so there may not be a good solution to the problem. So continually swapping ways of solving a problem can be an untenable situation.
I know that some people want to refactor code forever and others are happy just to write code and see if it works somehow. There's obviously a balance.
To me saying, "I don't want a gold plated solution" is asking not try to achieve a certain level of quality and certainly most IT shops should be trying to do more not less.
Monday, April 03, 2006
Blowing Your Mind
In pursuit of code quality: Monitoring cyclomatic complexity "This report's section labeled Top 30 functions containing the most NCSS details the largest methods in the code base, which incidentally almost always correlate to methods containing the highest cyclomatic complexity. For instance, the report lists the class DBInsertQueue's updatePCensus() method as having a noncommenting line count of 283 and a cyclomatic complexity (labeled as CCN) of 114.
As demonstrated above, cyclomatic complexity is a good indicator of code complexity; moreover, it's an excellent barometer for developer testing. A good rule of thumb is to create a number of test cases equal to the cyclomatic complexity value of the code being tested. In the case of the updatePCensus() method seen in Figure 2, you would need 114 test cases to achieve full coverage."
"Because cyclomatic complexity is such a good indicator of code complexity, there is a strong relationship between test-driven development and low CC values. When tests are written often (note, I'm not implying first), developers have the tendency to write uncomplicated code because complicated code is hard to test. If you find that you're having difficulty writing a test, it's a red flag that the code under test may be complex. The short "code, test, code, test" cycle of TDD invites refactoring in these cases, which continually drives the development of uncomplex code."
As demonstrated above, cyclomatic complexity is a good indicator of code complexity; moreover, it's an excellent barometer for developer testing. A good rule of thumb is to create a number of test cases equal to the cyclomatic complexity value of the code being tested. In the case of the updatePCensus() method seen in Figure 2, you would need 114 test cases to achieve full coverage."
"Because cyclomatic complexity is such a good indicator of code complexity, there is a strong relationship between test-driven development and low CC values. When tests are written often (note, I'm not implying first), developers have the tendency to write uncomplicated code because complicated code is hard to test. If you find that you're having difficulty writing a test, it's a red flag that the code under test may be complex. The short "code, test, code, test" cycle of TDD invites refactoring in these cases, which continually drives the development of uncomplex code."
Subscribe to:
Posts (Atom)