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

Why Don't We Have Better Practices? Expand / Collapse
Author
Message
Posted Thursday, May 15, 2014 9:08 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, May 15, 2014 9:08 PM
Points: 1, Visits: 1
Breakthrough ideas, when responding to complex business issues, cannot and should not be confined to "best practices" and not even to "good practices". Those belong to simple and complicated business issues respectively, and I am sure that in those cases all do follow them.

When dealing with complex business issues, where innovative and creative solutions are required, a solution would require developing "emergent practices". This is one reason for the evolution of new concepts that has led to very impressive approaches that, over time, become "good practices" and even "best practices" for others as a complex issue becomes a complicated or even a simple issue.

With the advancements in the IT world, new technologies helping to reduce or eliminate existing business limitations, new approaches to business issues are possible and must be conceived and created. To have a regulated approach to creativeness is not possible in a complex and even chaotic world. The way we have successfully accommodated a limitation cannot be enforced once that limitation has been removed.
Post #1571584
Posted Friday, May 16, 2014 7:53 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Thursday, September 11, 2014 8:23 AM
Points: 625, Visits: 2,128
I'm not sure I've ever heard buggy code, bad design, and lack of security standards or QA referred to as an 'emergent practice' or 'breakthrough idea' before.

Kind of makes the old "its not a bug its an undocumented feature" joke seem mild.
Post #1571731
Posted Friday, May 16, 2014 8:16 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Saturday, September 13, 2014 4:06 AM
Points: 988, Visits: 804
Nevyn (5/16/2014)
I'm not sure I've ever heard buggy code, bad design, and lack of security standards or QA referred to as an 'emergent practice' or 'breakthrough idea' before.

^^like^^
Post #1571747
Posted Friday, May 16, 2014 9:50 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 1:29 AM
Points: 65, Visits: 238
I don't think AmandS was suggesting buggy code, bad design, etc. should become viewed as emergent practice. Just that new programming methods and features become available before standards can be updated to reflect them.
Post #1571800
Posted Monday, May 19, 2014 11:24 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Yesterday @ 10:34 AM
Points: 418, Visits: 2,450
skeleton567 (5/15/2014)
Ralph Hightower (5/15/2014)
Try programming in APL. That is one bizarre language!


I'm not sure without researching it if APL and what we called in the old days Assembler Language are the same thing, but I've "been there, done that". It was a very efficient, fast, compact, precise tool and we always used it for the most exacting critical tasks. You had to be a real 'programmer' to use it, and we didn't have the naive folks 'managing' development. Real, experienced Systems Analysts were in charge and we got things right in development. Bugs in software were taken seriously and all identified were fixed without waiting for a 'next release'. Then along came the likes of COBOL which made so-called 'programmers' of those who weren't and shouldn't have been.

The industry really couldn't afford to code everything in assembler, there actually is a benefit to higher level languages, and COBOL at the time really brought benefits over assembler and to most folks in the industry it was a real no brainer. The resulting increase of the worlds programmer population was inevitably going to bring in folks who weren't up to your standards, but its worth considering how far we would have got if we stuck with assembler for everything, I'd hazard a guess not very far

Post #1572398
Posted Monday, May 19, 2014 12:30 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Yesterday @ 9:16 PM
Points: 37,102, Visits: 31,655
My personal feeling is the we have great "practices" in this industry and the last thing in the world that I'd want is for some RDBMS (like Oracle) start telling me that what I want to do isn't allowed. Computers are an imagination limited tool and I'd like them to stay that way instead of being fettered by what someone else thinks is the "right way" to do something.

Be careful what you ask for... you might get it.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1572421
« Prev Topic | Next Topic »

Add to briefcase «««12345

Permissions Expand / Collapse