michaelfeathers

> Those simple systems have (or rather will soon) perish, while the more complex system that emerged from them survives.

I've wondered whether that is why we find ourselves surrounded by complex software. Legacy code is code that provides more value than the cost of its replacement. Bad code endures when that cost goes up.

> But I strive to make everything as simple as possible, remove unnecessary components, etc. I still cant understand contexts where complex is better than simple

If there are some, I'm not really aware of them. Systems we create should be human-manageable. The thing I find interesting is that, even with decades of attempts at better practice, we still end up with complexity that makes our work difficult.

I think it's because we don't understand systems as well as we should. This article (http://www.miamiherald.com/news/business/article207841309.ht...) is a decent intro to what modeling shows about engagement and polarization. The paper it refers to (https://arxiv.org/pdf/1712.06009.pdf) goes way deeper.

I think the architecture of social media spaces affects their culture. I wrote up some observations here:

'Twitter, Reddit, and Conway's Law'

https://michaelfeathers.silvrback.com/social-media-architect...

Obligatory.

https://news.ycombinator.com/item?id=11189688

I'd like to hear a criticism of this.

I haven't read the full article but my immediate criticism is that systems need the spikes and peaks that synchrony provides. If they didn't exist we'd have to simulate them to keep systems from being overly fragile. Yes, there's a power spike when everyone goes to the fridge during a commercial, but the need to handle that variation makes systems more robust.

My favorite is this twitter account of titles for imaginary articles constructed from titles submitted to Hacker News.

https://twitter.com/HNTitles

Isn't it strange that the concorde moment for aviation was the retirement of the SR-71?

This was a Concorde moment for software: the move away from 'The Structure and Interpretation of Computer Programs' at MIT.

https://news.ycombinator.com/item?id=14167453

It would be interesting to have a word for devices that is sort of like 'organic' for food.

It would indicate that the device is self-contained and has no connectivity.

What's interesting is that we've known this in the industry for decades but people seem to forget it at the user interface.

https://scholar.harvard.edu/waldo/publications/note-distribu...

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

At the same time that this is showing on HN there is an article about an ESPN Analyst walking away after being upset at trauma on a football field [1]. The comments are very interesting in that they point out that football helmets may actually exacerbate injury because they their protection leads to players feeling protected enough to risk harder hits.

I don't think we have that same effect in software but I think there is an related one: when you don't have the protection of a static type system, you may become more careful.

[1] https://news.ycombinator.com/item?id=15141495

I think Postel's Law is best understood as a growth strategy. Its tolerance facilitates easy composition but at the expense of some protocol decay. What the author does not acknowledge is that less tolerant designs schemes are often so exacting that they discourage participation.

I wonder whether another way of approaching the problem would be to have to two commenting sections for a site. One would be moderated algorithmically and the other wouldn't. People could choose according to their tolerance.

Coverage isn't the goal. The goal is understanding.

Write a test if you don't feel confident that a piece of code does what you think it does. If you're not sure what it does now, there's little chance that you or anyone else will in the future, so write a test to understand it and to make that understanding explicit.

Use curiosity as a driver.

There's a myth around scaling [1]. Actually, it's almost like a cognitive bias. We assume that we can usually use the same structure as we scale. Because of this bias, we haven't thought enough about how to make bigger structural transitions normal.

The GP points at the transition between the quick & dirty architecture and the architecture that handles Google-scale, but those aren't the only good stable points for a system.

[1] https://michaelfeathers.silvrback.com/the-myth-of-scaling

I look at property-based testing the same way I look at Design by Contract. It can be used to find errors in existing systems, but it's also valuable when you are designing.

Just asking yourself what laws a function should adhere to as you are considering writing it function puts you in a different frame of mind and you can end up with simpler software.

Nick, I think that the primary win is referential transparency. APL idioms raise the level on that base. The tradeoff, though, is the same as we have for functional but further along the road: if you develop a codebase that doesn't use common idioms it's harder to hire people to work in it.

I think array languages, or at least their operation set and idioms, will move into the mainstream in the same way that functional is, but it will take time. Sustainability for your business would be more an issue of hiring and retaining talent.

Reach out if you want to talk about this more: @mfeathers

> Not sure where to go from here.

For the past few years I've been telling people about the APL family of languages. The clincher for me was seeing the video of an APL version of Conway's Life mentioned in the submission. The impressive part wasn't its brevity, it was how they approached the problem.

In APL you have a 'rotate' operator that shifts data in a particular direction. If you have a vector and you rotate it once, every element moves to the next position and the last element then becomes the first.

The nice thing about APL is that most operations work on data regardless of its dimensionality. So, to do Conway's Life, you take your 2D matrix of cells and produce rotations of it in eight directions (N,NE,E,SE,S,SW,W,NW). You then take those rotated versions of the matrix along with the original and conceptually stack them. Then, for each grid point, you sum downward, producing a new matrix that contains the neighborhood count of the original matrix. From that you can create the next Life generation.

This sort of problem doesn't come up everyday, but the thing that I think is profound is that the existence of these operations allows us to think about problems in different, possibly simpler ways. They are untapped potential and they could be as well known as map and fold.

APL and its derived languages are hard to approach but there isn't much that keeps us from importing the data structures and operations in more approachable languages.

I agree. My argument isn't against exploratory testing but rather against the idea that developers shouldn't also be cultivating that way of seeing systems.

As a developer you should be thinking through your edge cases more than a tester would. The alternative is needing more testing.

Ideal situation: tester doesn't find anything.

For higher level tests that's fine. At the unit level it's problematic. It delays feedback.

I don't think this is a good way of framing things. In fact int can be counter-productive.

Automated testing is the process of writing code to understand your code. We already have to understand our code. Testing is being deliberate about that understanding and writing it down. The same design/testing thoughts that lead us to edge cases can lead us their elimination without testing at all. It's an integrated process, not something separate.

Stance detection is nice but does anyone know of any effort to evaluate text based on Russell Conjugation?

https://www.edge.org/response-detail/27181

> I've always thought that AWK's most important feature is its self limiting nature

I agree. This idea doesn't receive enough attention. If you pick your constraints you can make a particular envelope of uses easy and ones you don't care about hard.

AWK's choice to be a per line processor, with optional sections for processing before all lines and after all lines is self-limiting but it defines a useful envelope of use.

Products are more often sidelined by technical debt than they are killed by it.

A typical scenario is:

1) Product becomes too hard to change but has many existing customers

2) Product is off-shored, and costs of maintenance are under-estimated because it depends on a vast technical ecosystem

3) Alternative products are developed to replace revenue of the original

The original product can live in this moribund state for decades.

The cost of not having employee turnover can be substantial also.

It would've been interesting to see this addressed. In some particularly bad cases, organizations atrophy and lose the ability to respond well.

It's staggering to think about how many layers there are now.

It needs an xkcd graphic.