SQLServerCentral Editorial

Will Coding Be Less Important?

,

How many of you can read Greek? I can decipher the alphabet and pronounce words, but that's about it. I thought about this after running across an essay that says that coding will eventually be as important to most people as ancient Greek, which is to say, hardly important at all. The author seems to suggest that eventually we'll tell systems what we want and they'll build algorithms. I guess that's what we do in code, but the impression I have from the piece is that we'll use natural language to inform some AI system that will actually produce the code.

Possibly, but let's set that aside for a minute. Assume that we could have an AI that removed the need for us to code the corporate CRUD systems or most of the websites we have. Could such a system be adapted to manage data?

Possibly, and maybe more consistently than we can. Certainly plugging in RTO/RPO values and HA needs might allow an AI like system to schedule backups, build up or tear down new nodes in a cluster or Availability Group, and certainly respond to DBCC errors, reindex systems, and more. I certainly could see that we could request a system to do X and lots of the background details would be handled. 

There are some other thoughts about this piece that I tend to agree with. The ability to easily specify the way in which a system can work, for the average or even above average user, isn't coming soon, if ever. The thing is, I'll take solace in something that I truly believe.

Writing the code isn't the hard part.

Sure, syntax can be challenging, and working out the mechanics of how modules interact, and building MAKE-like scripts, and deploying changes are difficult. We forget about the differences in environments and configuration, and I bet better static analysis and AI might help here. The thing that's really hard, that is likely to still exist even if we specify the way something works is that it's really, really hard to be specific.

We struggle to express the exact way that systems should work. We struggle sometimes to communicate what "a discount for more than 10 pieces" means. Is that a discount at 10? At 11? what if there are 20 ordered and 10 returned? Do we remove the discount or pro-rate the return? We can solve the issue, but so often, we don't know there's an issue until the system gets into production. Changes in rules/regulations? We don't often know about them, much less know how to express those changes in plain language. 

Even if we could get by without writing code, the expression of "how" something works likely requires a lot of detail, a meticulous person, and endless patience to get the machine to understand. Something many developers do now. I suspect the same thing would be necessary for database development. Even if we could specify the result set, would we really trust the machine to query the source and not come up with multiple ways to get this result set, which might not be valid for another?

Call my cynical, but coding isn't going away, even if the syntax changes to English (or some other spoken tongue). 

Rate

5 (1)

You rated this post out of 5. Change rating

Share

Share

Rate

5 (1)

You rated this post out of 5. Change rating