How to actually reduce software defects
-
As a Software Developer for nearly 39 years, There is NO silver bullet on reducing software defects. You cannot write bug free software. However there are ways to greatly reduce software defects. I have written software on a variety of software platforms in that nearly 39 years. Currently writing software for Windows PCs, so my details below assume that you too are using Windows... However if you are programming for a different Operating System, then adjust my instructions below to accomodate that Operating System. Here's what I suggest: 1. When writing software, make the labels, buttons, etc that you use on Windows Forms or WPF Forms not use the DEFAULT names such as label1 or button1. Change the names to describe how you intend to use those items (objects) in your code behind such as lblErrorMessage or btnSave before you use those objects. That way it helps self document your code. 2. Use variable names that describe what they will be used for instead of using things like x, y, and z. Reading code that uses something like "x = y * z * a" doesn't help you understand what that does... However using "CalculatedInterest = PrincipleAmount * DailyInterestRate * DaysOfInterest" actually helps you understand what is going on. 3. When writing subroutines / functions use descriptive names. Once again this will help self document your program. 4. Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned. 5. Test your code over and over and over. Don't forget to use "Try...Catch..." Blocks to prevent your code from crashing unexpectedly. Test valid and invalid data to make sure that your code works like you want it to work. 6. Take time to test your executable code and not just rush it out the door. Have other people help you test your resulting executable code. Then make code fixes as needed and repeat this step as many times as it takes to make sure your code works as expected. 7. If your program needs to have a Software Installer, create the installer and test it on say Windows 7, Windows 8.0, Windows 8.1, and Windows 10. If there are problems with any of those versions of the Operating System, go back and fix your program and / or the software installer. Hope this helps someone write better software, Bill G.
-
As a Software Developer for nearly 39 years, There is NO silver bullet on reducing software defects. You cannot write bug free software. However there are ways to greatly reduce software defects. I have written software on a variety of software platforms in that nearly 39 years. Currently writing software for Windows PCs, so my details below assume that you too are using Windows... However if you are programming for a different Operating System, then adjust my instructions below to accomodate that Operating System. Here's what I suggest: 1. When writing software, make the labels, buttons, etc that you use on Windows Forms or WPF Forms not use the DEFAULT names such as label1 or button1. Change the names to describe how you intend to use those items (objects) in your code behind such as lblErrorMessage or btnSave before you use those objects. That way it helps self document your code. 2. Use variable names that describe what they will be used for instead of using things like x, y, and z. Reading code that uses something like "x = y * z * a" doesn't help you understand what that does... However using "CalculatedInterest = PrincipleAmount * DailyInterestRate * DaysOfInterest" actually helps you understand what is going on. 3. When writing subroutines / functions use descriptive names. Once again this will help self document your program. 4. Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned. 5. Test your code over and over and over. Don't forget to use "Try...Catch..." Blocks to prevent your code from crashing unexpectedly. Test valid and invalid data to make sure that your code works like you want it to work. 6. Take time to test your executable code and not just rush it out the door. Have other people help you test your resulting executable code. Then make code fixes as needed and repeat this step as many times as it takes to make sure your code works as expected. 7. If your program needs to have a Software Installer, create the installer and test it on say Windows 7, Windows 8.0, Windows 8.1, and Windows 10. If there are problems with any of those versions of the Operating System, go back and fix your program and / or the software installer. Hope this helps someone write better software, Bill G.
Forgot to add the following: Make sure that your variable types match what you are doing. In other words, don't use a floating point variable when you intend to use integer values. For Example, years ago at a previous job, a novice programmer used a floating point variable instead of an integer value. They printed the value of the variable but didn't realize that when converting from floating point values to integer that the fractional part gets truncated (dropped without rounding) ... so when they are looking up data in a string everything was one short of what they intended to get. By simply changing the variable type to integer the "bug" was fixed very quickly. :D
-
As a Software Developer for nearly 39 years, There is NO silver bullet on reducing software defects. You cannot write bug free software. However there are ways to greatly reduce software defects. I have written software on a variety of software platforms in that nearly 39 years. Currently writing software for Windows PCs, so my details below assume that you too are using Windows... However if you are programming for a different Operating System, then adjust my instructions below to accomodate that Operating System. Here's what I suggest: 1. When writing software, make the labels, buttons, etc that you use on Windows Forms or WPF Forms not use the DEFAULT names such as label1 or button1. Change the names to describe how you intend to use those items (objects) in your code behind such as lblErrorMessage or btnSave before you use those objects. That way it helps self document your code. 2. Use variable names that describe what they will be used for instead of using things like x, y, and z. Reading code that uses something like "x = y * z * a" doesn't help you understand what that does... However using "CalculatedInterest = PrincipleAmount * DailyInterestRate * DaysOfInterest" actually helps you understand what is going on. 3. When writing subroutines / functions use descriptive names. Once again this will help self document your program. 4. Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned. 5. Test your code over and over and over. Don't forget to use "Try...Catch..." Blocks to prevent your code from crashing unexpectedly. Test valid and invalid data to make sure that your code works like you want it to work. 6. Take time to test your executable code and not just rush it out the door. Have other people help you test your resulting executable code. Then make code fixes as needed and repeat this step as many times as it takes to make sure your code works as expected. 7. If your program needs to have a Software Installer, create the installer and test it on say Windows 7, Windows 8.0, Windows 8.1, and Windows 10. If there are problems with any of those versions of the Operating System, go back and fix your program and / or the software installer. Hope this helps someone write better software, Bill G.
Destiny777 wrote:
Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned.
That's some of the worst coding advice you can give! I've said it many times before (and a lot of people still disagree, which is fine), comments are evil[^]! In my life I've never ever seen a comment that actually helped me. I really hate comments, maybe even more so than HTML and CSS, and man do I hate HTML and CSS X| You mention testing, but not automated testing. Equally important :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Forgot to add the following: Make sure that your variable types match what you are doing. In other words, don't use a floating point variable when you intend to use integer values. For Example, years ago at a previous job, a novice programmer used a floating point variable instead of an integer value. They printed the value of the variable but didn't realize that when converting from floating point values to integer that the fractional part gets truncated (dropped without rounding) ... so when they are looking up data in a string everything was one short of what they intended to get. By simply changing the variable type to integer the "bug" was fixed very quickly. :D
This is a no brainer. Unfortunately, you are right. I've seen this type abuse all too often :(
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Destiny777 wrote:
Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned.
That's some of the worst coding advice you can give! I've said it many times before (and a lot of people still disagree, which is fine), comments are evil[^]! In my life I've never ever seen a comment that actually helped me. I really hate comments, maybe even more so than HTML and CSS, and man do I hate HTML and CSS X| You mention testing, but not automated testing. Equally important :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
I agree, I've been a C# development for 9 years now and I've seen far more useless, misleading or just plain wrong comments in code than helpful ones. Adding comments is just another piece of "technical debt" that needs to be maintained with the code - and devs don't see comments as important as code. I think comments should be used sparingly to describe things that are not obvious from the code (like why you are trimming 7 characters from the input stream from that 3rd party service). Thumbs up for the others on the list 👍
-
Let them switch job. Let them code, you be the observer. See how the table turned. They will stop discussing when their simple "Hello World" code got dozen of bug/defect.
-
If your project is done slowly maybe and again there alway have a lot of unexpected :mad:. If want fast than lot messy code and mistake because of quick fix
-
As a Software Developer for nearly 39 years, There is NO silver bullet on reducing software defects. You cannot write bug free software. However there are ways to greatly reduce software defects. I have written software on a variety of software platforms in that nearly 39 years. Currently writing software for Windows PCs, so my details below assume that you too are using Windows... However if you are programming for a different Operating System, then adjust my instructions below to accomodate that Operating System. Here's what I suggest: 1. When writing software, make the labels, buttons, etc that you use on Windows Forms or WPF Forms not use the DEFAULT names such as label1 or button1. Change the names to describe how you intend to use those items (objects) in your code behind such as lblErrorMessage or btnSave before you use those objects. That way it helps self document your code. 2. Use variable names that describe what they will be used for instead of using things like x, y, and z. Reading code that uses something like "x = y * z * a" doesn't help you understand what that does... However using "CalculatedInterest = PrincipleAmount * DailyInterestRate * DaysOfInterest" actually helps you understand what is going on. 3. When writing subroutines / functions use descriptive names. Once again this will help self document your program. 4. Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned. 5. Test your code over and over and over. Don't forget to use "Try...Catch..." Blocks to prevent your code from crashing unexpectedly. Test valid and invalid data to make sure that your code works like you want it to work. 6. Take time to test your executable code and not just rush it out the door. Have other people help you test your resulting executable code. Then make code fixes as needed and repeat this step as many times as it takes to make sure your code works as expected. 7. If your program needs to have a Software Installer, create the installer and test it on say Windows 7, Windows 8.0, Windows 8.1, and Windows 10. If there are problems with any of those versions of the Operating System, go back and fix your program and / or the software installer. Hope this helps someone write better software, Bill G.
how about a published style guide (suitable for your organisation) .. that would cover the points you allude to an automated build process automated testing addendum to point '5' of yours .. dont ever let me see you catch an exception and absorb it out of laziness !
-
I agree, I've been a C# development for 9 years now and I've seen far more useless, misleading or just plain wrong comments in code than helpful ones. Adding comments is just another piece of "technical debt" that needs to be maintained with the code - and devs don't see comments as important as code. I think comments should be used sparingly to describe things that are not obvious from the code (like why you are trimming 7 characters from the input stream from that 3rd party service). Thumbs up for the others on the list 👍
Matt.L wrote:
why
Right there is the reason Sander is wrong, we all know how to trim strings but why you need to is the relevant point. Sure sometimes, even most times it is obvious but when it is not then put in a bloody comment for Ghu's sake!
Never underestimate the power of human stupidity RAH
-
And now take a look at a previous survey, and the comments there: Survey Results - Which Continuous Integration tool(s) are you using?[^] :~ Half of the people who participated aren't interested in quality (or insist that CI is crap which won't help them) X|
-
Stop shortcutting the SDLC process. Stop outsourcing your development work. Show some loyalty to your employees. Among other things.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
As a Software Developer for nearly 39 years, There is NO silver bullet on reducing software defects. You cannot write bug free software. However there are ways to greatly reduce software defects. I have written software on a variety of software platforms in that nearly 39 years. Currently writing software for Windows PCs, so my details below assume that you too are using Windows... However if you are programming for a different Operating System, then adjust my instructions below to accomodate that Operating System. Here's what I suggest: 1. When writing software, make the labels, buttons, etc that you use on Windows Forms or WPF Forms not use the DEFAULT names such as label1 or button1. Change the names to describe how you intend to use those items (objects) in your code behind such as lblErrorMessage or btnSave before you use those objects. That way it helps self document your code. 2. Use variable names that describe what they will be used for instead of using things like x, y, and z. Reading code that uses something like "x = y * z * a" doesn't help you understand what that does... However using "CalculatedInterest = PrincipleAmount * DailyInterestRate * DaysOfInterest" actually helps you understand what is going on. 3. When writing subroutines / functions use descriptive names. Once again this will help self document your program. 4. Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned. 5. Test your code over and over and over. Don't forget to use "Try...Catch..." Blocks to prevent your code from crashing unexpectedly. Test valid and invalid data to make sure that your code works like you want it to work. 6. Take time to test your executable code and not just rush it out the door. Have other people help you test your resulting executable code. Then make code fixes as needed and repeat this step as many times as it takes to make sure your code works as expected. 7. If your program needs to have a Software Installer, create the installer and test it on say Windows 7, Windows 8.0, Windows 8.1, and Windows 10. If there are problems with any of those versions of the Operating System, go back and fix your program and / or the software installer. Hope this helps someone write better software, Bill G.
-
Define "software defect" ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
1. Hire competent engineers 2. Hire competent testers I'm continually surprised how often companies ignore both of these, especially #2. Oh, and: 3. Don't think you can write software on a tight, fixed schedule (i.e. two week sprints.) Especially without staggered sprints for testers. This is the fatal flaw in agile/scrum. Sprints assume ALL work will be done, which means that your deverlopers will be working the first week and testers the second or you simply won't have adequate testing. In a similar vein, I'd add: 4. Factor "shit happens" into your development schedule.
-
And now take a look at a previous survey, and the comments there: Survey Results - Which Continuous Integration tool(s) are you using?[^] :~ Half of the people who participated aren't interested in quality (or insist that CI is crap which won't help them) X|
Bernhard Hiller wrote:
Half of the people who participated aren't interested in quality (or insist that CI is crap which won't help them) X|
How do you figure that? Do you think that everyone using CI puts out quality code? Do you think that everyone that isn't in a CI environment doesn't? Were we all writing garbage before the Good Lord Jenkins opened our sinful eyes to the ONE TRUE WAY?
-
Destiny777 wrote:
Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned.
That's some of the worst coding advice you can give! I've said it many times before (and a lot of people still disagree, which is fine), comments are evil[^]! In my life I've never ever seen a comment that actually helped me. I really hate comments, maybe even more so than HTML and CSS, and man do I hate HTML and CSS X| You mention testing, but not automated testing. Equally important :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
First off Sander you don't know how I program nor the other techniques that I use. Was trying to help others understand that without documentation even great code can be hard to follow. You learn by having others to help you test your products as well as quality assurance testing by qualified people. I don't buy your misconception about what was posted as a general guide to help reduce software defects. Does your software have NO issues at all? I think not. You obviously haven't read my documentation and comments in my own code... otherwise your opinion might change to realize that you don't have all the answers. You probably don't have over 39 years of software development on multiple platforms from mainframes to minicomputers in multiple computer languages. So I take your comments with a grain of salt... we all have a lot to learn and hopefully every day we all get better at the craft of writing software. We all have unique experiences in the field of software engineering. It is an ever changing environment with new things coming out every day... so none of us knows it all. Think before you start posting here with your limited experience. I'm sure that you know a lot... but to best understand things you have to keep an open mind.
-
First off Sander you don't know how I program nor the other techniques that I use. Was trying to help others understand that without documentation even great code can be hard to follow. You learn by having others to help you test your products as well as quality assurance testing by qualified people. I don't buy your misconception about what was posted as a general guide to help reduce software defects. Does your software have NO issues at all? I think not. You obviously haven't read my documentation and comments in my own code... otherwise your opinion might change to realize that you don't have all the answers. You probably don't have over 39 years of software development on multiple platforms from mainframes to minicomputers in multiple computer languages. So I take your comments with a grain of salt... we all have a lot to learn and hopefully every day we all get better at the craft of writing software. We all have unique experiences in the field of software engineering. It is an ever changing environment with new things coming out every day... so none of us knows it all. Think before you start posting here with your limited experience. I'm sure that you know a lot... but to best understand things you have to keep an open mind.
First off, Destiny777, it took you almost a year to reply!? :wtf: Second, my comment was in no way a personal attack, but it seems that's how you're taking it. From there on your post is just a giant ad hominem, attacking me as a person rather than my argument. I suggest you read Clean Code by Robert C. Martin, an author with more knowledge and experience than us mere mortals can ever hope to accumulate in this life, and he is against comments. By your own logic you are now in the wrong. You say "Think before you start posting here [because something that has nothing to do with anything]" and I suggest you do the same (and I guess a year wasn't enough).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
First off, Destiny777, it took you almost a year to reply!? :wtf: Second, my comment was in no way a personal attack, but it seems that's how you're taking it. From there on your post is just a giant ad hominem, attacking me as a person rather than my argument. I suggest you read Clean Code by Robert C. Martin, an author with more knowledge and experience than us mere mortals can ever hope to accumulate in this life, and he is against comments. By your own logic you are now in the wrong. You say "Think before you start posting here [because something that has nothing to do with anything]" and I suggest you do the same (and I guess a year wasn't enough).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
I didn't take your comments as a personal attack at all. You discounted the thought of even documenting code from what I could tell. You code your way, I'll code mine. Successful programming as a team REQUIRES documentation. Sorry that you took it as a personal attack by me. Good coding techniques and excellent documentation IS helpful.
-
I didn't take your comments as a personal attack at all. You discounted the thought of even documenting code from what I could tell. You code your way, I'll code mine. Successful programming as a team REQUIRES documentation. Sorry that you took it as a personal attack by me. Good coding techniques and excellent documentation IS helpful.
Sorry for that, your (invalid) argument about my experience hit a sore spot. I've worked for some a-hole who thought he was somehow a better programmer because he had more years of experience [read: years worked as a programmer]. He was sure to SCREAM at me that something as absurd as "design patterns" would never work and he could know because he had 8 years of experience and I was only just getting started. According to him not even Microsoft used design patterns. You can imagine that wasn't our first and neither our last argument about code and every time he'd be sure to say he was right BECAUSE he has more years or experience (and he was also my boss). Experience says nothing about skill or knowledge. Please remember that :) So, peaceful this time :laugh: I agree that good documentation can be helpful. Unfortunately, documenting is often even harder than writing the code in the first place. Updating documentation is something I've only heard of in fairy tales. I've had plenty of experience with documentation and especially code comments, and 99% of the documentation was useless at best. A useless comment (I've come across this exact comment countless of times!):
// Declare and set the variable.
int i = 42;Another "duh" comment:
// Save the customer.
customer.Save();And this is why commenting just doesn't work:
// Save the customer.
product.Save();These are real world examples and most of the comments I've seen. Anyway, good code (usually) requires no comments. And, as said, in his book, Clean Code, Robert Martin, an authority on programming, also argues against comments (the entire book is really worth a read!). That said, documentation is helpful! When I'm about to use some third party library and I can't find any documentation it's exit library! So if that was what you meant I'm completely with you. I've documented my own arrgh.js[^] like that (although you won't find a single // code comment in the source) :) So let's either agree to disagree or something in between (docs yes, comments no, agree 50%?) ;)
Best, Sander arrgh.js - Bringing LINQ to JavaScript
