Developers are losing their SQL powers

Today on twitter Chris Hey asked:

EarlOfTwirl Are devs losing the skill of writing good database queries and operations because of the rise in the use of ORMs? Undecided so far..discuss? 07/02/2013 09:11

My answer doesn't fit into 140 chars so I'm going to inflict a rare blog post on you.

 

The evolution of programming (in my myopic lifetime):

Rapid Application Development 

When I was a nipper RAD seemed to be all the rage. Visual Basic & Delphi were the kings in the  world of small to medium business and their developers were knocking up simple interfaces on top of simple databases such as Paradox, dBase and the JET engine. Typically database design was very simple in these applications in db theory terms many of these application started off with a Universal relation and when necessary the applications tended to have a few more tables. Some of the tooling that I experienced helped you glue these queries together producing some suspicious SQL. (And in many dialects ANSI-92 incompatible).

It's probably worth noting at this stage that the whole point of RAD was to rapidly develop applications.  Tooling allowed developers to put together GUIs very quickly and these GUIs were a lot of the time just an interface over the data tables they supported.

As some of these business became more mature the more requirements for the application grew and so therefore so did the number of entities in datastore.

The rise of the enterprise db

There began a new era. As SQL databases became more popular and many applications stored their data in the same databases (or very similar/replicated distributed dbs)  and data became a central part of small to medium businesses's strategy, more questions were asked of the data. In applications and in the relatively new area of Business Intelligence. The developer of this day was asked to do a lot more with asking the database. In addition stored procedures were popular and a lot of business logic was put in there. Data was king and this was the golden of SQL. RDBMS's were begining to look invincible.

The fall

It seems from my point of view at least that not much has come out of RDBMSs in comparision with the application development space. App devs have had to evolve from desktop to web, learn testing, go functional, go dynamic, get SOLID and have had to start testing their own work. In addition to all the tooling changes there was another look at design. A lot of previous systems were developed from a data driven perspective. Now the thinking was to design a system from a domain driven perspective. Databases suddenly became an implementation detail (and a very expensive one in Oracle's case).

So about queries

So what does this little history lesson tell us? Well in the RAD days data and DBs were forming for small to medium orgs. Queries were simple typically as the systems were tightly coupled to UIs and as the whole flipping db was in 1 table. The majority of developers only needed to user very simple SQL. Then RDBMSs became more prevalent and SQL became more popular so geralists had to learn more complicated SQL. As more data was stored in our DBs we had to get smarted with out SQL and learn about optimization too. To get by you needed to know more. Now we are in an age that we are questioning that data should even be stored in an RDBMs there is less motivation for developers to learn SQL in depth.

I think this is a good thing. Application programming is becoming more diverse why learn about SQL if you are say a mobile dev or a front end dev or a game dev? Our industry is demanding more diversity so why not embrace it?

 

Jamming with professionals

So I just watched this:  http://www.sciencedump.com/content/music-language (5  mins long - don't worry which uses the metaphor of music being a language. The video talks about how many musicians "can only be learned by following a strict regiment under the strict tutelage of a skilled teacher." and that with with learning spoken natural language that you are encouraged to make mistakes. It's argument that this model is wrong.

 - Learning is not something you are sent to do just a few times a week.
 - The people you speak to are not just beginners. They are proficient.
 - that if we are only aloud to speak with beginners we will take much longer to speak like an adult.

And that we should learn to embrace mistakes. That we should learn to encourage beginners to play and with accomplished musicians on a daily basis. And that "music works best when we have something to say." as well as that too many rules can slow down learning.

How does this compare with learning our craft? Many new working programmers are not allowed to be in an environment where they can make mistakes. Most of the time we are always 'in concert'. By the nature of those developers being paid to provide a professional service the majority will only ever end up sounding like band in the school play.

There are others who hack at home. These are the musicians that play without fear. They will make mistakes but learn but can also fall in to the trap having one way to do things. Without jamming with professionals how can the enthusiastic hacker know their weak points? Will they only be able to play one tune?

I guess the solution is that we need to have time & space to make our mistakes with mentored supervision. Now I know that there are some companies that promote this & with the advent of code dojo's, hackathons and code retreats we are being give a change to make mistakes. I just wish that I knew that when I was learning to play.

much chin stroking at ddd north

It seems like only yesterday that I was sharing stories and having drinks in the bar at Sunderland AFC after the original DDDNorth but somehow 12 months has passed and all of a sudden its DDD time again. This time the organisers moved the venue to Bradford in attempt to make the event closer to my house. So thanks for that.

The venue was the Bradford University's beautiful School of Management situated just outside the city centre. Registration was a little chaotic but after a quick reorganisation everyone was in and ready.

Stunning Venue.

The venue hosted 4 separate rooms for talks. Unfortunately I've not worked out how to fork myself so I'll take you though the ones I attended.

DDDNorth devs watching a session.

10 practices that made me the developer I am today - Gary Shutler

Before we ask the obvious question of do we want to be the developer Gary is today, it's worth pointing out Gary had aimed this session at developers new to the industry. What followed was a walk through of tips of how to really go from Joe average to a great developer. Most of the advice was sound (especially be diverse, and be responsible for your own training) but there was some controversy when Gary rated code reviews but didn't rate pairing. (note: very simplified interpretation). Gary's beard was immaculately groomed.

Gary gave some great advice.

Async C# 5.0 - Patterns for Real world user - Liam Westley

Technically my favourite session. Liam took us through the Task Asynchronous Pattern white paper.  Async is Microsoft's latest attempt to make doing more than one thing at once easy. What Liam does really well is slip from slides to code whilst maintaining an interesting patter. His test application was a simple mp3 organiser & player which give some great audio cues as to when things were done. This was definitely a session that I came out of eager to try new things. 

Liam's was a fascinating session.

Look Ma! No Frameworks - Gemma Cameron

Gemma's BDD message was that you don't need any stinking framework to do BDD. Forget about the tools and just have the conversations. She showed by the help of the audience how you could write meaningful test code with out having to be constrained by a frame works language. We had a live kata and some interesting discussion with good points raised by the grizzly looking Ian Cooper.

Gemma's interactive session was thought provoking

Websockets and SignalR - Chris Alcock

I've seen this talk before and somehow managed to be in here again. What I love about Chris is that he manages to pack in a tremendous amount of information in to an hour. SignalR and websockets on the front of it are powerful tools.

Another great buzz in the foyer. Not too unlike the sound of a Braun series 3.

Using nuget for fun and profit - Joel Hammond-Turner

Joel has found the solution to code reuse and its been right under our noses. It's NuGet! In this session Joel showed us how to set up our own NuGet server and his PublishNPackage tooling. He's used this effectively to reorganise big code dumps of shared code and is now an integral part of his build process. We got a quick insight how this will be used with CI build too.

I just wanted to thank the organisers for today. It was amazing.