Accidental complexity - SQL Antipattern #007

15 February,2016 by Jack Vamvas

I was recently  introduced to a term called Accidental Complexity. It was discussed by Fred Brooks in his essay No Silver Bullet -- Essence and Accidents of Software Engineering.

The essence of the essay is that many software systems are overly complex , and all effort should be exercised to erase complexity. He differentiates between essential complexity and accidental complexity.The essay progresses through a series of steps focusing on programming languages. The steps outline how programming languages have evolved to deal with complexity. Brooks argues that there is no one development that can completely change the game of technology. "No Silver Bullet"

Reading the essay , one idea which struck me , was his argument of the exponential gains to be made from decreasing essential complexity over decreasing accidental complexity.

Although he presents clear definitions on the differences between essential complexity and accidental complexity, I find it useful to think about where is the dividing between the two definitions. For example, many Enterprise software platforms are shipped with an ever increasing amount of features.

Although there are core features , which remain the main selling point - there are now a ton of extra features. One factor driving the addition of features is competition. This leads to solutions which create extra complexity in managing systems.

For example, If there are already standards in an organisation for backups , why introduce another method of backup. Think of the extra documentation, training , licening management etc , which comes with using these "extra" features.

SQL language is a custom language, maybe one of the most successful languages. As the SQL language has progressed and applied in different ways accidental complexity has arisen. SQL injection results from using one language from within another by doing string manipulation. When SQL  was developed , this was not the intention.

The SQL injection method remains the same. i.e the data starts with (‘)  , appends the Trojan SQL code and ends with the comment mark (--) . The effect of the (--) is to comment out the original SQL intended to be submitted.

 Other examples within SQL leading to accidental complexity (death by a thousand cuts)  :

1) No set theory and  lack of data modelling - DBA - Database Architect - Data Architect - What’s the difference ?

2) Poor Concurrency control

3) Integrity rules decisions - Where to maintain data integrity rules? - SQL Server DBA

 

Accidental Complexity is part of the  SQL Antipattern series. 


Author: Jack Vamvas (http://www.sqlserver-dba.com)


Share:

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment on Accidental complexity - SQL Antipattern #007


sqlserver-dba.com | SQL Server Performance Tuning | SQL Server DBA:Everything | FAQ | Contact|Copyright & Disclaimer