michaelfeathers

“The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.” - Alan J. Perlis

This is a lesson in incentives. The reason any of these procedures are not eradicated is that no one wants to be the person who does that and then have the next terrorist attack use a technique that would've been caught.

It's interesting to note that we have had this in software development too. Prior to CI/CD, organizations that had QA departments (responsible for testing) had a lot of incentive to hold up releases because they were blamed if a bug escaped into production. When developers test, they are responsible for both delivery and defects so there is balance.

It's hard to see how something like this could be applied for security. Making the TSA responsible for wait times seems like a good idea but there's always going to be an asymmetry when life hangs in the balance.

After the IRA bombings, train platforms didn't have trash bins for decades. Eventually some showed up with transparent bags so that the contents could be seen. The half-life of fear is long.

> It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. This is the mentality that I see everywhere in the software industry today.

I think the moniker is perfect because that is exactly what piecemeal growth is in nature. That's why code seems to have a biological feel. The rough bit, for we humans, is that code tends toward piecemeal growth because of the economics of change. It is easier to add to something that exists than to make something new, so entities (functions, classes, services) tend to grow in size. We have to step in, as gardeners in a way, to guide structure.

I don't know that it was intended by the original people behind micro-services (Fred George comes to mind), but micro-services are a good example of aligning with natural tendency rather than attempting to impose a design and continually falling short. Part of the intent was that you just rewrite a micro-service when it becomes unmaintainable. That's a direct structural correspondence to apoptosis in biology. Cells live for a while, then they are replaced.

Author of the post here. There's a lot that one can argue about with my choices. A thing that might help is that I selected the papers that led me to see things in a different way. One could argue that _Reflections on Trusting Trust_ isn't very important wrt modern security concerns but, to me, the most important thing is noticing that trouble can happen upstream in any process, and often it can be hidden. The abstraction of source code is so total for many people that they forget about all of the layers underneath. Things that don't look possible are often possible.

> The fundamental tool of cloud scaling is coordination avoidance.

Having many systems rather than one is the ultimate scaling hack.

Assuming GRON is short for "grep json", it seems like the tool could have a better name. It looks like it is useful beyond just the grepping case.

Separate files make sense if you consider typing a form of coupling. I pitched the idea for something like RBS in Ruby back in 2006.

The reasoning is here: https://www.artima.com/forums/flat.jsp?forum=106&thread=1559...

Another fun one.. Selenium was given its name because that element is used to treat mercury poisoning. (Mercury was a testing tool of that time).

Configuration files are globals and they are lousy for the same reason globals are lousy when they are in a program.

If you use a programming language, you had least have a way to scope.

Correct me if I'm wrong but can't all of the cases covered by conditions be handled in an OO language by providing an object that one can register conditions with and call signals upon? I'm trying to imagine library support for languages that don't support conditions directly.

This is a way you can approach it.

https://michaelfeathers.silvrback.com/characterization-testi...

When an area of engineering is new we make products better than the market will eventually pay for. Over time, we learn how to make them just good enough to reach an equilibrium in a market. This is an idea that is explored in _The World Without Us_ by Alan Wiesman. The Roman Colosseum still stands, but buildings today don't need to be that durable. It would cost significantly more to make them that way, so we don't. The same could be said about supersonic travel. We could do it again, but enough of us are happy to not pay the premium, so that product has disappeared.

It looks like a great base for a refactoring exercise.

Great article. It should add Technical Debt as a sign.

It's a decent goal, though. For all else, there's Erlang.

Good article but it is tangential to a basic design issue.

Error handling should be done at the edges of systems rather than in the center. If you do that, it doesn't matter whether you use exceptions or error monads, you have a pure core that doesn't need to deal with error handling and a very slim area to catch errors. The mechanism you use for error handling, at that point, doesn't matter.

The problems of error handling often come from having it spread across the system and mixed with the logical flow.

The easiest way to escape AI hype-thinking is to replace "AI" with "computer program" in your mind whenever you see "AI" in an article.

The thing I love about JetBrains is their ethic.

- Started by making refactoring plugins for IDEs. Became irritated by those IDEs. Wrote their own IDE.

- Supported various programming languages. Became irritated by those languages. Made their own programming language.

I thought the implication was clear. When everything becomes "one thing" there's no need to communicate using spectrum.

I dug into this topic in this talk in 2017. 'Moving Past the Scaling Myth' The core observation is that minimal spanning trees have less edge cost than fully connected graph - if you pay for the difference you can have decentralization.

Centralization is a cost reduction maneuver.

https://youtu.be/MgbmGQVa4wc?t=700

Last year, I was at a conference giving a talk about error handling and Joe Armstrong was in the audience. I went through a bunch of strategies for mitigation and handling of errors and Joe yelled from the back "just let it crash! just let it crash!" I had to reply, "but we're not all using Erlang yet."

I'd go further.

Use of software to make a plane airworthy when it isn't natively airworthy is a problem. Civilian aircraft should have a different standard than fighter aircraft: one that allows graceful degradation under failure.

I like 'collection pipeline' code written in this style regardless of language. If we took away the pipe symbols (or the dots) and just used indentation we'd have something that looked like asm but with flow between steps rather than common global state.

I periodically think it would be a good idea to organize a language around.

In ecology, what the author cites as a problem would be seen as a sign of a healthy robust ecosystem.

Yes, he was wonderful.

Here's where I think you and others are missing something. Orange juice is in the hypothetical that they are discussing. There's nothing that says you have to make up a request. It can be a legitimate request, it just wasn't in the hypothetical.

The key thing is whether the response is "that's impossible" or "you can have that for this price." In the anecdote, the businessman told Gerald that he'd already passed the test.

What lie?

I'm stunned that no one is mentioning that this story came from Gerald Weinberg ( https://en.wikipedia.org/wiki/Gerald_Weinberg ) - who passed away a few days ago. He was the OS dev manager for Project Mercury. He wrote 40 books on topics in software development, quality, organizational change and team psychology. He was very influential.

It's even more stunning that the author of the post didn't mention him either.

I may get a chance to write up more over the next week. If I do, it will be on the same blog.

I'm not sure whether it is finalized yet but the conference may go biennial, skipping next year. That's just what I've heard indirectly. If you're interested, definitely watch for it.