Post by Robert on Apr 10, 2024 8:52:08 GMT -5
George,
I see you have now released SPFLite3. I don't approve of this, and I want you to understand why.
You know, there was a time when a change of this magnitude was something you'd talk over with me in great detail. We'd work out every nook and cranny of the design, so once it saw the light of day, there was a good chance (a) it was documented accurately, and (b) it worked as advertised. It would seem those days are over, since you are no longer interested in my opinion. But, what you have done forces me to give my opinion here, even though personally, I'd rather not. I hate arguing, but this is not an argument, because I am not asking you to change your ways. I know you won't.
I want you to think carefully about how in past times I proposed wild ideas for some damn thing or another. At first you went along with them, but over time and after having been burned enough, you tended to come up with a standard answer. Ready for it? The standard answer goes like this:
"I am trying to back away from major changes. I am XX years old and I can't do this forever. Besides, no one will even know the fix is in there. No one will use it. Putting this in is make-work. It doesn't buy me anything."
And you would summarily shut me down. The standard answer shuts down a lot these days. NOW, suppose some years ago that I had proposed to YOU to make the very change that YOU made to SPFLite3. Wouldn't YOU have given ME the standard answer? "It doesn't buy me anything. Why do it?"
So, George, what does SPFLite3 "buy me"?
1. You removed some perfectly good, working features, because you wanted to wrap up SPFLite3 development prematurely and were too lazy to keep those features in place in your rewrite. And, you were too lazy to properly reach out to the user community, a step that would have delayed the release. (BTW, what is your hurry, anyway?) And even if you did THAT, it overlooks a vital current-events fact: The SPFLite community has been AWOL for the last months at least, with days when NO ONE has even logged on, and when they did, it was just 2 or 3 people, sometimes only you, and sometimes literally no one. Not exactly the right circumstances to be conducting surveys, is it?
2. You completely changed the architecture of the "parser" (oh yeah, you never mentioned WHICH parser; I assume you mean the primary command one, which is not the only one, is it?) when no one that I know of has made a single complaint about the parser failing in years, that I can recall. Tell me again, what does this buy me? I know I didn't ask for this.
3. You have destroyed confidence in the editor. Your changes are so complex that even you, as the author, admit that you yourself are incapable of testing it - despite the fact that you have complete and total knowledge of what was done. So, instead of the only person in the world that even knows WHAT was changed going ahead and doing that necessary, time-consuming grunt work, you have handed off that testing to hundreds of your users, who don't know what the hell they are even looking for to test. And why? You're too bored to do it yourself. So, now every time the editor fails or a macro fails, we ALL are going to have to painstakingly run our own ad-hoc tests to try to figure out what the hell went wrong. Thanks for that.
Now, you can't judge by me, because my use of SPFLite is not at all typical. I am not trying to design software or run a business. But there are users out there who ARE trying to do those things. Maybe some of that activity is critical to a business, and if SPFLite3 is subtly broken, it could cause real harm to them. But, IS SPFLite3 subtly broken? I have absolutely no idea, nor do you, NOR do any of your users.
I can tell you right now, if I depended on SPFLite as part of a business process, there is no way I would use SPFLite3, unless some other braver and more-willing users had the time and energy to test it for me first. I would stay with SPFLite2 for at least a year, because I simply couldn't justify the risk of an unproven, untested editor breaking critical data or editing processes.
For my own use case, I have some quite large macros that I have used for years because they work, and now, I don't remember the details of all the hundreds of lines of macro code I wrote. With SPFLite3, I will have to go through all of them, line by line, to make sure the syntax of every one will still work in version 3, that I don't use any of the features you unceremoniously removed, etc. etc. And, at my stage of life, I am doing good just get up in the morning. Do I have the strength and resolve to exhaustively go through that make work to survive whatever you've done with SPFLite3?
NO.
As I see it, it's unforeseeable that I will use SPFLite3 any time soon, if at all.
I tried to tell you that you needed automated methods to test your changes. You dismissed that, because (again) it was your famed "make work" and you couldn't be bothered. Instead, you are 'bothering' your users to test a new editor that (I am sorry to say) sets back the editor's reliability by 15 years. And I will repeat, USERS are not qualified to properly test everything you've done, because you haven't told us what you changed - not EXACTLY. And even if you did, that presupposes that all of your users have the TIME to do that. Maybe they are very busy running a company, and just wanted their editor to work? Just a thought.
Now, if you at least had a DESIGN DOCUMENT, we could read it for ourselves and use it as a testing guideline. But you never design things first, do you? You haven't worked that way for 15 years, so why start now? Code first, design later, document last, right? We have no way to know if you've even revised everything in the Help to reflect the new circumstances. Documentation is such make work, isn't it?
Remember the bad old days when every other day, some bug was found where commands didn't work right or didn't support ISPF syntax? I remember. But constantly working on those problems as they arose served to address the issues, one at time. Yet now, you have thrown away years of all the hard work that made the old parser - such as it is - quite reliable. Perfect? No, but it was perfect enough. How could you do that to us - to pull the rug out from under us like that?
George, I am sorry to be so critical and throw cold water on your hard work. Perhaps I am too cynical and suspicious. Maybe 99% of the changes work right. Sorry for the poor guy who gets hit with the 1% bad part and ends up destroying their data, but oh well. Achieving perfection is such make work.
In my opinion, you have done your users a great disservice. If you had asked me beforehand (you know, like the "good old days" when you listened to me) I could have given you some advice, and I would have tried to find some way to help you automate your testing so that you might have had some grounds for confidence. I actually know something about this stuff. I worked on object oriented systems where they included testing stubs as part of the object design, and all you do is compile in "test-generator mode" and poof, your design gets tested. Yes, that is pie in the sky design, and SPFLite is not really an actual object-designed program. Still, I actually have testing insights that you don't have. Only thing is, you're not interested in my options and won't listen any more. We're two peas. Two geezers. Listening is just so time consuming, isn't it?
Maybe I'm wrong - and if I am, good for you and good for the users. You may be willing to foist an unproven, untested and untestable alpha program on your users and burden them with finding all the bugs in real time - bugs you yourself are unwilling to find. I just can't do it.
I could advise you on how to get out of this conundrum, but again, you won't listen, and I don't have the heart to argue. What's the use? It won't buy me anything.
Sorry.
I see you have now released SPFLite3. I don't approve of this, and I want you to understand why.
You know, there was a time when a change of this magnitude was something you'd talk over with me in great detail. We'd work out every nook and cranny of the design, so once it saw the light of day, there was a good chance (a) it was documented accurately, and (b) it worked as advertised. It would seem those days are over, since you are no longer interested in my opinion. But, what you have done forces me to give my opinion here, even though personally, I'd rather not. I hate arguing, but this is not an argument, because I am not asking you to change your ways. I know you won't.
I want you to think carefully about how in past times I proposed wild ideas for some damn thing or another. At first you went along with them, but over time and after having been burned enough, you tended to come up with a standard answer. Ready for it? The standard answer goes like this:
"I am trying to back away from major changes. I am XX years old and I can't do this forever. Besides, no one will even know the fix is in there. No one will use it. Putting this in is make-work. It doesn't buy me anything."
And you would summarily shut me down. The standard answer shuts down a lot these days. NOW, suppose some years ago that I had proposed to YOU to make the very change that YOU made to SPFLite3. Wouldn't YOU have given ME the standard answer? "It doesn't buy me anything. Why do it?"
So, George, what does SPFLite3 "buy me"?
1. You removed some perfectly good, working features, because you wanted to wrap up SPFLite3 development prematurely and were too lazy to keep those features in place in your rewrite. And, you were too lazy to properly reach out to the user community, a step that would have delayed the release. (BTW, what is your hurry, anyway?) And even if you did THAT, it overlooks a vital current-events fact: The SPFLite community has been AWOL for the last months at least, with days when NO ONE has even logged on, and when they did, it was just 2 or 3 people, sometimes only you, and sometimes literally no one. Not exactly the right circumstances to be conducting surveys, is it?
2. You completely changed the architecture of the "parser" (oh yeah, you never mentioned WHICH parser; I assume you mean the primary command one, which is not the only one, is it?) when no one that I know of has made a single complaint about the parser failing in years, that I can recall. Tell me again, what does this buy me? I know I didn't ask for this.
3. You have destroyed confidence in the editor. Your changes are so complex that even you, as the author, admit that you yourself are incapable of testing it - despite the fact that you have complete and total knowledge of what was done. So, instead of the only person in the world that even knows WHAT was changed going ahead and doing that necessary, time-consuming grunt work, you have handed off that testing to hundreds of your users, who don't know what the hell they are even looking for to test. And why? You're too bored to do it yourself. So, now every time the editor fails or a macro fails, we ALL are going to have to painstakingly run our own ad-hoc tests to try to figure out what the hell went wrong. Thanks for that.
Now, you can't judge by me, because my use of SPFLite is not at all typical. I am not trying to design software or run a business. But there are users out there who ARE trying to do those things. Maybe some of that activity is critical to a business, and if SPFLite3 is subtly broken, it could cause real harm to them. But, IS SPFLite3 subtly broken? I have absolutely no idea, nor do you, NOR do any of your users.
I can tell you right now, if I depended on SPFLite as part of a business process, there is no way I would use SPFLite3, unless some other braver and more-willing users had the time and energy to test it for me first. I would stay with SPFLite2 for at least a year, because I simply couldn't justify the risk of an unproven, untested editor breaking critical data or editing processes.
For my own use case, I have some quite large macros that I have used for years because they work, and now, I don't remember the details of all the hundreds of lines of macro code I wrote. With SPFLite3, I will have to go through all of them, line by line, to make sure the syntax of every one will still work in version 3, that I don't use any of the features you unceremoniously removed, etc. etc. And, at my stage of life, I am doing good just get up in the morning. Do I have the strength and resolve to exhaustively go through that make work to survive whatever you've done with SPFLite3?
NO.
As I see it, it's unforeseeable that I will use SPFLite3 any time soon, if at all.
I tried to tell you that you needed automated methods to test your changes. You dismissed that, because (again) it was your famed "make work" and you couldn't be bothered. Instead, you are 'bothering' your users to test a new editor that (I am sorry to say) sets back the editor's reliability by 15 years. And I will repeat, USERS are not qualified to properly test everything you've done, because you haven't told us what you changed - not EXACTLY. And even if you did, that presupposes that all of your users have the TIME to do that. Maybe they are very busy running a company, and just wanted their editor to work? Just a thought.
Now, if you at least had a DESIGN DOCUMENT, we could read it for ourselves and use it as a testing guideline. But you never design things first, do you? You haven't worked that way for 15 years, so why start now? Code first, design later, document last, right? We have no way to know if you've even revised everything in the Help to reflect the new circumstances. Documentation is such make work, isn't it?
Remember the bad old days when every other day, some bug was found where commands didn't work right or didn't support ISPF syntax? I remember. But constantly working on those problems as they arose served to address the issues, one at time. Yet now, you have thrown away years of all the hard work that made the old parser - such as it is - quite reliable. Perfect? No, but it was perfect enough. How could you do that to us - to pull the rug out from under us like that?
George, I am sorry to be so critical and throw cold water on your hard work. Perhaps I am too cynical and suspicious. Maybe 99% of the changes work right. Sorry for the poor guy who gets hit with the 1% bad part and ends up destroying their data, but oh well. Achieving perfection is such make work.
In my opinion, you have done your users a great disservice. If you had asked me beforehand (you know, like the "good old days" when you listened to me) I could have given you some advice, and I would have tried to find some way to help you automate your testing so that you might have had some grounds for confidence. I actually know something about this stuff. I worked on object oriented systems where they included testing stubs as part of the object design, and all you do is compile in "test-generator mode" and poof, your design gets tested. Yes, that is pie in the sky design, and SPFLite is not really an actual object-designed program. Still, I actually have testing insights that you don't have. Only thing is, you're not interested in my options and won't listen any more. We're two peas. Two geezers. Listening is just so time consuming, isn't it?
Maybe I'm wrong - and if I am, good for you and good for the users. You may be willing to foist an unproven, untested and untestable alpha program on your users and burden them with finding all the bugs in real time - bugs you yourself are unwilling to find. I just can't do it.
I could advise you on how to get out of this conundrum, but again, you won't listen, and I don't have the heart to argue. What's the use? It won't buy me anything.
Sorry.