Validity & Verity
I am asked. "Did you have lunch today?"
I answer, "Monday."
That answer is invalid. The question has just two valid answers - "Yes" or "No".
If I give one of the valid answers, it does not mean it is the truth (verity). My answer has to be verified.
Validation checks for Validity. Verification checks for Veracity.
Valid Programs & Correct Programs
A C program that can be compiled without errors is a valid C program. Is it a correct program? By executing the program, it can be verified that the program meets its specification. It can be verified that the program is correct. Correct programs are a subset of Valid programs.
Validation Criteria & Quality
What if the compiler options are set to treat all warnings as errors? Now if there are warnings the program will not compile. The program is no longer a valid program. There is nothing to verify.
What if, to successfully check-in code to the version control system, the code must meet Complexity Metrics?
What if the code cannot be checked-in because coding standards are not met?
There is more to qualifying as valid code than just clearing compiler errors.
If you want to improve code quality, enforce stricter validation criteria.
Showing posts with label Quality. Show all posts
Showing posts with label Quality. Show all posts
09 February 2017
20 July 2013
Message of Bihar's Mid-Day Meal Tragedy
It turns out that the CAG had, a few years ago, pointed out the unhygienic conditions prevailing, and state of the materials used, in the mid-day meal system. Arnab Goswami, on his show asked one of the participants as to why quality control measures were not in place. The participant said it was not practical to do so.
QA being "not practical" is something that I have heard a lot of when it comes to software work. (A few weeks back, I was part of a 3-way discussion on quality, when again I heard more about "not practical".)
Do developers and their managers treat QA reports any more seriously than the politicians treat the CAG's report? How seriously are QA audits taken in most software companies? (Incidentally, final testing and defect reporting do not constitute the totality of QA.) As the tag line for this blog says, "Quality & 6-pack abs, both require hard work". And sacrifice. And the integrity not to fudge - if you did 20 crunches, do not imagine you did 21.
Could the contractor have said, "Sorry, I cannot provide the meal"?
Can you as a software professional say, "Sorry, I cannot meet the time frame with the required quality"?
Must you also serve software crawling with "bugs" like the food served to those hapless children?
If you are being forced by management, what of the school principal, the contractor, ...?
QA being "not practical" is something that I have heard a lot of when it comes to software work. (A few weeks back, I was part of a 3-way discussion on quality, when again I heard more about "not practical".)
Do developers and their managers treat QA reports any more seriously than the politicians treat the CAG's report? How seriously are QA audits taken in most software companies? (Incidentally, final testing and defect reporting do not constitute the totality of QA.) As the tag line for this blog says, "Quality & 6-pack abs, both require hard work". And sacrifice. And the integrity not to fudge - if you did 20 crunches, do not imagine you did 21.
Could the contractor have said, "Sorry, I cannot provide the meal"?
Can you as a software professional say, "Sorry, I cannot meet the time frame with the required quality"?
Must you also serve software crawling with "bugs" like the food served to those hapless children?
If you are being forced by management, what of the school principal, the contractor, ...?
21 January 2013
ZAMM-1
I mentioned in my previous post, I am going to make a series of posts about "Zen and The Art of Motorcycle Maintenance" (ZAMM).
Before I post about specific passages that resonated with me, I want to first talk about my relationship with the book.
I first read the book about 20 odd years ago. After that I have re-read it a couple of times. Never the same copy. I confess to being guilty of having given it to (forced it on?) people I have known, to read. I really missed the last one that went missing. It had lots of notes, and highlighting, and a personal index. Then on 22nd Dec last year (I remember the date as I was at the airport to receive my son and his family), I came across the 25th anniversary edition. I promptly purchased it from the Kindle store. I am happy that I did.
The first time I bought the book was because I was fascinated by the title. I was quite adept at stripping down my Lambretta scooter and putting it together again. Never at the level where I did my own welding or machining, like the author; I wished I had the gumption to do it. (The book has a lot to say about gumption. I relate to it totally.)
I was also mildly interested in Zen
Here are a couple of things that I believe about the book:
1. It is one of two books, without reading which, the education of an electronics - or software - engineer is not complete. The other book is, Tracy Kidder's "The Soul of a New Machine". (I still have my copy:-)
2. The book was first published in 1974. That was just after the Oil-Shock of 1973. Fuel efficient Japanese cars started making inroads into the American market. The consumer electronics industry was finished off. Americans could not believe that the Japanese could produce high quality goods at the prices they did. Japanese industry was studied. Japanese methods like Quality Circles were adopted. Nothing worked. Till finally it was established that Japanese practices required Japanese civilizational values. (See the books about Toyota authored by Jeffrey Liker). I find it prescient of the author that in ZAMM, he ascribes the problems of American society in general, and American industry in particular, to civilizational values. And since Western, and hence American, civilizational values derive from ancient Greece, he traces the problem to Aristotle. Very interesting.
06 August 2011
About Hats
Watch this video about a company that makes hats. The same management attitude is required for software companies. I believe my late friend RR practised this.
31 March 2011
Quality Control and Quality Assuarance
India Software Brief group on LinkedIn has a post on protection from bad software. The actions to be taken by an outsourcer (the one getting the software developed) are all necessary acceptance checks. The problem is what happens when the acceptance checks fail? Sure, reject the product but what happens to rolling out the services that depend on getting this software?
Acceptance checks can provide assurance that bad software does not get accepted. It does not provide assurance that good software will be delivered.
Far better to check the outsoursee's processes and be assured that the final acceptance checks will not turn up serious deficiencies or defects. An incremental model of development, with actual functioning code delivered would give a better estimate of the progress. This, of course, requires that the outsourcer put resources to test each increment and give feedback.
A while back I posted my views about QA and QC. The outsourcer must verify the QA processes and, by providing feedback on each increment, become part of QC. I suspect the root cause of all outsourcing horror stories lie in not doing this.
Acceptance checks can provide assurance that bad software does not get accepted. It does not provide assurance that good software will be delivered.
Far better to check the outsoursee's processes and be assured that the final acceptance checks will not turn up serious deficiencies or defects. An incremental model of development, with actual functioning code delivered would give a better estimate of the progress. This, of course, requires that the outsourcer put resources to test each increment and give feedback.
A while back I posted my views about QA and QC. The outsourcer must verify the QA processes and, by providing feedback on each increment, become part of QC. I suspect the root cause of all outsourcing horror stories lie in not doing this.
Cyber Weapons against Embedded Systems
Watch this video on Stuxnet.
I suppose the answer, for systems that can justify the additional cost, is not to use standard off-the-shelf hardware. The people who built stuxnet knew the details of the Seimens SCADA systems that run the centrifuges. They would also know the details of the centrifuges. Iran, like Pakistan, does not have the capability to build centrifuges. (India's nuclear programme, I think, does not require centrifuges.)
Not using standard hardware and firmware means building them in the country. Good news for Indian engineers.
Safety is one dimension of embedded software quality. Safety includes security against malicious attacks. Watch this webinar on security in eHealth.
I suppose the answer, for systems that can justify the additional cost, is not to use standard off-the-shelf hardware. The people who built stuxnet knew the details of the Seimens SCADA systems that run the centrifuges. They would also know the details of the centrifuges. Iran, like Pakistan, does not have the capability to build centrifuges. (India's nuclear programme, I think, does not require centrifuges.)
Not using standard hardware and firmware means building them in the country. Good news for Indian engineers.
Safety is one dimension of embedded software quality. Safety includes security against malicious attacks. Watch this webinar on security in eHealth.
22 November 2010
02 October 2010
Movie about Quality
Early today I watched Executive Suite. It is a movie made in the the 1950s. I strongly recommend getting the bittorrent download, or the DVD (available from Amazon), or watch when Turner Classic Movies schedules it again
The terrific cast include William Holden. Holden was a favourite of mine when I was in school. Some may remember him from Bridge On the River Kwai. The movie very convincingly conveys the message about values on which a company should be run, quality in manufacturing, product that the company's people are proud to stand behind. If American companies had paid heed they would not have lost leadership in automobiles. We need to build companies with the same values.
The terrific cast include William Holden. Holden was a favourite of mine when I was in school. Some may remember him from Bridge On the River Kwai. The movie very convincingly conveys the message about values on which a company should be run, quality in manufacturing, product that the company's people are proud to stand behind. If American companies had paid heed they would not have lost leadership in automobiles. We need to build companies with the same values.
29 September 2010
High Jobs and Low Jobs
Aamir Khan attends to a customer complaint. The customer is surprised to find that Aamir is the managing director. Aamir replies, "Kaam bada ya chota nahin hota. Kaam, kaam hota hai." (Translation: A job is not low or high. A job is a job.)
No job is High. No job is Low.It is the standard of execution that is high or low. It is commitment that is high or low. It is professionalism that is high or low. A job is just that - a job.
No job is High. No job is Low.It is the standard of execution that is high or low. It is commitment that is high or low. It is professionalism that is high or low. A job is just that - a job.
25 July 2010
Certfication & Quality
Todays Swaminomics talks of how the award for Corporate Social Responsibilty does not correlate with actual behaviour towards society.Both BP and Goldman Sachs had received it. Recent damage caused by these companies show that social responsibilty was not a value. It was mere PR glitter.
Quality certifications, like the award for Corporate Social Responsibilty, can be obtained with the required "paper work" and some amount of play acting. It does not mean that Quality is a prime value for the company. In most cases it is obtained for adding glitter to marketing. And all that glitters is not gold.
Quality has to be a basic value. A value expressed not through certfications, or on the web-site, or in quality manuals. It has to be the gating criteria for all product decisions. It has to be expressed through action. Actions speak louder than words.
Quality certifications, like the award for Corporate Social Responsibilty, can be obtained with the required "paper work" and some amount of play acting. It does not mean that Quality is a prime value for the company. In most cases it is obtained for adding glitter to marketing. And all that glitters is not gold.
Quality has to be a basic value. A value expressed not through certfications, or on the web-site, or in quality manuals. It has to be the gating criteria for all product decisions. It has to be expressed through action. Actions speak louder than words.
02 July 2010
Excellence
"We are what we repeatedly do. Excellence is therefore not an act but a habit" - Aristotle
The above quote was in an email that I received.
I am sure that something was lost in translating from classical Greek to English.
Surely just repeatedly doing something out of habit will not improve us in whatever we are doing. If we are to improve in doing something, surely how we do it must change. Continuing to do something in a manner because it was always done so, would still have us hanging from trees.
It is the PDCA (Plan, Do, Check, Act) cycle - not just repeatedly Doing (the D part) - that will move us towards excellence.
Yes making the PDCA cycle a habit will lead to excllence.
The above quote was in an email that I received.
I am sure that something was lost in translating from classical Greek to English.
Surely just repeatedly doing something out of habit will not improve us in whatever we are doing. If we are to improve in doing something, surely how we do it must change. Continuing to do something in a manner because it was always done so, would still have us hanging from trees.
It is the PDCA (Plan, Do, Check, Act) cycle - not just repeatedly Doing (the D part) - that will move us towards excellence.
Yes making the PDCA cycle a habit will lead to excllence.
17 June 2010
Software Development Practices
This is the content of an email that I sent to the people that I worked with in the programming tools business unit. The email was sent in Jul 2003. By and large these were adopted by most of the developers of the business unit and continued to be practised over successive generations of developers. The practices were well ingrained and I doubt if later generation of developers were even aware that such a mail existed:-)
The practices were based on my reading of the following references:
1. Steve McConnell: "Rapid Development". Microsoft Press (WP Publishers, India)
2. Steve McConnell: "Code Complete". Microsoft Press. (Indian Publisher: WP Publishers)
3. John Robbins: "Debugging Applications". Microsoft Press (WP Publishers, India)
4. Steve Maguire: "Writing Solid Code". Microsoft Press (WP Publishers, India)
5. Masaki Imai: "Kaizen - The key to Japan's Competitive Success". McGraw-Hill International Editions
Documentation
See:
"Comment, Comment, Comment, And Comment", pgs77-78 of Ref3.
"Self-Documenting Code", Ch19 of Ref2.
"PDL for Pros", pgs54-57 of Ref2.
Please remember documentation is for YOUR customer. Who is your customer? Anyone who has to look at your code, or use it, is your customer; the developer who uses the services that your code provides, the reviewer, the tester, the maintainer, and last but not least - you. It is documentation that transcends space and time. To paraphrase (I think, Wordsworth), "Dust thou art to dust returnest was not spoken of documentation"
Comments need to convey what's in the developer's mind, not what a given statement is doing. Explain the "What & Why". Only then, explain the "How"
Two quotes from Ref3:
"I mean documenting your assumptions, your approach, and your reasons for choosing the approach you did."
"Donald Knuth once observed that you should be able to read a well-written program just as you would read a well-written book."
Develop the code in a three-stage step-wise refinement process. The artifact of each stage is to be reviewed.
First Function Headers. Function header should contain the algorithm. If it is from a text, then give the reference. The algorithm should just explain the broad idea of how the purpose of the function will be achieved. If the algorithm is getting unwieldy, it means more than one function is required. The algorithm has to be reviewed before proceeding.
Next PDL. The PDL refines the algorithm. Check if indeed it does that. The PDL must be in a style that will make them good comments.
Next Code. The final refinement. Check if algorithm, PDL and code are consistent.
Any changes to the code should be reflected back to the PDL and if necessary to the algorithm. The reasons for the changes should be given in the comments.
The DETAILED DESIGN, inclusive of functional specifications, will exist only in the source files, as file and function headers. NO WHERE ELSE.
Only the architecture design will exist as a separate document. It will be largely pictorial and show the interconnections and responsibilities of the modules. This document should be a part of the workspace.
NAMING CONVENTION: Follow the Hungarian Notation.
ASSERT
Read:
"Assert, Assert, Assert, And Assert", pgs48-58 of Ref3
"Assert Yourself", Ch2 of Ref4
And implement.
Globals
No globals. Any relaxation, to this rule, will only be made with the permission of the CEO.
Use Access routines. See pg231-233 of Ref2.
Test Each Function
Read:
"Step Through Your Code" Ch4 of Ref4
"Trust Yourself, But Verify (Unit testing)" in Ref3 pgs78-80.
Walk-thru your code by stepping thru every path.
Daily Build
Read:
"Daily Build and Smoke Test", ch 18 of Ref1
Get the bad news early!
Do this even on one-person projects.
A smoke test is just an indicator that the build has a reasonable chance of passing the full test and therefore, development can continue. If the full test throws up defects that necessitates the development to regress, then the smoke test is not adequate.
Creation of tests is a creative activity and will require the attention of skilled and experienced persons.
The further away we are from Daily Builds the more defect prone is our development process.
Daily Check-out and Check-in
Even on one-person projects use the CVS. Check-out the files at the start of the workday. Check them in at the finish of the workday.
Defects
All defects are to be recorded in the DTS (Defect Tracking System. This was implemented as a MySQL database).
Defect analysis does not finish with identifying the cause. Like Taiichi Ohno ask "Why?" five times (pg50 of Ref5). Analysis must identify reasons that caused the defect to be introduced; the reasons that caused it to be missed in unit tests. It must identify the remedial measures that need to be introduced in the development process.
Defects caught in reviews must also be recorded in the DTS and analyzed.
Checklists
The results of defect analysis must result in entries in checklists.
Each of the chapters in Ref2 ends with a checklist. Browse the book and choose your top 10. Use it when reviewing your own code or someone else's. Save a copy.
Keep records
Keep records, preferably as text emails, of all discussions and reviews. If it was not recorded, it did not happen.
Keep it Simple
"Finally, don't write code the way lawyers write contracts." - pg166 of Ref4
Use the QA C to keep a check on the complexity of your code. Document this metric in the function/file header.
The practices were based on my reading of the following references:
1. Steve McConnell: "Rapid Development". Microsoft Press (WP Publishers, India)
2. Steve McConnell: "Code Complete". Microsoft Press. (Indian Publisher: WP Publishers)
3. John Robbins: "Debugging Applications". Microsoft Press (WP Publishers, India)
4. Steve Maguire: "Writing Solid Code". Microsoft Press (WP Publishers, India)
5. Masaki Imai: "Kaizen - The key to Japan's Competitive Success". McGraw-Hill International Editions
Documentation
See:
"Comment, Comment, Comment, And Comment", pgs77-78 of Ref3.
"Self-Documenting Code", Ch19 of Ref2.
"PDL for Pros", pgs54-57 of Ref2.
Please remember documentation is for YOUR customer. Who is your customer? Anyone who has to look at your code, or use it, is your customer; the developer who uses the services that your code provides, the reviewer, the tester, the maintainer, and last but not least - you. It is documentation that transcends space and time. To paraphrase (I think, Wordsworth), "Dust thou art to dust returnest was not spoken of documentation"
Comments need to convey what's in the developer's mind, not what a given statement is doing. Explain the "What & Why". Only then, explain the "How"
Two quotes from Ref3:
"I mean documenting your assumptions, your approach, and your reasons for choosing the approach you did."
"Donald Knuth once observed that you should be able to read a well-written program just as you would read a well-written book."
Develop the code in a three-stage step-wise refinement process. The artifact of each stage is to be reviewed.
First Function Headers. Function header should contain the algorithm. If it is from a text, then give the reference. The algorithm should just explain the broad idea of how the purpose of the function will be achieved. If the algorithm is getting unwieldy, it means more than one function is required. The algorithm has to be reviewed before proceeding.
Next PDL. The PDL refines the algorithm. Check if indeed it does that. The PDL must be in a style that will make them good comments.
Next Code. The final refinement. Check if algorithm, PDL and code are consistent.
Any changes to the code should be reflected back to the PDL and if necessary to the algorithm. The reasons for the changes should be given in the comments.
The DETAILED DESIGN, inclusive of functional specifications, will exist only in the source files, as file and function headers. NO WHERE ELSE.
Only the architecture design will exist as a separate document. It will be largely pictorial and show the interconnections and responsibilities of the modules. This document should be a part of the workspace.
NAMING CONVENTION: Follow the Hungarian Notation.
ASSERT
Read:
"Assert, Assert, Assert, And Assert", pgs48-58 of Ref3
"Assert Yourself", Ch2 of Ref4
And implement.
Globals
No globals. Any relaxation, to this rule, will only be made with the permission of the CEO.
Use Access routines. See pg231-233 of Ref2.
Test Each Function
Read:
"Step Through Your Code" Ch4 of Ref4
"Trust Yourself, But Verify (Unit testing)" in Ref3 pgs78-80.
Walk-thru your code by stepping thru every path.
Daily Build
Read:
"Daily Build and Smoke Test", ch 18 of Ref1
Get the bad news early!
Do this even on one-person projects.
A smoke test is just an indicator that the build has a reasonable chance of passing the full test and therefore, development can continue. If the full test throws up defects that necessitates the development to regress, then the smoke test is not adequate.
Creation of tests is a creative activity and will require the attention of skilled and experienced persons.
The further away we are from Daily Builds the more defect prone is our development process.
Daily Check-out and Check-in
Even on one-person projects use the CVS. Check-out the files at the start of the workday. Check them in at the finish of the workday.
Defects
All defects are to be recorded in the DTS (Defect Tracking System. This was implemented as a MySQL database).
Defect analysis does not finish with identifying the cause. Like Taiichi Ohno ask "Why?" five times (pg50 of Ref5). Analysis must identify reasons that caused the defect to be introduced; the reasons that caused it to be missed in unit tests. It must identify the remedial measures that need to be introduced in the development process.
Defects caught in reviews must also be recorded in the DTS and analyzed.
Checklists
The results of defect analysis must result in entries in checklists.
Each of the chapters in Ref2 ends with a checklist. Browse the book and choose your top 10. Use it when reviewing your own code or someone else's. Save a copy.
Keep records
Keep records, preferably as text emails, of all discussions and reviews. If it was not recorded, it did not happen.
Keep it Simple
"Finally, don't write code the way lawyers write contracts." - pg166 of Ref4
Use the QA C to keep a check on the complexity of your code. Document this metric in the function/file header.
07 March 2010
First Post: Six-Pack Abs
I am not going to be blogging about working out.
I am going to blog about quality - in services, and in software development. Software development related activities is where i have spent most of my life - or at least the most interesting part.
Quality is like six-pack abs.
Every one claims to provide quality product/services, or at least wants to. Not many are prepared to put in the hard work needed to deliver quality. Some do manage to get to provide a quality product or service - for a while. Very few are able, or willing, to continue to to put in the hard work to provide qualityon a sustainable, day-in and day-out basis.
Not very different from getting and maintaing 6-pack abs!
I am going to blog about quality - in services, and in software development. Software development related activities is where i have spent most of my life - or at least the most interesting part.
Quality is like six-pack abs.
Every one claims to provide quality product/services, or at least wants to. Not many are prepared to put in the hard work needed to deliver quality. Some do manage to get to provide a quality product or service - for a while. Very few are able, or willing, to continue to to put in the hard work to provide qualityon a sustainable, day-in and day-out basis.
Not very different from getting and maintaing 6-pack abs!
Subscribe to:
Posts (Atom)