February 24, 2020 at 7:19 pm
I am sort of famous for being the "standards Uber Alles" guy in the SQL community. I'm very proud of it and it served me very well. I've written 10 books on SQL which adhere as strictly as I could to those standards, collected the royalties on those books and gotten free drinks at bars.
However, I'm the first guy to admit that not all standards cover all things. A lot of basic definitions are not standardized. For example, what is the median? If I have the set {1,2,2,3,3,3}, how to find the median? One way says that it has to be in the set, so the only thing you can consider is {2,3}, but we don't allow a set result for a median, so pick one. The other way is to do an average so you use ((2+3)/2.) = 2.5 instead. However, I prefer to do a weighted median because I feel it's more representative of a central tendency to give us SUM(2,2,3,3,3)/5 = 13/5 = 2.6 instead.
So which one should be a standard? For those of you are old enough to remember when Pascal was the "language du jour", they had a whole debate on how to define modular arithmetic. The problem is that when it goes to negative numbers in the two parameters, it's not well defined.
Now going back to my defense standards. The one thing that they do at least is the terms which we use to describe things are standardized. We know that an expression is not the same as a function, that a variable is not the same as a constant, and so forth. We might disagree on how they interact or work in a language (I'm trying to get an article on this assignment statement and all the variations that it has, even though it looks like it's one of the most fundamental in any language).
Damn, I guess this programming thing is trickier than it looked. 🙁
Please post DDL and follow ANSI/ISO standards when asking for help.
February 24, 2020 at 7:34 pm
Awesome points. Thanks for sharing Joe.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 24, 2024 at 9:05 am
One of the practises that contribute to agile development (not Agile TM) is constant refactoring of team processes, code..etc to design out failure points.
I do a lot of refactoring work on legacy code bases for data pipelines. This is largely fixing the U-Boat bog and trying to remain civil with the person who last used it. In most cases U-Boat Bog systems are poorly documented and the designers are long gone.
Beyond the code itself I capture how I think a system works in Confluence and/or GitHub Markdown files. I then go through this with anyone who has been involved in the system that is still in the organisation. This is to verify my understanding so I can correct and/or elaborate where necessary. Even if it is just diagrams and bullet points what I have got is an agreed and shared understanding captured in a shared and commonly accessed location.
I capture the processes team members have to do to make the system work. As an outsider I find that some of the questions I ask reveal gaps, duplications or even zombie processes. What I mean by a zombie process is one that you do, you don't know why and when you dig deeper you find it is to feed a system that is no-longer there.
At this point you find things that can simply cease to be.
I can refactor code to break it into simpler smaller, testable pieces. In some cases the steps to take would be obvious without all the analysis I did earlier. In others I'm looking at WTF code and really need to understand its intent. Sometimes I just have to accept that the code is what it is. Whoever wrote it produced a stream of unconciousness that defies analysis.
If successful I will have a (largely) documented system that is a damn sight more maintainable and with mechanical tests that prove that the captured understanding of the system is what is happening.
The tricky bit is to make sure that when I leave the client's team keep up the practises of testing, documenting and refactoring. I was called in to help with a system I had dealt with previously to find that the team had disabled several of the tests. When I asked why they said that the tests were disabled because they broke the build pipeline. It turns out those failing tests were failing for a very good reason and that in disabling them they had allowed a whole series of bugs to re-infest their system. They'd done the equivalent of pre-installing dry-rot in their basement.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply