My 100 year old house has marks on the floor that look like it was worn from a door swinging. Very distinctive arc pattern. Like it was there for many years and was under frequent use.

The problem is that there's no door there, just a wall, which is also the edge of a dormer...so if there were a door there it would just open out onto a sloping roof.

Every time I register it I contemplate why it's there and wtf happened.

the fact that a system eventually becomes complex and flawed is not due to engineering failures - it is inherent in the nature of changing systems

it is not. It's just that there will be some point, where you need significant effort to keep the systems structure up to the new demands {1}. I find the debt-metaphor is quite apt [2]: In your scenario the debt accumulates until it's easier to start fresh. But you can also manage your debt and keep going indefinitily. But in contrast to financial debt, paying of technical debt is much less obvious. First of all it is pretty much impossible to put any kind of exact number on it. On the other hand, it's very hard to tell what you actually should do to pay it off. (tangent: This is why experienced engineers are worth so much: (among other things) they have seen how debt evolves over time, and may see the early signs).

[1] https://tidyfirst.substack.com/p/the-openclosedopen-principle

[2] https://blog.pragmaticengineer.com/tech-debt/

You’ll find light switches that don’t connect to anything

My house was built in the 1960s and had a switch like this. I was always curious what the switch was actually doing. One day, I was replacing all the light switches with smart switches, and discovered that the switch didn't even had a load connected to it! It was literally doing nothing.

I was perplexed by this until I saw some old photos of the house, from the early 2010s when the previous owners bought it. It turned out that there were originally ceiling lights in the room (George Nelson bubble lamps, fitting the mid-century modern design of the house) that were removed at some point, and the switch was left behind. I had an electrician install recessed lights in most rooms, and they found old wires for the old lights. It wasn't actually proper power cabling though... They had used speaker cables to power the lights!

You can and should design for change, within reason, because all successful programs will need to change in ways you cannot predict

You've yourself here. You can not predict how it wull change. Which means that whichever design for change you've made, may just as well completely miss the future utilization

Which doesn't mean that we shouldn't design for change at all... Just saying.

I've even experienced this in the 3D printing community, where I design a highly parametric model and put lots of effort into making all of the major dimensions and qualities parameterized and dynamically adjustable, with lots of bounds checking and value clamping, with all the parameters at the top of my scad file with comments explaining what each variable does.

And then someone comes along to remix my model, says I don't want to install openscad, and just scales the entire output stl to change the dimensions, squashing all the features of the model in the process (instead of having the size gracefully adjust with all the features moving around to account), and leaving anybody starting from their work with a hard to remix mesh with no parameters.

Or business decides all specs and design decisions that were made last quarter were actually garbage and yes we do want to be able to manually override every step of the carefully designed state machine. We'd like to be able to manually change all calculated sales data, but also the data needs to remain in a consistent state at all times. Oh and while you're there, we decided the commission calculations will use a different system from now on. We expect it to be online by the end of the week, thanks.

The 'document' part also seems to be insanely hit-or-miss from my amateur experience. Self-documenting design/code is... well, not. Auto-generated documentation is also usually just as bad IMO. Producing good documentation really is a skill in and of itself.

Also small personal opinion: If your abstraction layers or algorithms are based off a technical concept, you should probably attribute that concept and provide links to further research, to eliminate future ambiguity or in case your reader lacks that background. Future you will probably thank you and anyone like me who immediately gets lost in jargon soup will also be thankful.

Why do you have access to my project??

============ Top 5: =============== HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor: 97
AbstractAnnotationConfigDispatcherServletInitializer: 52
AbstractInterruptibleBatchPreparedStatementSetter: 49
AbstractInterceptorDrivenBeanDefinitionDecorator: 48
GenericInterfaceDrivenDependencyInjectionAspect: 47

============ Factories: ===============
DefaultListableBeanFactory$DependencyObjectFactory
ObjectFactoryCreatingFactoryBean
SimpleBeanFactoryAwareAspectInstanceFactory
SingletonBeanFactoryLocator$BeanFactoryGroup
ConnectionFactoryUtils$ResourceFactory
DefaultListableBeanFactory$DependencyProviderFactory
ObjectFactoryCreatingFactoryBean$TargetBeanObjectFactory
JndiObjectFactoryBean$JndiObjectProxyFactory
DefaultListableBeanFactory$SerializedBeanFactoryReference
AbstractEntityManagerFactoryBean$SerializedEntityManagerFactoryBeanReference
BeanFactoryAspectInstanceFactory
SingletonBeanFactoryLocator$CountingBeanFactoryReference
TransactionAwarePersistenceManagerFactoryProxy$PersistenceManagerFactoryInvocationHandler
AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler

https://gist.github.com/thom-nic/2c74ed4075569da0f80b

Okay, here we go. I'm going to spit out some bullshit and home someone corrects me if I'm wrong. I've looked for some explanations and this is what I've gotten.

Are you ready?

The Factory Pattern.

My understanding is that the purpose is a function to return any of several types of objects, but a specific type, not just an interface or whatever they might all inherit from.

I think most languages now have something like a "dynamic" keyword to solve this issue by allowing determination of the type only at runtime. (To be used with extreme caution.)

But most of the time I see the Factory pattern, it's used unnecessarily and can only return one specific type. Why they would use a Factory pattern here and not just a plain old constructor confounds me.

Am I off base?

So many developers don't seem to understand the point of modularization and add lots of abstraction just for abstraction's sake. It's hella frustrating to take over a project like that.

In my first month at my current employer, I added some temporary code with a TODO to fix it properly. That was 11 years ago in 2013, and the same TODO is still there today, and these days it'd be significantly harder to do it. 😂

This, to a point.

Other things help :

• Unit test to help catch regressions. If you are confident in your test catching a good portion of bugs from refactoring, at least you feel confident refactoring. Worst case, at least you ensured your code is testable. There is nothing worse than refactoring untestable code.
• Self-documenting code and when it fails to self-document, comments or refer to a wiki page.

That may lead to over-refactoring, leading to unmaintainable garbage code.

It’s an idea by the same guy who wrote the clean code book

Onion architecture. Ports and adapters are other names for it, I think.