The Sequel to SQL

  • The sequel to seeqwell is SQL.

  • Comments posted to this topic are about the item The Sequel to SQL

    Best wishes,
    Phil Factor

  • One of the few things to do with computing that has not seen multiple order-of-magnitude reductions in cost over the past 40 years is application development.  This has always been expensive, and has always been on senior management radar as a cost-cutting target.

    Where managers want to hear about how costs can be cut by 20%, 50% or 80% they will listen to whoever is selling this message.  IT managers are not immune from this, if they are not listening to what the C-level people are hearing they may soon hear the sound of 'Goodbye'.

    The last 15 or so years have been dominated by .Net with Visual Studio, or LAMP with Eclipse if you are outside the Windows mainstream.  Although SSIS (and DTS before it) had a promise of code-free development they never became mainstream for application development.  Partly because they were considered part of the SQL niche, and partly because they could not deliver on the code-free promise.

    We are now seeing a new raft of tools promising code-free development but aimed squarely at application developers.  Anybody concerned about costs would be daft to not look at these tools and get a project or two going to try them out.  I suspect the normal result will follow - for simple things they will be code-free but for anything complicated (like enterprise-quality systems) code will be needed.

    Management then has a dilemma.  Do they major on training people to add the necessary code to the code-free tools, plus retain enough people to write traditional .Net code for where the code-free does not touch.  Or do they maintain standardisation on .Net so they can swap developers around as needed.  By 2025 we will know the answer.

    My view is that application development will remain expensive.  Code-free will move into departmental computing and get added to the morass of Access, Excell, and other uncontrolled stuff.  Central IT will still be using Visual Studio and the latest .Net things, albeit that by 2025 .Net (or Eclipse) will have progressed a long way from what we see today.

    Original author: 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • I used to work for Burroughs and I joined a project team in Detroit in 1972 that was developing a system to make application programming redundant. It was known as PARSEL for parameter selector. We got too expensive for the marketing people. Management was just over 100% from marketing and they cancelled the project. It wouldn't have worked anyway. We didn't have the technology to take a spoken description of system requirements and turn it into a working application. Have you ever heard a rational requirements definition from a user?

    We had the output layer more-or-less working. You could specify L/TC assembler or medium systems COBOL. We hadn't got around to defining the database.

    Management decreed around about that time that everything in the company had to be written in a 3GL. For us, that was COBOL. The first statement in the procedure division was "Enter Symbolic". The last statement was "Enter COBOL" followed by "END". In between there were around 90,000 lines of Assembler.

    As far as I'm concerned, we still don't have the technology to turn spoken word requirements into a working application for any platform.

    Management should be focused on maximising the shareholders' equity. I think that they are mainly focused on maximising their short-term income. They will only get interested in a software development if they can see short-term profits. If they own the company, then they might have an interest in the long term. Good luck with that.


  • I don't see a conflict between having code-free tools and experienced developers.   You cite a study that says 30% of development will be using code-free tools.   That still leaves 70% to be done using traditional coding.

    Code abstraction is the basis of most development.  Write a low level function that can be called by a higher level function.  Repeat several times until you end up with a drag and drop component in a code-free visual programming tool.    As the lower level coding becomes more complex with distributed systems, security, encryption, etc, even senior developers can benefit from "canned" solutions to deal with some of those issues.

    There will always be a need for developers (of all levels).   If the code free tools can expand the pool of people capable of developing a program, then that is a net benefit.  Aside from lowering costs of development, I think management struggles with finding people to do the development.   Allowing non-programmers to tackle the low-hanging fruit of custom reports, gathering data from multiple sources, basic data analysis, means the senior developers can spend more time on the complex enterprise development needs.



  • "SQL (originally SEQUEL) was envisioned as a fourth-generation declarative language that would require minimal training and that anyone could use to get information from databases. "

    And, as usual, therein lies the problem.  Over my 42 years in IT during which I more and more specialized in db design and SQL development and testing, the problem is often that we assume anyone can get information from databases.  While that is basically correct, the variation in skill level that I witnessed convinces me that the idea of minimal is dangerous.  The old adage that says 'you get what you pay for' is not always true, but from what I experienced, there are certain thinking abilities and innate 'empathetic'  understandings that are crucial, and can only be developed through years of experience.

    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • I am impressed by the Microsoft Power Platform of Power BI, PowerApps, and Microsoft Flow. As an old grizzled VBA, Java, Ruby, Clojure, and Power BI (DAX) dev, I like using tools that handle the routine and let me just add value-producing code to the data model or code.  Microsoft at least builds the base field in the corn for "citizen" developers. Whether or not they come, we'll see, but they are making a platform that is possible for business users, which means it is easy for devs.  I'd rather use the Power Platform when possible instead of taking a day to set up my machine to dev with the latest build stack for the JavaScript flavor of the year.

  • It's not about marketing vs developers. Not at all. It's not about doing away with the need for skilled professional developers. It's about getting things done.

    Information systems design is primarily about understanding the needs of the users. There is a reason why Design Thinking starts with Empathy. There is a lot of pain out there caused by inadequate systems built by these "skilled professional developers." Time and again I have seen "skilled professional developers" put the bar way too low. They give access to information and they think they have done their job. (Roll your eyes here.)

    If only "skilled professional developers" took the time to understand what the user needs, they would be so much more productive. They would actually serve their customers. How about that? Wouldn't that be great?

    If the only way users can communicate what they want is by building a crappy prototype with all kind of issues, then we should encourage this because at least they are communicating what they want. There is a world of opportunities out there for information systems but the people struggling there are not trained to think in terms of what information systems can do for them. So whenever people suggest that each kid should learn programming in school I roll my eyes because what each kid should actually learn is what computers can do for them and how to communicate their information needs. I have met PhDs who cannot imagine what information systems can do for them, even though they have hundreds of Excel files to manage on SharePoint. Go figure.

    So yes, study PowerBI and Self-Service BI. Encourage your customers to learn what information systems can do for them. Study their work, and really commit to understanding what they want to achieve. And then build on that. Aim to delight them. Then your skills can help improve what they have cobbled together. And then you understand what they want and can make them smile and appreciate your work.

  • I can remember the "revolution" that were things like RPG, Oracle CASE, et cetera, all of which were tools that wrote code for the developer. Much of the time we spent working out how to work around the tool to get it to work properly. Some of those tools are still around and very successful; the two that spring to mind are Jade and WhereScape RED. The tools don't do away with the need for developers though; instead, they create very specific, domain-specific developers.

    I think the desire to automate what should be an automated task (code generation) won't go away; we're very familiar with wanting to write code at higher levels of abstraction and let the computer translate that for us.  That's the ethos of the compiler, after all.  It doesn't surprise me that we continue to improve our tools and languages, and continue to push the level of abstraction.

    I do agree that thinking that the need for developers will go away has no substance.  I think that we have more developers in the world now than ever before, and we are already using high-level assisted programming languages and tools.  I don't see that changing in my lifetime.

  • A solution to everything is a solution to nothing.  I'm also an 'old grizzled DBA', besides being a front-end code developer for years, and I saw way too much of this during my years.  Fortunately, I never had to deal with a large number of 'end-user solutions' during my years, but I never saw a good one - EVER.  Typically they served only a portion of the real need, and then were dumped on those of us in IT to try to deal with and make viable.  Also, over the years I dealt with any number of 'packaged solutions', and not even one of those, no matter how expensive and comprehensive, served the entire purpose.

    Generalized solutions pretty much give generalized results.


    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • End- user solution are becoming better and better now that OO databases are becoming increasingly more popular. And it is the fact that these databases are OO or relational. It is that OO often treats schema as a second class citizen. Schema adapts to the data entered. And only when it makes sense do you define constraints (and even finer constraints that data types give you).

    The goal of a software developer is to develop ourselves out of a job. DBA should be to install yourselves out of a job. The difference? DBA are there for every install.

    When you get a new stereo for you car, do you ruin your car putting it in yourself? Or do you higher a professional.

    Infrastructure and the software ecosystem should be no different. Ansible is Like the stereo adapter kit the radio fits in any model of car it needs to. Power shell is the wiring.

    If PhD are the ones who developed the optimizations for the triple-calculus in the database, why aren’t they babysitting the schema? Why don’t we need PhD to understand the database?

    It is because they are successful. DBA aren’t skillful enough to take it to that level and develop an installer or whatever is needed so they are no longer needed.

    Or maybe there are DBA who are. And this is the mentality DBA who aren’t quite there should have. It is important to finish what you start...



  • "..It is somewhat odd that so many of the opinion-formers on the technology of the IT industry have so little experience working in the industry as technologists. Few other professions are so clearly led by marketing people.."

    I don't think the marketing people are even targeting IT; at the end of the day they're gold diggers targeting C level executives and venture capitalists. But just like how some 19th century Gold Rush towns soon outlived their original intended business model and went on to became modern cities where regular people actually work and live, the abandoned half baked NextGen technologies hyped by marketers today are parted out and folded into other something IT products. For example, the whole idea that enterprise IT shops would maintain distributed file system databases using a closet full of on-prem commodity hardware, that idea never really took off broadly speaking. But that HDFS style technology now underpins Azure and Amazon cloud services. Today, NoSQL has Microsoft's corporate logo stamped on it's rear end.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I see both in use, and PowerBI is a great example. Or even the Power-XXX suite. A user or non-technical (less expensive) individual can prototype something or get something useful done. It might not scale, and it might need attention, but they can prove it's worth investing in. Same with CodeFirst, EF, nHibernate, etc.

    The challenge at times is then getting someone to invest more and use technical staff to enhance the application. There are companies that do this well, seeking to maximize their investment in development resources, rather than spec'cing out big projects that aren't proven or thought through. There are, of course, plenty of companies that try to just get by on their prototype, no different than things written in C# or Php.

  • My thought is more like a question. Why can't more features and functionality be added to SQL language and stop creating more languages to learn? If not, let's all go back to C++ and call it a day.

    • This reply was modified 4 years, 11 months ago by  Rudy Panigas.


  • Rudy, I guess I'm an old-timer, but my take is that we should not add lots of 'bells and whistles', but keep SQL pure and effective at what it is good at doing.  Stick to the original purpose and need of basic, pure, DB level access which is clean, quick, effective and simple.  The front-end languages are for and are better at all the other stuff.  SQL needs to stay clean, fast ( if well written ), and powerful without getting all bogged down with fancy stuff.

    That said, I do wish sometimes that I still had some of the front-end skills that would allow me to do a better job of formatting and seeing my data.  When they added the ability in Enterprise Manager to place query results in a table format and to do line-by-line updating, that was a great help.


    Disaster Recovery = Backup ( Backup ( Your Backup ) )

Viewing 15 posts - 1 through 15 (of 37 total)

You must be logged in to reply to this topic. Login to reply