January 19, 2021 at 3:03 pm
Sometimes it seems that we have to ALLOW failure for success to follow. My wife and I raised four sons after we combined our families. After they were all out on their own, the youngest one along with his wife fell prey to a serious drug problem that was debilitating for both of them. At the lowest point their jobs were ruined and their lives in serious jeopardy.
We had to, as a painting in our home advises, 'Give it to God and go to sleep'. Now, after all their failures, they have been clean for years, started a business, employ about 15-16 people, couple years ago passed their first million-dollar-plus-volume year, and as of last year celebrated their first million-dollar-net year. This winter, at 50 years of age, they are spending two months of the mid west cold winter in sunny Florida.
I think it was President Ronald Regan who famously said 'It CAN be done'.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 19, 2021 at 3:23 pm
Allowing failure: Steve and others use children learning as an analogy for this. That works very well because this is childish. When I am a member of your team, there is no need for failure, ever. The reason is because of this: I am a professional. I seek the best solution in all cases. I use professional techniques to solve problems and avoid failure. When I am on a team comprised of other professionals, I can pretty much guarantee that you will have an acceptable solution in all cases, sometimes a stellar solution, and your risk of failure is minimal. That's what you get with a team of professionals. Apparently, some people are not so fortunate, and for you, I truly feel sorry. For myself, I always seek the best available solution, and failure is not an option.
Edited to add that I am upsetting myself the more I think about this topic. Someone who is in charge of a production database, thinking this way? "Oops, sorry I brought down production, my bad. At least I learned something"??? Who on earth would think this is ok?
George, I'll try to say this nicely. I think it is naive to think that teams cannot fail. In fact, I have experienced that in my career. Teamwork does in no way guarantee success, it maybe be a factor, and might just encourage it somewhat. Besides, the 'best' solution available may not always be a good one.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 19, 2021 at 3:36 pm
Good article, Ben. I appreciate it but am not entirely sure I agree. Not on good grounds, just more because I've never worked anywhere that allowed for experimentation. I'm familiar with Mark Zuckerberg's maxim, "Fail fast and break things". Everywhere I've worked failure is not tolerated. You may be right, I've just never experienced it.
Kindest Regards, Rod Connect with me on LinkedIn.
January 19, 2021 at 3:40 pm
Good article, Ben. I appreciate it but am not entirely sure I agree. Not on good grounds, just more because I've never worked anywhere that allowed for experimentation. I'm familiar with Mark Zuckerberg's maxim, "Fail fast and break things". Everywhere I've worked failure is not tolerated. You may be right, I've just never experienced it.
Rod, maybe you can get away with failing fast and breaking things only if you are the boss.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 19, 2021 at 10:04 pm
Allowing failure: Steve and others use children learning as an analogy for this. That works very well because this is childish. When I am a member of your team, there is no need for failure, ever. The reason is because of this: I am a professional. I seek the best solution in all cases. I use professional techniques to solve problems and avoid failure. When I am on a team comprised of other professionals, I can pretty much guarantee that you will have an acceptable solution in all cases, sometimes a stellar solution, and your risk of failure is minimal. That's what you get with a team of professionals. Apparently, some people are not so fortunate, and for you, I truly feel sorry. For myself, I always seek the best available solution, and failure is not an option.
Edited to add that I am upsetting myself the more I think about this topic. Someone who is in charge of a production database, thinking this way? "Oops, sorry I brought down production, my bad. At least I learned something"??? Who on earth would think this is ok?
So you've NEVER had management overrule you as a DBA? Now, that must be nice.
That's happened to me several times despite us all being "professional" and all. In one case that was extremely dangerous, I dug in and wouldn't budge instead of giving them the "opportunity to fail". I was called a "non-professional" and not being a "team player" for that even though I didn't lose my cool and continued with all the professionalism in the world. Giving them the "opportunity to fail" on that one time would have been the wrong thing to do. I was overridden anyway and, you guessed it, it failed just as horribly as I said it would.
Sometimes, you do have to train other "professionals" by letting them fail using their method and then do it right using the correct method. Even supposed true professionals are incorrect and when you have a handful of them that all think the same is right and just one DBA that says they're wrong and won't even consider what the DBA is saying, you have to let them feel the sting of their poor decisions and to "train" them to be a bit more "professional".
What's sad is that it usually takes multiple such lessons to knock the chip of their shoulder.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2021 at 10:20 pm
What's sad is that it usually takes multiple such lessons to knock the chip of their shoulder.
Yep, that's because they still don't accept responsibility! I've been in similar situations where I warned and warned, but I was overridden and my prediction came true. Yet I was still held to blame because I didn't "provide enough information" on the situation! It made me feel like Ian Malcolm in Jurassic Park: "Boy, do I hate being right all the time!"
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
January 20, 2021 at 1:04 am
Rod at work wrote:Good article, Ben. I appreciate it but am not entirely sure I agree. Not on good grounds, just more because I've never worked anywhere that allowed for experimentation. I'm familiar with Mark Zuckerberg's maxim, "Fail fast and break things". Everywhere I've worked failure is not tolerated. You may be right, I've just never experienced it.
Rod, maybe you can get away with failing fast and breaking things only if you are the boss.
HAHAHA! That's a good one, Rick.
Rod
January 20, 2021 at 1:40 am
Its evening, I have more time to respond to this.
Ben, I believe there's a lot to what you said. It is valuable to allow people to fail. I've only done a fair job of that as a parent, as more often than I can to admit, I'd "rescue" the child from potential harm.
I'm less certain about work situations. It just isn't as clear to me whether allowing people to fail is a good idea or not. Let me illustrate with an example from my current job.
One of the developers I work with loves to violate the anti-pattern, Action at a Distance. We're working on replacing several old Excel and Access apps with Windows applications (WPF). My colleague made two action at a distance violations/mistakes. One, he'd open a log file when the application first starts up, then leave it open the whole time the app was running. This wasn't too serious a problem, because it's likely users won't run the app (any of them) more than once. But if they did try to open it a second time, they'd wonder why it wouldn't work. It's because the first instance had a hook on the log file, so the second one couldn't touch it. The second instance would silently go away, never appearing. Not a big deal, but it would be curious to the users.
The second one was far more serious. The same guy would open a connection to the database, upon the application starting up, then leave it open the whole time the app is running. Since this app could allow the user to open multiple windows into different tables, then it is possible for a user to really screw themselves up. And since action at a distance anti-pattern is hard to determine and debug, it would go on for a long time. There would be mysterious things like editing one table in one window, then go to another window and start editing a different table. The user might decide to delete a record in the first window, but not immediately save that change, then go to the second window, make changes there and save it. Then they'd go back to the first window and "back out" the deletion in the first window, thinking they succeeded in preventing the deletion.
Only, they hadn't. Because my colleague likes to open a connection once, for the whole application, never closing it until the user closes the application, then any action the user takes to perform a save, would automatically save all other pending actions. I caught this problem before users actually encountered it. (I became wise to the action at a distance anti-pattern, because I had violated it years ago in other applications I wrote for a previous employer.) I demonstrated how the action at a distance anti-pattern could happen to my colleagues. They were surprised, but saw the problem, and changed the code. I wanted to show them the problem because the users discovered it and raised all sorts of help tickets which unless you're wise to action at a distance anti-pattern, it can take months or longer before you discover that gotcha.
So, it was best I did demonstrated the problem to my colleagues. But as others have said here, not every potential problem I've seen and tell others about, is paid attention to. People have, occasionally, just proceeded to make the mistake. And what bothers me is I like to raise the level of competence at work. It's hard for me to see people make mistakes and it doesn't help me, if I must duplicate a flaw that I've identified, because we must follow some patterns put down by someone.
Which is better at work? If it's a blatant problem and you can demonstrate it to others, it is better to do so. But if it isn't? I don't know.
Rod
January 20, 2021 at 9:09 am
GeorgeCopeland wrote:Allowing failure: Steve and others use children learning as an analogy for this. That works very well because this is childish. When I am a member of your team, there is no need for failure, ever. The reason is because of this: I am a professional. I seek the best solution in all cases. I use professional techniques to solve problems and avoid failure. When I am on a team comprised of other professionals, I can pretty much guarantee that you will have an acceptable solution in all cases, sometimes a stellar solution, and your risk of failure is minimal. That's what you get with a team of professionals. Apparently, some people are not so fortunate, and for you, I truly feel sorry. For myself, I always seek the best available solution, and failure is not an option.
Edited to add that I am upsetting myself the more I think about this topic. Someone who is in charge of a production database, thinking this way? "Oops, sorry I brought down production, my bad. At least I learned something"??? Who on earth would think this is ok?
So you've NEVER had management overrule you as a DBA? Now, that must be nice.
That's happened to me several times despite us all being "professional" and all. In one case that was extremely dangerous, I dug in and wouldn't budge instead of giving them the "opportunity to fail". I was called a "non-professional" and not being a "team player" for that even though I didn't lose my cool and continued with all the professionalism in the world. Giving them the "opportunity to fail" on that one time would have been the wrong thing to do. I was overridden anyway and, you guessed it, it failed just as horribly as I said it would.
Sometimes, you do have to train other "professionals" by letting them fail using their method and then do it right using the correct method. Even supposed true professionals are incorrect and when you have a handful of them that all think the same is right and just one DBA that says they're wrong and won't even consider what the DBA is saying, you have to let them feel the sting of their poor decisions and to "train" them to be a bit more "professional".
What's sad is that it usually takes multiple such lessons to knock the chip of their shoulder.
+1
Amen brother 🙂
Far away is close at hand in the images of elsewhere.
Anon.
January 20, 2021 at 11:45 am
for what it's worth ...
- it took me 5 years to get our apps to a state that sysadmin was no more needed and no non-dba had sysadmin at OS level nor at SQLServer level. I spare you the discussion(s) details;
- this very issue is still a struggle with vendor applications (especially in a cloud environment)
- in one particular case, a "must have sysadmin" just added a sqlaccount to the sysadmin role and all applications failed. Our 24/7/363 production plant came to a halt for 4 hours ( they called me after 3,5 hours and it took me some time to actually figure out the account had been added to the sysadmin group ). This was expressed in $ and not only reported at plant level ! That got me some extra sponsorship.
- Failure is not an option? Well, it depends !
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
January 20, 2021 at 2:37 pm
In one position I held many years ago at a food wholesaler warehouse, the only IT Management position I was dumb enough to take, we were developing the first computer systems the company ever had. The company would load and ship 30-35 truck loads of dry, fresh, frozen foods and cleaning/industrial supplies daily. Before my arrival the company had hired a consulting company to get them started. During the design of the order processing package the consultants were adamant that we should enter orders into the system and immediately print a 4-part NCR invoice document and then the warehouse crew would pick and load the orders. Order entry was interactive but invoice printing was a batch process on continuous forms.
Since the clientele was largely schools, hospitals, nursing homes, and restaurants, it was very common to have item substitutions for those not available so they would have some product to use instead of nothing. This resulted in documents needing to be returned to the IT folks for order modification and re-printing in new batches. I argued that this would never work satisfactorily and we should print a single-part picking document which could be used to pick and load the orders, then make adjustments and print the 4-part invoices for the whole load in delivery sequence.
A VP and part-owner of the company sided with the consultants and over-ruled my suggestion. So we proceeded to do the development. Implementation of the system began with processing just small batches consisting of a single truckload of orders.
It was only about three days into the process when the VP pulled me aside and asked "How much trouble would it be to do the 1-part order picking document like you suggested?" Fortunately I had slipped into the flat-file designs the necessary data elements, so all I needed to do was add a status value, write the pick-list print process, and modify the invoice printing to select based on the new status.
Sometimes even if you can't get functionality approved at first, anticipating the needs can save you lots of work.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 20, 2021 at 2:51 pm
It is sometimes a pain but that's my usual tact... if you know something can/is going to go wrong, you need to be ready to pick up the pieces and rather seamlessly if possible. There's no glory in it... it's just good for the company that provides me and others a paycheck.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2021 at 2:54 pm
Jeff Moden wrote:What's sad is that it usually takes multiple such lessons to knock the chip of their shoulder.
Yep, that's because they still don't accept responsibility! I've been in similar situations where I warned and warned, but I was overridden and my prediction came true. Yet I was still held to blame because I didn't "provide enough information" on the situation! It made me feel like Ian Malcolm in Jurassic Park: "Boy, do I hate being right all the time!"
Aaron, I think I'm in that exact situation now. I'm warning and demonstrating as best I can, but it's falling on deaf ears. And like you, I normally get the blame for other's actions, which really angers me.
Kindest Regards, Rod Connect with me on LinkedIn.
January 20, 2021 at 3:54 pm
Allowing failure: Steve and others use children learning as an analogy for this. That works very well because this is childish. When I am a member of your team, there is no need for failure, ever. The reason is because of this: I am a professional. I seek the best solution in all cases. I use professional techniques to solve problems and avoid failure. When I am on a team comprised of other professionals, I can pretty much guarantee that you will have an acceptable solution in all cases, sometimes a stellar solution, and your risk of failure is minimal. That's what you get with a team of professionals. Apparently, some people are not so fortunate, and for you, I truly feel sorry. For myself, I always seek the best available solution, and failure is not an option.
Edited to add that I am upsetting myself the more I think about this topic. Someone who is in charge of a production database, thinking this way? "Oops, sorry I brought down production, my bad. At least I learned something"??? Who on earth would think this is ok?
I'd like to thank George for this sanity check.
The only failure I want to encounter is a test failure, because thats where failures belong, when you test your solutions.
That isn't to say that I haven't failed, and when I do I try to wring every last lesson I can out of it because there was something that was lacking in my process and I want to know what it was. But there's plenty of regret to be had over not foreseeing the failure.
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply