These are basically graph vertexes; places where two (or more) things interface.
Every “node” is a potential quality hit. A lot of my refactoring involves removing these, using techniques like deriving base classes, protocol defaults, or recursion/reuse.
As an example, a couple of days ago, I refactored an SDK I’m refining. It has an auth capability that uses an API key (bearer token), in a Basic Auth scheme. It does this via a common method that generates a URL request, and adds a header.
But servers that run fastCGI don’t like auth headers, so I was forced to add the option for query arguments to deliver the tokens.
So I basically “kludged” it, and added the arguments to the URI in all the places the requests were being built. An ugly, clumsy, lash-up (I was in a hurry).
This was months ago. I forgot I did that.
As I was reviewing my code a few days ago, I saw this, and was quite embarrassed.
Not only was it sloppy, but it was dangerous. This was auth stuff. The worst kind of place to have rotten quality code.
The refactoring was a pretty intense effort, and removed dozens of “trouble nodes.” It was fundamental stuff, and required a lot of testing. If I had taken the time to do it right, the first time, it would not have been necessary. I’m glad I found it before it became a problem.
And I slept like a baby, that night (waking up frequently, cying).
If no one is available, stepping away from ones own work and reviewing it with a fresh mind can have a similar affect
But doing it right the first time would have been better. That comes from establishing habit.
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." -Some guy that habitually wore a bedsheet.I have never really cared who said it. It's a great quote.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. ConwayYes, and if different parts of an organization don't communicate, then the systems they develop / procure will often be stovepiped.
I have seen this in a UK civil service acquisition organisation, that even lacked consistent shared engineering guidance for the different teams. They did at least approximately follow the same acquisition guidance so there were commonalities with how they approached industry and managed the bidding process.
Elon said the best part is no part. Parts between systems, interfaces/valves/pumps/APIs/whatever, are often modelled not after what makes the most sense for the final system or product but often follows the organisational structure of the people making the system. So it makes sense that these interface parts are often what creates problems.