Recently I was trying to describe code that is always releasable.
One simple criteria is if someone came to a developer and said "We are going to doing a build this afternoon and release it to the public" the developer would not say "Well you need to wait because I need to go back in and change _____".
Can code be inter-iteration releasable? That is, right in the middle of the iteration can a build be made to release? It can be. I have found because of troublesome code merging issues caused by source control I often check in things that are not complete or done. These things compile and even pass their tests but the task is not finished. I check in often because I have had significant "fights" with source control not recognizing "new items" because the project file was modified by another developer, etc. If the "sand box" or "shelf set" were better I would not be inclined to check in to the main line of the code until the task was complete.
So, code can be always releasable if only completed tasks are checked-in. Incomplete tasks are safely backed up and stored in a sand box or shelf set or jump drive or something.
Wednesday, February 25, 2009
Thursday, February 12, 2009
Software Quality: Customer Facing -vs- Developer Facing
There are, at least, two different types of quality to software. Customer facing and Developer facing.
Customer facing quality is defined by the customer and has to do with any aspect that the customer finds important. If there is some aspect of a software product that the customer dislikes for any reason the customer can deem the product to be low quality. For instance, if the software takes too long to load at startup the customer may complain about the quality of the software. If a button in a GUI interface is not where the user expects it then the customer may complain about the quality of the software. In these two examples often the user will say, "Did anyone test this before it went out the door." This line of questioning also leads many to think that enough testing will find all quality issues.
Developer facing quality is defined by the developer when making judgments about the code or the systems upon which the code is developed. Code quality is often discussed in terms of such things as no duplication, no go-to's, no global variables, etc. Code quality also encompasses such things as which database was used, which OS is the target, etc. Yet another aspect of code quality has to do with the architecture, design, and metaphors used to compose the software.
Let me be clear, the customer does not care about the code quality. (Now if you are developing software libraries, tool kits, frameworks, etc., and provide the code to your customers then this is obviously different.) To the customer it is all product quality. If a customer finds problems with their software and the customer actually has the opportunity to talk to the developer of the software and the software developer says, "Well the problem is we have way too much duplication in the code and there is this static class filled with values that get changed all over the place, yadda yadda yadda" all the customer hears are EXCUSES.
Does this mean that the developer's concerns and efforts to have a level of quality in the code are ultimately worthless? Well, if you think that then I suggest you are trying to convince yourself of something other than reality, whether you are denying the fact that you don't really have enough money or skill to be in the business or some other reason you want to blame development. Developer's have compelling reasons to address code quality issues.
Does the customer care if the software was developed by the greatest programmers? The first answer is "NO", they do not care. One reason is they don't care because they do not understand how software is made and how the making of the software is tied to the customer facing quality.
Should developers try to get customers to care about code level quality? No because I feel it is not possible to communicate such things.
So, if I am correct that customers do not care about code quality and it is difficult to imagine that the majority of customers could be enlightened. So then, what is the purpose of this posting?
There are at least two types of quality spoken of when talking about software. Often one person is talking about customer facing quality and the other is talking about developer facing quality. It causes endless discussion which get no where!
In my opinion these items are realities of software:
In the developer community can we at least be clear when we are talking about customer facing quality versus developer facing quality? Call it out when it is not clear which type of quality is being discussed or maybe it is yet another facet of quality still.
Is it obvious that this is a complex system with many inputs and feedbacks. Cash is king, up to a point. Product quality is king, up to a point. Code quality is king, up to a point.
Customer facing quality is defined by the customer and has to do with any aspect that the customer finds important. If there is some aspect of a software product that the customer dislikes for any reason the customer can deem the product to be low quality. For instance, if the software takes too long to load at startup the customer may complain about the quality of the software. If a button in a GUI interface is not where the user expects it then the customer may complain about the quality of the software. In these two examples often the user will say, "Did anyone test this before it went out the door." This line of questioning also leads many to think that enough testing will find all quality issues.
Developer facing quality is defined by the developer when making judgments about the code or the systems upon which the code is developed. Code quality is often discussed in terms of such things as no duplication, no go-to's, no global variables, etc. Code quality also encompasses such things as which database was used, which OS is the target, etc. Yet another aspect of code quality has to do with the architecture, design, and metaphors used to compose the software.
Let me be clear, the customer does not care about the code quality. (Now if you are developing software libraries, tool kits, frameworks, etc., and provide the code to your customers then this is obviously different.) To the customer it is all product quality. If a customer finds problems with their software and the customer actually has the opportunity to talk to the developer of the software and the software developer says, "Well the problem is we have way too much duplication in the code and there is this static class filled with values that get changed all over the place, yadda yadda yadda" all the customer hears are EXCUSES.
Does this mean that the developer's concerns and efforts to have a level of quality in the code are ultimately worthless? Well, if you think that then I suggest you are trying to convince yourself of something other than reality, whether you are denying the fact that you don't really have enough money or skill to be in the business or some other reason you want to blame development. Developer's have compelling reasons to address code quality issues.
Does the customer care if the software was developed by the greatest programmers? The first answer is "NO", they do not care. One reason is they don't care because they do not understand how software is made and how the making of the software is tied to the customer facing quality.
Should developers try to get customers to care about code level quality? No because I feel it is not possible to communicate such things.
So, if I am correct that customers do not care about code quality and it is difficult to imagine that the majority of customers could be enlightened. So then, what is the purpose of this posting?
There are at least two types of quality spoken of when talking about software. Often one person is talking about customer facing quality and the other is talking about developer facing quality. It causes endless discussion which get no where!
In my opinion these items are realities of software:
- The customer cares about product quality.
- The customer DOES NOT care about code quality.
- The customer believes product quality is the results of testing.
- A product can have minimum "product quality" issues and be filled with "code quality" issues.
- A product with poor code quality will not be able to keep up with competing products in an agressive market space.
- A product with poor code quality will not be able to attract or retain the talented software developers needed to move the product forward
- A product with great code quality may receive a low quality product rating by the customers.
- The customer will leave a product that lags behind the competition.
- The customer will spend their money how they see fit.
- A company with more money can produce more low quality code and be able to afford the incurred costs in order to push a company with less capital out of the sector.
- A company with more money can address customer facing quality issues through the use of customer service activities such as phone support, books, tutorials, managed users groups, etc., thus the company's wealth is sufficient to afford the costs of issues with product quality.
In the developer community can we at least be clear when we are talking about customer facing quality versus developer facing quality? Call it out when it is not clear which type of quality is being discussed or maybe it is yet another facet of quality still.
Is it obvious that this is a complex system with many inputs and feedbacks. Cash is king, up to a point. Product quality is king, up to a point. Code quality is king, up to a point.
Monday, February 02, 2009
Where does Quality Code come from?
I have commented and blogged about code quality many times. A recent discussion has influenced me to review my old posts.
A current blog entry entitled "Quality-Speed Tradeoff - You're kidding yourself" asserts that quality is a primary factor in obtaining and sustaining a high speed of software development.
The Maverick Software Development blog contains an archive of the most interesting posts from the old Maverick Software Development group. On that blog can be found "Quality Code" where an analogy is presented to show some of the various definitions of a quality automobile.
So, where does quality code come from? Another question could be where does poor/low quality code come from?
If those questions can be answered could we arrive at the "cause" of poor/low quality code and the "cause" of high quality code?
Another question that comes to mind is this, "Can a high quality software product be made of low quality code?" This question causes one to suppose that the quality of the software product and the quality of the code may be independent. Is this true?
Consider read-ability to be an aspect of quality code. Readable code is another term for code that conveys an accurate message of what the code is actually doing. It is beyond "intent revealing". Intent revealing code is supposed to convey the intent of the programmer. What if the programmer did not meet their intentions? Readable code makes it apparent to what is actually taking place.
Can a quality software product be developed with code that is not easily read?
Here is a consideration for you. Assembly languages are not easily read by the human programmer. There have been quality software products developed in assembly language. Therefore quality software products can be developed with code that has poor readability and therefore a quality software product can be developed with poor/low quality code.
Can poor/low quality code be modified correctly as fast as high quality code?
Consider the development of what is termed "high level languages". One of many reasons that languages such as AGOL, Pascal, COBOL, C, Ada, ...., C# and Java have been developed was to decrease the burden and cost of understanding existing code that needed modification. Simply stated it is that high level languages are more readable. Given this known aspect of programming it can be stated that readable code can be modified correctly faster than less-readable code. Therefore quality code allows for increased speed when maintaining code, or stated another way, quality code takes less time to modify than poor/low quality code. Can this be said for all facets of quality for code?
Consider another attribute of quality code. Quality code has little or no duplicated code. Let's go back to some of the previous questions. Can a quality software product be developed with low quality code? Can a quality software product be developed with duplicated code? I propose that the answer is again YES.
Can code with duplication be correctly modified as fast or faster than code with little or no duplication? The answer is NO. The time to locate the duplicate code plus the time to insert the modification in each location are just two of the factors of the increased time needed to deal with duplicate code. Once again code quality is related to the speed in which correct modifications can be made to the code.
Does it take longer to initially develop high quality code? In the case of readable code I propose that in the worst case it takes no longer to develop readable code than non-readable code and that in most cases it takes less time. In the example of assembly code versus a high level language I propose that most modern software applications can always be developed faster in a high level language. In the case of duplicate code I propose that it takes less time to create the appropriate non-duplicate containing solution than it does to duplicate the code. Let us step back a few short years before refactoring functionality in modern IDE's. Many times I had developed code that I had "inlined" what was conceptually a function. After I had developed it and stepped through it with the debugger until I was satisfied I would then copy the code and make a function and paste it in. It was easy and didn't take any longer than it would to have duplicated it else where. I have now given two examples where quality code takes less time to develop than poor/low quality code.
Finally, where does quality code come from? Well the obvious answer is from people that understand code quality. So, where do people come from that have that understanding? I dare say they are the result of much work and effort on their part to gain experience, knowledge, techniques, and tools which allow them to excel in their profession.
I propose that the level of quality of code is directly related to the level of experience, expertise, and professionalism of the one writing the code. If you want to experience the benefits of quality code then you must first find experienced professionals or allow your developers the opportunity to become those desired professionals.
A current blog entry entitled "Quality-Speed Tradeoff - You're kidding yourself" asserts that quality is a primary factor in obtaining and sustaining a high speed of software development.
The Maverick Software Development blog contains an archive of the most interesting posts from the old Maverick Software Development group. On that blog can be found "Quality Code" where an analogy is presented to show some of the various definitions of a quality automobile.
So, where does quality code come from? Another question could be where does poor/low quality code come from?
If those questions can be answered could we arrive at the "cause" of poor/low quality code and the "cause" of high quality code?
Another question that comes to mind is this, "Can a high quality software product be made of low quality code?" This question causes one to suppose that the quality of the software product and the quality of the code may be independent. Is this true?
Consider read-ability to be an aspect of quality code. Readable code is another term for code that conveys an accurate message of what the code is actually doing. It is beyond "intent revealing". Intent revealing code is supposed to convey the intent of the programmer. What if the programmer did not meet their intentions? Readable code makes it apparent to what is actually taking place.
Can a quality software product be developed with code that is not easily read?
Here is a consideration for you. Assembly languages are not easily read by the human programmer. There have been quality software products developed in assembly language. Therefore quality software products can be developed with code that has poor readability and therefore a quality software product can be developed with poor/low quality code.
Can poor/low quality code be modified correctly as fast as high quality code?
Consider the development of what is termed "high level languages". One of many reasons that languages such as AGOL, Pascal, COBOL, C, Ada, ...., C# and Java have been developed was to decrease the burden and cost of understanding existing code that needed modification. Simply stated it is that high level languages are more readable. Given this known aspect of programming it can be stated that readable code can be modified correctly faster than less-readable code. Therefore quality code allows for increased speed when maintaining code, or stated another way, quality code takes less time to modify than poor/low quality code. Can this be said for all facets of quality for code?
Consider another attribute of quality code. Quality code has little or no duplicated code. Let's go back to some of the previous questions. Can a quality software product be developed with low quality code? Can a quality software product be developed with duplicated code? I propose that the answer is again YES.
Can code with duplication be correctly modified as fast or faster than code with little or no duplication? The answer is NO. The time to locate the duplicate code plus the time to insert the modification in each location are just two of the factors of the increased time needed to deal with duplicate code. Once again code quality is related to the speed in which correct modifications can be made to the code.
Does it take longer to initially develop high quality code? In the case of readable code I propose that in the worst case it takes no longer to develop readable code than non-readable code and that in most cases it takes less time. In the example of assembly code versus a high level language I propose that most modern software applications can always be developed faster in a high level language. In the case of duplicate code I propose that it takes less time to create the appropriate non-duplicate containing solution than it does to duplicate the code. Let us step back a few short years before refactoring functionality in modern IDE's. Many times I had developed code that I had "inlined" what was conceptually a function. After I had developed it and stepped through it with the debugger until I was satisfied I would then copy the code and make a function and paste it in. It was easy and didn't take any longer than it would to have duplicated it else where. I have now given two examples where quality code takes less time to develop than poor/low quality code.
Finally, where does quality code come from? Well the obvious answer is from people that understand code quality. So, where do people come from that have that understanding? I dare say they are the result of much work and effort on their part to gain experience, knowledge, techniques, and tools which allow them to excel in their profession.
I propose that the level of quality of code is directly related to the level of experience, expertise, and professionalism of the one writing the code. If you want to experience the benefits of quality code then you must first find experienced professionals or allow your developers the opportunity to become those desired professionals.
Subscribe to:
Posts (Atom)