September 25, 2013 at 7:41 am
No programmer can anticipate ALL possible use cases and potential sources of errors. This is why error trapping and handling should be core skills for all programmers. It's much easier to diagnose and correct issues with code that fails gracefully, providing ample information about the failure in error messages or logs, than code that simply crashes with either cryptic error messages or no error messages at all.
Jason Wolfkill
September 25, 2013 at 8:24 am
paul.knibbs (9/25/2013)
I always like Maurice Wilkes' quote about this:"I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."
That was back in the late 40s, I believe, so this has been going on for a while! It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.
That's great.
September 25, 2013 at 8:30 am
simon.crick (9/25/2013)
"embrace the idea that code can be wrong" -- Nathan MarzSurely this is the wrong approach, as it just gives people an excuse to be lazy.
If they're lazy, they won't be good developers, whether they embrace this or not. If they are proud and professional, they won't be lazy, but they'll be more realistic and more open to correcting issues.
Code should NEVER be wrong. It is not difficult to write code that works correctly. You just need to follow two simple rules:
1) Be crystal clear about the valid set of inputs, and throw an appropriate exception if the input is not in the valid set.
2) If you are not sure whether the logic is correct, break your code into smaller functions/procedures until it is 100% clear that it will work correctly in all cases.
Bugs only arise when people do not follow these simple rules.
Simon
I'd disagree, but you're also conflating working with right. Code can compile and run, but work as intended. I might be able to enter orders in the system and store them in a database, but might not calculate the shipping date correctly, or I might not anticipate that I need defaults in certain fields. I'll make mistakes coding because you cannot be crystal clear about all inputs for all situations.
Bugs also arise as code gets very complex, and when platforms have their own bugs. If it were as simple as just paying attention to all details, we wouldn't have bugs in most software. There are many, many smart people writing software. We still get bugs.
September 25, 2013 at 8:32 am
To start out with the goal of writing anything less than perfect code, is a sure way to create a system riddled with bugs.
Do you write space craft code for NASA? Because their code is supposedly the "most correct" code ever, and it's still not flawless. And it's an expensive process that takes lengthy amounts of time. Do you have lots of time and money for your projects?
Every decent programmer wants perfection, every experienced programmer realizes that perfection isn't obtainable in most circumstances.
September 25, 2013 at 8:49 am
In today's scenario, many of the times, the code which is correct today may become incorrect (or inefficient) tomorrow based on the frequently changing scenarios and/or improvements. So any change in the code should be taken as making a step closer to perfection (for today's perfect can be improvised further tomorrow).
September 25, 2013 at 9:10 am
Steve Jones - SSC Editor (9/25/2013)
simon.crick (9/25/2013)
"embrace the idea that code can be wrong" -- Nathan MarzSurely this is the wrong approach, as it just gives people an excuse to be lazy.
If they're lazy, they won't be good developers, whether they embrace this or not. If they are proud and professional, they won't be lazy, but they'll be more realistic and more open to correcting issues.
Code should NEVER be wrong. It is not difficult to write code that works correctly. You just need to follow two simple rules:
1) Be crystal clear about the valid set of inputs, and throw an appropriate exception if the input is not in the valid set.
2) If you are not sure whether the logic is correct, break your code into smaller functions/procedures until it is 100% clear that it will work correctly in all cases.
Bugs only arise when people do not follow these simple rules.
Simon
I'd disagree, but you're also conflating working with right. Code can compile and run, but work as intended. I might be able to enter orders in the system and store them in a database, but might not calculate the shipping date correctly, or I might not anticipate that I need defaults in certain fields. I'll make mistakes coding because you cannot be crystal clear about all inputs for all situations.
Bugs also arise as code gets very complex, and when platforms have their own bugs. If it were as simple as just paying attention to all details, we wouldn't have bugs in most software. There are many, many smart people writing software. We still get bugs.
Systems can get complex, but code should never be complex. If code becomes complex, it should be broken down into smaller functions/procedures until it is no longer complex.
This simple rule will eliminate almost all bugs from even the most highly complex systems.
To understand why this is true, you need to consider the relationship between the number of lines of code in a function/procedure and the probability of that function/procedure containing a bug. Everyone knows that the probability of a bug starts at zero and increases exponentially as the number of lines of code increases. This is why systems that are coded in large chunks always contain way more bugs than equally large systems that are coded in small chunks.
I have worked with lots of extremely gifted people who are incapable of writing bug-free code simply because they do not understand this principle.
I was lucky. I had teachers who drummed this into me from an early age, and I have written some fairly complex systems that have not needed a single bug fix or enhancement in 20+ years.
Unfortunately, there seem to be a lot of people who are still not aware of the importance of breaking down complex systems into simple components, and this is why a large proportion of programmers and software engineers now see it as normal and acceptable and somehow innevitable that all software will contain bugs.
Simon
September 25, 2013 at 9:13 am
All this stipulation regarding correctness and yet most systems are developed in 3GLs which cannot be proved. Functional languages can but not 3GLs.
Also the HUGE ASSUMPTION is that the requirements are correct, unambiguous and constant. If the requirements are wrong (or have changed) then so will the system even if the development team(s) did a perfect job.
Catering for defects is a mature and responsible approach to developing complex systems. Whilst simon.crick may not have meant to come across as holding a very naive viewpoint that systems should be fault free that was the way that I interpreted his statements, and it seems others too, hence the responses.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 25, 2013 at 9:16 am
simon.crick (9/25/2013)
...This simple rule will eliminate almost all bugs from even the most highly complex systems...
What is the other simple rule to get eliminate of the rest of the defects? :unsure:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 25, 2013 at 9:38 am
I believe technology also has a role to play in the prevalence of bugs in modern software.
I have no hard evidence to back this up, but I would be prepared to bet quite a lot of money that modern languages like C# with lots of "advanced" programming concepts suffer from way more bugs than earlier languages like C++ that are more minimalistic.
Advanced programming concepts are fine in principle, but they can lead to code with lots of unnecessary layers and levels of abstraction that can obscure the underlying logic, resulting in mis-understandings that would not have occurred if simpler programming concepts had been used.
I firmly believe that computer science will eventually realize this and there will eventually be a return to simpler and more minimalistic languages and technologies.
But this won't happen until computer scientists get over their inferiority complex (controversial, I know, but a well recognised phenomenon) and start thinking about how they can help us build more reliable systems rather than how they can impress their physics/engineering/mathematics colleagues with difficult to understand research papers.
Simon
September 25, 2013 at 9:42 am
simon.crick (9/25/2013)
I was lucky. I had teachers who drummed this into me from an early age, and I have written some fairly complex systems that have not needed a single bug fix or enhancement in 20+ years.
I can't argue with that. I hope you're well compensated as you must be one of the best developers around. I've never me anyone that could make this claim.
September 25, 2013 at 9:47 am
simon.crick (9/25/2013)
...I believe technology also has a role to play in the prevalence of bugs in modern software...modern languages like C# with lots of "advanced" programming concepts suffer from way more bugs than earlier languages like C++ that are more minimalistic...
I concur. Complicated languages with features continual shoe horned in only leads to even more complicated languages. I felt the same way about C++ circa 2001.
I also feel that the acceptance of low quality and a low entrance bar for programmers is a vicious circle. I don't believe in a closed shop but we should raise the bar and help people over it through quality mentoring and both formal and informal training. This has to be driven by corporates.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 25, 2013 at 9:49 am
Steve Jones - SSC Editor (9/25/2013)
simon.crick (9/25/2013)
I was lucky. I had teachers who drummed this into me from an early age, and I have written some fairly complex systems that have not needed a single bug fix or enhancement in 20+ years.I can't argue with that. I hope you're well compensated as you must be one of the best developers around. I've never me anyone that could make this claim.
I sense a degree of disbelief, and I can't blame you given the culture of not caring about the odd bug here and there that seems to invaded the computing industry, but it is 100% true. The first system I worked on was a client database and commission tracking system for a financial advisor. I finished it in the early 1990's, and it is still in use today, and it hasn't been touched for over 20 years.
Simon
September 25, 2013 at 9:54 am
simon.crick (9/25/2013)
Steve Jones - SSC Editor (9/25/2013)
simon.crick (9/25/2013)
I was lucky. I had teachers who drummed this into me from an early age, and I have written some fairly complex systems that have not needed a single bug fix or enhancement in 20+ years.I can't argue with that. I hope you're well compensated as you must be one of the best developers around. I've never me anyone that could make this claim.
I sense a degree of disbelief, and I can't blame you given the culture of not caring about the odd bug here and there that seems to invaded the computing industry, but it is 100% true. The first system I worked on was a client database and commission tracking system for a financial advisor. I finished it in the early 1990's, and it is still in use today, and it hasn't been touched for over 20 years.
Simon
I struggle with "fairly complex systems" and "not needed a single [...] enhancement". No changing requirements? Are you sure? Where in this world is a place where that neither financial regulation nor personal data regulation has changed in 20+ years???
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 25, 2013 at 9:55 am
simon.crick (9/25/2013)
I sense a degree of disbelief, and I can't blame you given the culture of not caring about the odd bug here and there that seems to invaded the computing industry, but it is 100% true. The first system I worked on was a client database and commission tracking system for a financial advisor. I finished it in the early 1990's, and it is still in use today, and it hasn't been touched for over 20 years.
Simon
I'll admit I have natural skepticism. I've never heard anyone make a claim like that. all systems, all software I've ever seen has bugs.
However I have no basis to doubt you. I don't know you, nor your work, and it's unfair of me to state that I don't believe you. I have no basis for doing that, hence my comment that I hope you're well paid. If you can back up the claim, you should be very well compensated.
Someone has to be the best developer in the world. It could easily be you. I only know it's not me.
September 25, 2013 at 9:57 am
Part of the article reads "It an application doesn't work for the cases we've designed it for, then we need to work on our coding skills. "
More often then not it is more of an understanding or communication problem then it is a coding problem. The code often is innocent for it does just what the developer wrote it to do. It functions in a patten and takes input, processes it and creates the resulting output. Each time using the same input and processing, the identical output is produced. I know of the anomalies that can happen as far as data is concerned but even the anomalies are for the most part repeatable.
If we replace the need for "work on our coding skills" with the need for work on our development skills this would be more correct. For the development is more then code, it includes the molding of a defined function into a technical idea that is then coded. Without a complete understanding of the defined function and proper communication about it concerning any questions or complexities, the code will most often come close but in the end fail. If however the code is a byproduct of proper analysis and understanding of the function it most often produces the correct result.
Development includes far more then just writing code. And making a system out of what we designed it for included far more then input/processing/output. Remember Yogi saying “We're lost, but we're making good time.” Put into this scenario we are not sure what the program should do but we are really coding it well.
Not all gray hairs are Dinosaurs!
Viewing 15 posts - 16 through 30 (of 60 total)
You must be logged in to reply to this topic. Login to reply