Re^5: Have SQL standards gone too far?

The document that you link to (that you wrote) seems very good. On the post here that I comment on here I don't quite agree with your final point.

Let me give an example. Imagine a T-SQL or SQL system. In doesn't really matter if it is that or a Perl or Python program. There are equivalences in data structures and associated commands. In this system there is a requirement to perform complex statistics. The requirements of the system are not laid out from the beginning. So what we have is a set of interrelated statistic related calculations performed. Over time there are new datasets, different types of datasets, variation on the statistical methods, transformations and adjustments on the data and also variations in how the data is presented to the user of the system. Non of this is known from the onset by the developer. The developer is forced (rightly or wrongly) to follow an agile approach. If I was to develop such a system then would I want to use the SQL-92 standard or the most modern standard for SQL. Given the list that you link to I would argue that the SQL-92 standards would be better. More than that, it may be essential. Therefore an agile team should perhaps enforce the SQL-92 standards.

Now imagine that the system was developed using Perl and not SQL, which it could be using map functions instead of SELECT etc. The same would apply. Therefore there could be restrictions put on code to facilitate Agile development. Am I right?

Comment on Re^5: Have SQL standards gone too far?

Replies are listed 'Best First'.
Re^6: Have SQL standards gone too far? by eyepopslikeamosquito (Archbishop) on Jan 17, 2021 at 10:19 UTC
The requirements of the system are not laid out from the beginning. So what we have is a set of interrelated statistic related calculations performed ... None of this is known from the onset by the developer. The developer is forced (rightly or wrongly) to follow an agile approach ... an agile team should perhaps enforce the SQL-92 standards. Unclear requirements are a very common problem. I see them so often I wrote a series of articles about it. If you and your team are suffering from chronically unclear requirements, the SQL-92 standards won't save you. Instead, you need to have the courage and honesty/transparency (often lauded in Agile) to have a serious conversation with your Product Owner, explaining that it is wasteful and disrespectful to your Dev team to ask them to proceed with unclear requirements. Be proactive: if your Product Owner is lacking resources (goes with the territory in my experience) volunteer your team to do an initial sprint with the sole goal of clarifying requirements, using some of the techniques mentioned in Building the Right Thing (Part III): Customers such as: Distill customer interviews and customer conversations into a manageable set of Personas. Make these personas visible to everyone. Ask why. Understand why. Find the root of the problem. Understand the problem. Define the solution. User Journey Mapping. Shows end to end flow of a persona using a feature, starting with installation. Get the user journey right (e.g. map out how someone enters/exits a feature). Value-stream mapping. Fake it till you make it. Use a variety of Pretotyping techniques.	[reply]

Replies are listed 'Best First'.

Re^6: Have SQL standards gone too far?
by eyepopslikeamosquito (Archbishop) on Jan 17, 2021 at 10:19 UTC

The requirements of the system are not laid out from the beginning. So what we have is a set of interrelated statistic related calculations performed ... None of this is known from the onset by the developer. The developer is forced (rightly or wrongly) to follow an agile approach ... an agile team should perhaps enforce the SQL-92 standards.

Unclear requirements are a very common problem. I see them so often I wrote a series of articles about it. If you and your team are suffering from chronically unclear requirements, the SQL-92 standards won't save you.

Instead, you need to have the courage and honesty/transparency (often lauded in Agile) to have a serious conversation with your Product Owner, explaining that it is wasteful and disrespectful to your Dev team to ask them to proceed with unclear requirements. Be proactive: if your Product Owner is lacking resources (goes with the territory in my experience) volunteer your team to do an initial sprint with the sole goal of clarifying requirements, using some of the techniques mentioned in Building the Right Thing (Part III): Customers such as:

Distill customer interviews and customer conversations into a manageable set of Personas. Make these personas visible to everyone.
Ask why. Understand why.
Find the root of the problem.
Understand the problem.
Define the solution.
User Journey Mapping. Shows end to end flow of a persona using a feature, starting with installation.
Get the user journey right (e.g. map out how someone enters/exits a feature).
Value-stream mapping.
Fake it till you make it. Use a variety of Pretotyping techniques.

[reply]