Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

It Happens Expand / Collapse
Author
Message
Posted Wednesday, September 25, 2013 6:41 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, October 09, 2013 3:49 AM
Points: 24, Visits: 76
chrisn-585491 (9/25/2013)
It is not difficult to write code that works correctly.


You can write good code, but chances are you don't write perfect code, all the time. Just because it works, doesn't mean it's correct or right for all situations. Try writing a huge complex business application that runs on three different RDBMS, the desktop and the web, with features to satisfy hundreds of different companies with thousands of users with data collected from millions of people.

(There's a corollary to this about data: "All data is bad, some data is worse.")


I agree, we are all human and we all make mistakes from time to time.

However, I still believe that any system, no matter how large or complex, can always be broken down into simple components that can easily be coded correctly.

Problems only arise when people try to tackle too much in one go.

Simon
Post #1498302
Posted Wednesday, September 25, 2013 6:44 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, March 24, 2014 8:12 AM
Points: 117, Visits: 226
I've mentioned this example before, but it's completely appropos:

My boss used to work for a call center. Every so often the entire system would crash for no apparent reason. After some detective work, they isolated it to one specific employee.

The root cause of the problem was the guy was clicking on a button in the GUI just to see how fast he could make the colors change back and forth.

The moral: You can NEVER be 100% certain how your software will be used now and forevermore.

And these days software doesn't run in isolation. You can test your software until you're blue in the face, get it working perfectly, then the company (ahem) that writes the OS changes something that causes your code to break.


____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
Post #1498306
Posted Wednesday, September 25, 2013 6:56 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 6:26 AM
Points: 1,529, Visits: 5,190
simon.crick (9/25/2013)
However, I still believe that any system, no matter how large or complex, can always be broken down into simple components that can easily be coded correctly.


Then your point of failure becomes the communication between all these simple little components. It only takes a mistake in documentation for one part of your program to call another with incorrect parameters, and suddenly the whole thing comes crashing down in your lap. In addition, it's always possible for code to produce unexpected results even when it's entirely syntactically correct--compilers and interpreters are written by programmers who make mistakes, just like your own code is!
Post #1498316
Posted Wednesday, September 25, 2013 7:13 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, October 09, 2013 3:49 AM
Points: 24, Visits: 76
paul.knibbs (9/25/2013)
simon.crick (9/25/2013)
However, I still believe that any system, no matter how large or complex, can always be broken down into simple components that can easily be coded correctly.


Then your point of failure becomes the communication between all these simple little components. It only takes a mistake in documentation for one part of your program to call another with incorrect parameters, and suddenly the whole thing comes crashing down in your lap. In addition, it's always possible for code to produce unexpected results even when it's entirely syntactically correct--compilers and interpreters are written by programmers who make mistakes, just like your own code is!


Yes, you still need a good set of integration tests to ensure there were no misunderstandings at the interface level, but there is no excuse for bugs within individual components.

I'm not saying that we can ever achieve perfection (clearly that is not possible when humans are involved), but I do believe that we should be aiming for perfection.

To start out with the goal of writing anything less than perfect code, is a sure way to create a system riddled with bugs.

Simon
Post #1498334
Posted Wednesday, September 25, 2013 7:17 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 6:26 AM
Points: 1,529, Visits: 5,190
simon.crick (9/25/2013)
To start out with the goal of writing anything less than perfect code, is a sure way to create a system riddled with bugs.


This still seems to be suggesting that people who write buggy code are deliberately setting out to do so, which is not the case. I would hope *any* programmer would want to write bug-free, easily maintainable code (with the caveat of the usual "Fast. Cheap. Bug-free. Pick any two" problem), but wanting something really, really hard isn't guaranteed to make it happen!
Post #1498341
Posted Wednesday, September 25, 2013 7:41 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, April 07, 2014 7:35 AM
Points: 1,172, Visits: 2,413
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
Blog: SQLSouth
Twitter: @SQLSouth
Post #1498358
Posted Wednesday, September 25, 2013 8:24 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 6:29 PM
Points: 32,834, Visits: 14,975
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1498394
Posted Wednesday, September 25, 2013 8:30 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 6:29 PM
Points: 32,834, Visits: 14,975
simon.crick (9/25/2013)
"embrace the idea that code can be wrong" -- Nathan Marz

Surely 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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1498397
Posted Wednesday, September 25, 2013 8:32 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, April 04, 2014 8:42 AM
Points: 598, Visits: 1,504
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.
Post #1498400
Posted Wednesday, September 25, 2013 8:49 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 6:04 AM
Points: 3,517, Visits: 2,606
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).
Post #1498415
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse