March 1, 2017 at 4:11 pm
Steve Jones - SSC Editor - Wednesday, March 1, 2017 9:01 AMJeff Moden - Wednesday, March 1, 2017 8:36 AMIronically, the very techniques talked about in this article apparently haven't been exercised for the recent forum update and one of the most important parts of this site, the SQL Code windows, still doesn't work correctly. They still double-space and delete leading spaces if you copy and paste from SSMS. They still come up with all sorts of wonky colorization if you make a trip through NotePad (for example) to preserve the spaced indentation. What happened to test and UAT?
That's not remotely true. Things were tested and users worked with them. That didn't guarentee there were fixes, and for a number of items, there aren't good fixes with rewriting lots of code. Which means we're either in the business of full time forum development or we must redo all that work with every software upgrade.
We are working with the vendor to try and incorporate some fixes into their codebase to handle some issues, but some don't have good solutions that we can easily implement.
[/quote]
so can we assume that these "glitches" that were not guaranteed to be fixed, were recognised during the evaluation stage, prior to awarding the contract for the forum software?
Or is that it was only after the contract was signed, that these 'glitches' became apparent?
Having suffered similarly in the past on more than one occasion, despite the fact that after my evaluation (which I was employed to perform) that SYS2 was better than SYS1....some "other person" awarded it to SYS1.
I then spend mths/years sorting the shite out!
Wonder who made the decision on this new forum software?
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
March 1, 2017 at 4:35 pm
Jeff Moden - Wednesday, March 1, 2017 1:50 PMSteve Jones - SSC Editor - Wednesday, March 1, 2017 9:01 AMJeff Moden - Wednesday, March 1, 2017 8:36 AMIronically, the very techniques talked about in this article apparently haven't been exercised for the recent forum update and one of the most important parts of this site, the SQL Code windows, still doesn't work correctly. They still double-space and delete leading spaces if you copy and paste from SSMS. They still come up with all sorts of wonky colorization if you make a trip through NotePad (for example) to preserve the spaced indentation. What happened to test and UAT?That's not remotely true. Things were tested and users worked with them. That didn't guarentee there were fixes, and for a number of items, there aren't good fixes with rewriting lots of code. Which means we're either in the business of full time forum development or we must redo all that work with every software upgrade.
We are working with the vendor to try and incorporate some fixes into their codebase to handle some issues, but some don't have good solutions that we can easily implement.
Glad to hear you're working with the vendor but, what I said is true or not in your opinion, the results still speak for themselves, Steve. It's difficult for me to understand why probably the most popular SQL Server forum in the world, which is owned by a company that makes some of the most popular software in the world, allowed for such a thing to happen. I'm not going to bail or anything like that because of it but it does make your good article extremely ironic.
[/quote]Surely such big problems with copying code from elsewhere and pasting it into a code box in a message should have been visible long before the UAT stage - they should have been obvious at Unit Test and the code shouldn't have been handed over for User Acceptance Trials until the problems were down to something acceptable. The only ways I can see for the thing to have reached UAT with such problems outstanding are (i) the requirements were incomplete - this particular feature was not adequately specified or (ii) there was no serious attempt to do proper unit testing, gradually building and testing larger components. The only ways for it to get through UAT and be rolled out to production seem to be (a) the UAT left these areas untested or (b) UAT failures were ignored and the system rolled out before it was fit to be rolled out.
The new forum software isn't an out-and-out disaster - in fact I've seen far bigger screw-ups rolled out. So it's nowhere near the bottom of the scale - but it does seem to me that it is, as Jeff suggests, pretty solid evidence of some serious holes in the quality management process both during the development process (where this level of bug should have been found and eliminated) and during the validation phase (which should probably have thrown it straight back to development as soon as the code paste bugs were detected).
The idea that a fix for the code copying problem could take a vast amount of development is quite frightening - what ought to be a fairly small function with clean boundaries and a clear specification is apparently so interwoven into other parts of the product that fixing it will be a major problem. That suggests that no-one attempted to apply any decent principal of modularity. That to me seems a far bigger error than failing to do some of the neccessary early testing and not holding the rollout back when the resulting problems were detected.
Tom
March 1, 2017 at 5:04 pm
Gary Varga - Wednesday, March 1, 2017 6:54 AMSergiy - Wednesday, March 1, 2017 4:43 AMOh, really?How much did they pay you, say last month, for the software which you developed 5 years ago and which is working since then with no issues?Ah, you probably never came across such software.In hour experience.:-)I am paid to deliver quality software. They wouldn't have me here, where I currently am, if I didn't.
I am just saying that my experience is different. It happens.
"Quality software" is quite a strercheable definition.
Does your definition of quality software include "No Post-Deployment bugs"?
I suspect no, because I'm still to hear about a software which never required post-deployment hot fixes.
From this - there are 2 questions for you:
- Are you paid for the time you spend on fixing those bugs?
- Do you get a paid time off for not having those bugs?
If you answer these question honestly, than my point will become clear.
_____________
Code for TallyGenerator
March 1, 2017 at 5:05 pm
We made a business decision on the copy/paste of code. You can disagree, but we decided that since IE is about 15% of our audience, that the 85% who have browsers that work fine were enough for us to roll things out. I'm happy to discuss the decision elsewhere, but I'm not hijacking this thread to do it.
We detected the issue early on, and users did as well. The fact that we decided it wasn't important enough to fix has nothing to do with us detecting, evaluating and prioritizing the issue. The discussion here is about finding those issues, with monitoring, with testing, with something else. Not everything found will be fixed, and certainly not fixed at a point in time.
March 1, 2017 at 5:16 pm
Steve Jones - SSC Editor - Wednesday, March 1, 2017 5:05 PMbut we decided that since IE is about 15% of our audience, that the 85% who have browsers that work fine were enough for us to roll things out.
Not hijacking this thread - just a quick note.
There are huge problems operating the forum from Safari on iPad.
Quotes, IFC - simply not there.
_____________
Code for TallyGenerator
March 1, 2017 at 5:20 pm
Sergiy - Wednesday, March 1, 2017 5:16 PMSteve Jones - SSC Editor - Wednesday, March 1, 2017 5:05 PMbut we decided that since IE is about 15% of our audience, that the 85% who have browsers that work fine were enough for us to roll things out.Not hijacking this thread - just a quick note.
There are huge problems operating the forum from Safari on iPad.
Quotes, IFC - simply not there.
Post issues in the "Website Issues" forum. Safari would be way down our list.
March 1, 2017 at 7:40 pm
Testing is really the way to catch more issues before humans do.
No testing as we know it can catch the issue you indicated in the article: "SELECT * "
It's rather about "quality assurance" for the code.
but so many developers have been resistant to the idea of building some sort of formal test for their code. It's not fun, it's hard to maintain, and really, it's just hard for most people to start writing tests.
And it's really frustrating for BA's s and the management to compromise delivery deadlines because of some stupid "minor issues" revealed by @extreme-2 testing" of features which "90% of users will not touch anyway".
I may assure you, I did not invent all these terms.
As for developers - who would like to run testing which may turn shiny coach (aka "Quality Software") into an ugly pumpkin (buggy bunch of unmanageable scripts)?
Developing a proper test is more complex task than developing a software itself.
To get it right we need to start with developing tests, before starting with software itself.
So far I saw an appropriate approach to testing only in Apple under Steve Job.
Everyone else (including current Apple) simply "cannot afford" proper testing and let consumers to be their guinea pigs.
_____________
Code for TallyGenerator
March 1, 2017 at 9:19 pm
Sergiy - Wednesday, March 1, 2017 7:40 PMNo testing as we know it can catch the issue you indicated in the article: "SELECT * "
It's rather about "quality assurance" for the code.Developing a proper test is more complex task than developing a software itself.
To get it right we need to start with developing tests, before starting with software itself.
So far I saw an appropriate approach to testing only in Apple under Steve Job.
Everyone else (including current Apple) simply "cannot afford" proper testing and let consumers to be their guinea pigs.
The first part isn't true. SQL Cop and other static code analysis packages will detect and find a "SELECT *" in T-SQL. Other .NET (or application packages), can detect this inline in code.
The second part isn't true either. While companies do release products and let customers give feedback, many of them also constantly increase and add to their testing suites. They prevent regressions and do increase quality over time. Are they 100% No, but no one is. Not sure that's even possible.
March 2, 2017 at 1:40 am
Sergiy - Wednesday, March 1, 2017 5:04 PMGary Varga - Wednesday, March 1, 2017 6:54 AMSergiy - Wednesday, March 1, 2017 4:43 AMOh, really?How much did they pay you, say last month, for the software which you developed 5 years ago and which is working since then with no issues?Ah, you probably never came across such software.In hour experience.:-)I am paid to deliver quality software. They wouldn't have me here, where I currently am, if I didn't.
I am just saying that my experience is different. It happens.
"Quality software" is quite a strercheable definition.
Does your definition of quality software include "No Post-Deployment bugs"?
I suspect no, because I'm still to hear about a software which never required post-deployment hot fixes.
From this - there are 2 questions for you:
- Are you paid for the time you spend on fixing those bugs?
- Do you get a paid time off for not having those bugs?If you answer these question honestly, than my point will become clear.
You said:
...Software engineers are paid for fixing issues, and never - for absence of them...
I disagree. I have been brought in on a number of occasions because there will be fewer defects. I certainly wasn't suggesting absolute absence but absence of defects that would otherwise be there. Never is a very strong word.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2017 at 1:59 am
Steve Jones - SSC Editor - Wednesday, March 1, 2017 9:19 PMSergiy - Wednesday, March 1, 2017 7:40 PMNo testing as we know it can catch the issue you indicated in the article: "SELECT * "The first part isn't true. SQL Cop and other static code analysis packages will detect and find a "SELECT *" in T-SQL. Other .NET (or application packages), can detect this inline in code.
You can always protect your database against SELECT * by putting a computed column that attempts to evaluate 1/0 on each table... Not saying it's a good idea, mind, but it's possible...
Thomas Rushton
blog: https://thelonedba.wordpress.com
March 2, 2017 at 2:33 am
Gary Varga - Thursday, March 2, 2017 1:40 AMYou said:...Software engineers are paid for fixing issues, and never - for absence of them...
I disagree. I have been brought in on a number of occasions because there will be fewer defects. I certainly wasn't suggesting absolute absence but absence of defects that would otherwise be there. Never is a very strong word.
What exactly you disagree with?
You say: I have been brought in on a number of occasions because there will be fewer defects.
"Will be fewer issues" - Doesn't it mean that there were a lot of issues when you've been brought in?
And they ask you to do what? making them fewer, did I read you right?
So, according to your own statement, you've been paid for fixing the issues.
My words:
...Software engineers are paid for fixing issues
What exactly you disagree with?
Then, since you've fixed those issues (assuming ytou did your job well and delivered a real quality software) - how much did they pay you for the priviledge of not spending more time and money on another bugger who would need to fix issues you could leave/introduce in the system if you'd do your job not so well?
i think I know the answer. t's here:
... and never - for absence of them...
If you still disagree, name the rate.
_____________
Code for TallyGenerator
March 2, 2017 at 2:50 am
Steve Jones - SSC Editor - Wednesday, March 1, 2017 9:19 PMSergiy - Wednesday, March 1, 2017 7:40 PMNo testing as we know it can catch the issue you indicated in the article: "SELECT * "
It's rather about "quality assurance" for the code.Developing a proper test is more complex task than developing a software itself.
To get it right we need to start with developing tests, before starting with software itself.
So far I saw an appropriate approach to testing only in Apple under Steve Job.
Everyone else (including current Apple) simply "cannot afford" proper testing and let consumers to be their guinea pigs.The first part isn't true. SQL Cop and other static code analysis packages will detect and find a "SELECT *" in T-SQL. Other .NET (or application packages), can detect this inline in code.
The second part isn't true either. While companies do release products and let customers give feedback, many of them also constantly increase and add to their testing suites. They prevent regressions and do increase quality over time. Are they 100% No, but no one is. Not sure that's even possible.
Testing is not the same as "code analysis".
Endless loop could pass code analysis with no problems. Not so lucky with testing.
And some really nasty code within a block IF 1=0 BEGIN
....
END
could raise all sorts of warnings from code analysis tools, but will pass any testing without a glitch and would never cause any trouble in Production.
What I said is true - testing (actual testing, not analyzing the code for following suggested practices) will not indicate any issue with SELECT * .
_____________
Code for TallyGenerator
March 2, 2017 at 5:30 am
Sergiy - Thursday, March 2, 2017 2:33 AMGary Varga - Thursday, March 2, 2017 1:40 AMYou said:...Software engineers are paid for fixing issues, and never - for absence of them...
I disagree. I have been brought in on a number of occasions because there will be fewer defects. I certainly wasn't suggesting absolute absence but absence of defects that would otherwise be there. Never is a very strong word.What exactly you disagree with?
You say: I have been brought in on a number of occasions because there will be fewer defects.
"Will be fewer issues" - Doesn't it mean that there were a lot of issues when you've been brought in?
And they ask you to do what? making them fewer, did I read you right?
So, according to your own statement, you've been paid for fixing the issues.
My words:...Software engineers are paid for fixing issues
What exactly you disagree with?
Then, since you've fixed those issues (assuming ytou did your job well and delivered a real quality software) - how much did they pay you for the priviledge of not spending more time and money on another bugger who would need to fix issues you could leave/introduce in the system if you'd do your job not so well?
i think I know the answer. t's here:... and never - for absence of them...
If you still disagree, name the rate.
Name the rate?
The rate I am paid? No. That is not going to happen. It is client confidential for a start.
The rate of decrease in defects? Sorry, I can't measure both what has and hasn't happened.
The rate per defect or per defect not created? I don't get paid that way.
I can only hope that we are talking at cross purposes.
You said that developers are only paid to fix defects and never for the absence of them. I disagree as I in my experience those that create loads of defects are often got rid of and those that produce less are kept and therefore they are getting paid for the absence of defects. (As I said earlier fewer as opposed to none.)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2017 at 6:10 am
Sergiy - Thursday, March 2, 2017 2:50 AMSteve Jones - SSC Editor - Wednesday, March 1, 2017 9:19 PMSergiy - Wednesday, March 1, 2017 7:40 PMNo testing as we know it can catch the issue you indicated in the article: "SELECT * "
It's rather about "quality assurance" for the code.Developing a proper test is more complex task than developing a software itself.
To get it right we need to start with developing tests, before starting with software itself.
So far I saw an appropriate approach to testing only in Apple under Steve Job.
Everyone else (including current Apple) simply "cannot afford" proper testing and let consumers to be their guinea pigs.The first part isn't true. SQL Cop and other static code analysis packages will detect and find a "SELECT *" in T-SQL. Other .NET (or application packages), can detect this inline in code.
The second part isn't true either. While companies do release products and let customers give feedback, many of them also constantly increase and add to their testing suites. They prevent regressions and do increase quality over time. Are they 100% No, but no one is. Not sure that's even possible.
Testing is not the same as "code analysis".
Endless loop could pass code analysis with no problems. Not so lucky with testing.
And some really nasty code within a blockIF 1=0 BEGIN
....
END
could raise all sorts of warnings from code analysis tools, but will pass any testing without a glitch and would never cause any trouble in Production.What I said is true - testing (actual testing, not analyzing the code for following suggested practices) will not indicate any issue with SELECT * .
And a code analysis tool which raises a warning about every "SELECT * " would only annoy me, because I use that construction all the time.
In EXIST checks, dynamic SQL and in inline comments.
You could use an alternative instead (e.g. SELECT 1). Also some static code analysis tools recognise the idiom and ignore those.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2017 at 6:23 am
Gary Varga - Thursday, March 2, 2017 5:30 AMName the rate?
The rate I am paid? No. That is not going to happen. It is client confidential for a start.
The rate of decrease in defects? Sorry, I can't measure both what has and hasn't happened.
The rate per defect or per defect not created? I don't get paid that way.
The rate you've paid for not fixing your software because you did not leave any issues in it.
Gary Varga - Thursday, March 2, 2017 5:30 AMI disagree as I in my experience those that create loads of defects are often got rid of
Really?
Actually, they form a support team, communicate with customers, run daily scrum meetings, measure average issue resolution time, report team members kpi upstairs, etc.
Because if business will get rid of them then during several months while a new developer will dig through unmanageable code looking for errors the business will simply lose all clients and go down.
and those that produce less are kept
Kept for what exactly?
If everything working fine and does not require daily attention from the IT guy, and it was thought through, so increased scale, new data would not cause any faults/issues - what to keep that employee for? Would any kind of stakeholders approve such an expense?
I don't think so. They'll get rid of such a developer as soon as they sure the software does not have any serious issues.
_____________
Code for TallyGenerator
Viewing 15 posts - 16 through 30 (of 36 total)
You must be logged in to reply to this topic. Login to reply