October 24, 2022 at 12:00 am
Comments posted to this topic are about the item Good Enough
October 24, 2022 at 1:06 pm
Excellent article, as always. I have found myself facing similar dilemmas many times in my 30+ years serving businesses in computing and processes. I often think of the trade-off between the grandiose excellence, and the boots on the ground real need, as a study in pre-emptive multi-tasking (think Windows NT and what came later). At first you just do the manual tasks, and then you think, hey, I can automate this, and then you think, "this is how it really could be". The real Art of being of service is knowing the right time to take something to the next level, and when that task is complete (for now).
I absolutely love it when the challenge at hand requires a graceful and carefully engineered solution, but I also find it gratify to simply craft something that works. In my mind I still see the perfect, but my heart is gladdened to see peoples lives improved by the small thing I did.
October 24, 2022 at 2:11 pm
I once read about a term in economics that was coined for this kind of decision making: satisficing.
Satisficing is a decision-making process in which an individual makes a choice that is satisfactory rather than optimal.2 It would require a great deal of effort – and may not even be possible – to gather all the necessary information in order to make the best decision, and satisficing thus represents the kinds of decisions we are actually capable of making. Satisficing is all about making ‘good enough’ decisions instead of perfect ones.
https://thedecisionlab.com/reference-guide/psychology/satisficing
Over the years of learning the hard way in database work, I grew to get a little better at good satisficing (perhaps manually importing some data short-term until it is automated) versus bad satisficing (granting too many permissions to "get it done" or poorly normalizing tables, etc.).
HTH.
-- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
October 24, 2022 at 2:13 pm
Good article, Steve. Where I work this form of good enough has often resulted code that was only good enough back when it was written 10, 15 or even 20 years ago. As a result, these code instances have contributed to a very large body of technical debt. That weighs us down so much that it's hard to do anything new, as we're often feeding and tending to old apps that might have been good enough when they were written way back when, but rather than making significant improvements, only Band-Aid fixes are all that's done.
For example, recently there's a lot of interest in getting several of our software systems into the cloud. I like this idea, because it can result in working on technology that is in high demand, which is good for my career. However, I'm very concerned because in my opinion we haven't any software systems that is cloud ready. Our approach is going to be the typical lift-and-shift approach. It is the path of least resistance, but I suspect it will only prove to be more expensive in the end, due to the fact that our systems aren't modernized. For those systems which produce something for anther system to consume, it was done the way people did it when they wrote it back in the 1990's or earlier. i.e.: they'll write results to either a CSV or XML file somewhere, to be consumed by the next software solution in the pipeline. I'm concerned that after a year or so, perhaps sooner, management or someone in the fiscal office, will wonder why our cloud bill is so high.
Kindest Regards, Rod Connect with me on LinkedIn.
October 24, 2022 at 2:42 pm
From the Article:
I find that many of us that work in technology want a solution to be great. Often perfect. Computers are so good at following instructions that we expect them to work as we intend all the time. We aim for being perfect in our code and we find “good enough” to be a low bar.
That's not it for me. Sure, I'd love everything to be "perfect", especially when I'm doing code reviews for other. But, consider this... what does "good enough" actually mean? If it means that it's not actually doing what is required, how can anyone say that it's "good enough"?
The real issues usually have nothing to do with functionality, though, because most people understand the above. The real issues come in the form of a "Server Death by a Thousand Cuts". This is when people "just want to get it done" and, especially when there's a perception of a low row count, will do things like creating an incremental CTE to do things like create a date range or write 30 table joins or write stuff in a single SELECT without using Divide'n'Conquer methods. It's seem like "good enough" means "it produced a correct answer"... for 10 rows of input.
One of the companies I do work for says that they want to move things to the "cloud" because SQL Server takes too long to run some monster processes on millions of rows per import. The reasoning is that they'll be able to "throw hardware at the problem". A lot of the code takes hours to run and consumes 10 of TeraBytes of I/O. I expect that "throwing hardware at the problem" is going to be really expensive in the cloud.
The problem with ALL of the code is there are no places where you can make a tweak or two, rewrite a couple of SELECTs, or add indexes to fix the problem because it was all written to be "good enough" and there's a shedload of code. It's the epitome of what "Server Death by a Thousand Cuts" means. Even stupid little things like removing control characters from a column of imported data had been done all wrong and the code is VERY slow. There's no understanding of things like the fact that a CTE must re-run in it's entirety for each time you call it. There's no understanding of things like "Divide'n'Conquer"... why would you ever need to do such a thing anyway? It ran fast on 10 rows, right?
I thing the biggest issue, whether it's front-end code, reporting code, ETL, ELT, whatever is that the people writing the SQL only have a very basic knowledge of the SQL Language and databases in general. Why? Well, "databases are just a place to store data", right? 🙁
I did a check for one day for the company I'm talking about. There are 15 stored procedures that chewed up between 10 and 47 TERABYTES! There are another 71 procs that take between 1 and 10 TERABYTES! There are another 600 that consume between 100GB and 1TB! And that doesn't include the front-end stuff!
On the front-end, I've got a half dozen "single lookup" bits of code that have already that are between 1 and 8 TERABYTES of logical I/O as a total of the runs and we're only 2 hours into the normal business day. I have dozens of others that that exceed that have already exceeded the 100GB range. But they run "good enough", right? And, yet, they want to move to the cloud because you can easily strap on more CPUs, right? And, remember... you can store all the data you want for damned near free. What do they charge you for? Reads.
And it's not like they have big databases. The database that that they have is only 1.6TB and more than a half of it is in the form of history/audit tables.
The real issue is NOT a search for the perfection that you claim a lot of us want. What we really want is for people to study their trade well enough to understand that just knowing how to join multiple tables isn't "good enough". Just like any language, people need to study SQL and learn how to form good habits and how to avoid the "Server Death by a thousand cuts".
But... they won't. They'll just keep asking questions on forums or finding "answers" in blog articles written by "experts" that aren't much better than they are when it comes to even simple knowledge to achieve their perception of "good enough". Or, they'll skip all that and learn to use Python... every one knows that's "good for performance", right (If you couldn't feel the jolt of extreme sarcasm there, you've gone totally numb. They make the same mistakes in all languages)? Or they'll spend months trying to learn how to use something like "RedShift" because it's a great buzzword... only to find out that it doesn't do the job they need it to.
And all of it is because most of the people working on the SQL think that just getting the correct answer is "good enough". Yeah... let's put more methanol in our gas tank, shall we (that will void your warranty, BTW).
--Jeff Moden
Change is inevitable... Change for the better is not.
October 24, 2022 at 3:08 pm
One of my wife's web site consultants ussed to say: "Done right is good. Done is better". I don't think that is all ways the case, but it made her point.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
October 24, 2022 at 5:25 pm
The fly in the ointment is... what does "done" actually mean and when will it come back to bite you? "Done" is just another name for "Good Enough" and I've found that "Good Enough" usually isn't. One of the many definitions of "Good Enough" turns out to be someone just wanting to get something off their plate.
Of course, the way some managers drive their Developers, I can understand that issue but it turns out to be a "Catch 22"... the faster you turn out crap code, the more rework will come back and rework tends to take about 8 times longer than the initial development. It's also a part of the reason why there's supposedly not enough time to do right the first time.
They made the realization at one of the companies I worked for in the past. They spent just a little more time to do it right the first time. After about a year, their throughput had drastically increased because they were no long spending huge amounts of time on rework and that gave them even more time to do it right which killed more rework... wash, rinse, repeat.
From what I see from a lot of people, "Done" means they did the absolute minimum to return some of the correct answers and spend more time justifying the rest of it than they would completing it.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 24, 2022 at 6:44 pm
Jeff, at the risk of introducing more adages into this thread, your most recent reply reminds me of another I heard once: "If you don't have time to do it right, when will you find the time to do it over?"
At the same time, many people who want to do it right are often under pressure from others (bosses, investors, etc.) so are rarely given the time that they need. Definitely a longstanding dilemma in tech careers in particular.
-- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
October 24, 2022 at 7:10 pm
@webrunner...
And so there's yet another adage we can add...
"If you want something real bad... that's usually the way you'll get it". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
October 24, 2022 at 7:12 pm
Another adage: The first idea is not usually the best one. The problem is really bad in large installations with ranks of project managers, QC people with their management, and support staff with their management to contend with.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
October 24, 2022 at 7:21 pm
At the risk of 'negative feedback' I'll add that after a couple years, I still get the error rejecting my first post effort with "Did you really mean to do that" making me send the same thing again. And now it even tells me that I've already sent that. So I check, and that is true. There's my comment. It happens both on my Android phone and my Windows laptop. But it's good enough.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
October 24, 2022 at 7:48 pm
At a certain point it becomes a question of effort vs reward. How many things is it worth trying to parameterize that will almost certainly never be used? Does it need some elaborate pre run cleaning routine and error trapping or can the job just die if there's a problem?
October 24, 2022 at 7:53 pm
Had a laugh that was 'good enough' last week. I bought an item at a local business, and got home to find an email receipt issued by an account called 'POS6'. Yeah, I know, point-of-sale, but really?
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
October 24, 2022 at 8:01 pm
At a certain point it becomes a question of effort vs reward. How many things is it worth trying to parameterize that will almost certainly never be used? Does it need some elaborate pre run cleaning routine and error trapping or can the job just die if there's a problem?
Being the old-timer that I am, it's never OK to just let the job die. We were raised believing failure meant you weren't smart enough or were not trying hard enough.
But if you are posting deposits to my account, run it as many times as you need.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
October 24, 2022 at 8:25 pm
Excellent article, ...
I absolutely love it when the challenge at hand requires a graceful and carefully engineered solution, but I also find it gratify to simply craft something that works. In my mind I still see the perfect, but my heart is gladdened to see peoples lives improved by the small thing I did.
Thanks, and a great sentiment there. The value to the customer is king.
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply