Hacker News Reader

Comment by efxhoy | Hacker News Reader

> Security and reliability are more likely to go wrong in the seams between components. That means literal integrations, but it also means organization seams.

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.

View on HN

I have always worked with the concept of what I call “trouble nodes.”

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).

Moral of the story: any public interfaces should be peer reviewed by various stakeholders if possible :)

If no one is available, stepping away from ones own work and reviewing it with a fresh mind can have a similar affect

Absolutely. In this case, I was the only person working on it, and reviewing the code long after the fact is what did it.

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.

It's a quote from Will Durant, The Story of Philosophy: The Lives and Opinions of the World's Greatest Philosophers (1926)

[0] https://en.wikiquote.org/wiki/Aristotle#Misattributed

I did not know who did that. Thanks! I knew it was misattributed, but was really just a "cliff's notes" of a speech ARIS-stot-ly made.

I have never really cared who said it. It's a great quote.

This is just an instance of Conway's Law:

    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. Conway

> whose structure is a copy of the organization's communication structure

Yes, 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.

Reply on news.ycombinator.com