Have you ever been in an old house? Not old, like, on the Historic Register, well-preserved, rich bastard “old house”. Just a house that has been around awhile. A place that has seen a lot of living.
You’ll find light switches that don’t connect to anything; artwork hiding holes in the walls; sometimes walls have been added or removed and the floors no longer match.
Any construction that gets used, must change as needs change. Be it a house or a city or a program, these evolutions of need inevitably introduce complexity and flaws that are large enough to annoy, but small enough to ignore. Over time those issues accumulate until they reach a crisis point. Houses get remodeled or torn down, cities build or remove highways, and programs get refactored or replaced.
You can and should design for change, within reason, because all successful programs will need to change in ways you cannot predict. But 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.
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.
There was most likely a closet or other crawl space storage area there. My house has closets like that but luckily full height entries to them so we can actually step in. I’ve seen other houses with 1/2 or 1/3 height doors leading to under-roof crawl spaces for storage.
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
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!
My hallway has a light like this that was removed from what I can only guess was water damage and the accompanying upstairs bathroom renovation.
It’s astounding to me that they would go through the trouble of renovating the bathroom, but not have reinstalled the light so that the hallway isn’t a dark safety hazard… 😒
I used to work summers as an apprentice electrician. The amount of crazy wiring I saw in old houses was (heh) shocking. Sometimes it was just that it was old. Real old houses sometimes just had bare wire wrapped in silk. … And a few decades later that silk was frayed and crumbling in the walls and needed replacing.
My current house was wired at a time when copper was more precious, so it was wired up and down through the house, with circuits arranged by proximity, not necessarily logic. When a certain circuit in my house blows the breaker, my TV, PC and one wall of the master bedroom all lose power. The TV and PC are not in the same room either.
in the 80s I helped gut a house that had aluminum wire with paper thin cloth wrapping. anywhere you touched it it would just disintegrate. blew my mind that the place hadn’t burned to the ground, especially all the dead rodents that had nested in the piles of fragmented cloth wrap.
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.
You can build your systems with as few assumptions as possible. The fewer assumptions you make, the less probable it is that any of your future assumptions will conflict with your previous assumptions. Your code will be built for change.
If your API call to some external system assumes the existence of a particular button in the UI, then your system isn’t built for change. Maybe you want to change this button? Then you need to go through all places in the code that relies on this particular button to see if it doesn’t conflict with any of their assumptions.
As long as loose coupling, and separation of concerns are well tinkered into your application you minimise risks of breaking everything on a restructuring.
If you have for example shared state leaking everywhere into the program, your most probably doomed on the slitest changes.
I am not saying you’re wrong, but there are ways to mitigate the risks even without knowing what will happen in the future.
Just saying.
… Saying what, exactly?
I said that we should
- design for change
- “within reason”
- because we can’t know what exact changes are needed.
And you argued… The same thing? Just in the reverse order?
Seems like he’s worried you’ll Java everything up, which can be valid.
I think a good, easy example is whether your application should allow a selection of databases or be tied to one database.
You can make arguments for either, often (but not always) regardless of your use case.
You can design it to be changeable at all, though.
In the simplest case that’s just proper abstractions. You can’t change details in the rest controller, if the persistence layer absolutely needs to call methods from the rest controller for no reason.
Finding the right balance between YOLO and YAGNI is almost impossible to get right. But you can at least try not to land on the extremes.
This is so true.
Even if you do design clean modular code and document it, you’re getting a question a year from now about how it works, or someone just duct tapes on top of it.
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 closest I got to this kind of job., is the closest I got to running away. I’m much happier elsewhere now.
Removed by mod
At least they can observe the patterns….
Bless your heart.
In my experience, this often doesn’t happen. So many developers are either inexperienced or cowboys, and there’s nothing inherently wrong with either. But at places where projects are small and numerous, teams often end up with nothing but a combination of the two.
As one of our office’s engineering “fixers”, I’ve taken over maintenance of several such projects. They usually have shattered remnants of code taken from other projects, open source libraries, internal libraries, stack overflow, and so on. Whole source files copied into the project, modified in ways that introduce impressive new failure cases while failing to add new functionality, and used in ways that completely ignore the features natively implemented in that code while those same features are bodged in as barely-working piles of if statements, balanced on a knife’s edge to avoid triggering the failure modes added by the project’s modifications of the copied code. I’m usually able to purge 20-30k lines of code from such projects in the first month, simultaneously closing multiple outstanding issues the PM had been led to believe were intractable.
That probably sounds like arrogance and/or shitting on everybody else’s work but it’s just reality at many workplaces due to a pace driven by unreasonable expectations from management. I just happen to be the person here that ends up sifting through the wreckage when a project reaches the inevitable osteoporosis phase, because of a natural disposition for reverse engineering. It would be great to escape for this and other reasons, as far as I can tell, most places aren’t that different.
This can work for junior devs who aren’t stuck in their ways. Unfortunately there are too many “senior” devs who are happy making crap. It’s hard to fight them constantly to do things properly (e.g. write actual commit messages rather than just “Fix #836”) so using tools like linters where possible is definitely a big improvement.
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.
public class AbstractBeanVisitorStrategyFactoryBuilderIteratorAdapterProviderObserverGeneratorDecorator { // boilerplate goes here }Why do you have access to my project??
… And can you fix it?
============ 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$ManagedEntityManagerFactoryInvocationHandlerOkay, 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?
Factory pattern can return a mock type for testing or a production type, as needed, which makes it possible to unit test the code that uses the produced object.
This quick guide explains it well. Then it improves on it by explaining dependency injection.
Yeah most uses of the factory pattern are unnecessary and it’s mild code smell IMO. If your factory only returns one type you should definitely just use that type’s constructor.
You avoided writing spaghetti code.
Congratulations! Now maintain this piece of shit lasagna that takes place over multiple layers of abstraction and repositories.
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.
We have those parts of code someone wrote years ago that is heavily abstracted for no reason at all other than that the developer thought it might be good. It’s just endless clicking on methods just to find no code at all and then you have to deep dive to figure out where stuff is actually computed.
Make it just one simple method call? Nah, it should be divided into 10 different abstract classes because whatever reason.
It’s also the most buggy part of the code because no one currently in the team dares to touch it.
And it can be in any language, but typically comes from someone who started with Java.
It happens in English too — just think about how many people never learned how to properly use paragraphs, quotations, hyphens, parentheses and footnotes.
It’s just the human condition to attempt to communicate in known blobs without thinking about what you’re actually trying to communicate and how it can be most effectively done with the tools at hand.
We’re all single hammer hominids at heart.
Why maintain what’s perfect?
I have a website that I haven’t touched in 14 years and it still makes money. Build it right the first time.
Never touched it? A website? What about updating frameworks for security issues?
Fuck all that noise.
There is nothing more permanent than a temporary solution that works
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. 😂
If it gets comitted to master, TODO means never do.
In my experience it doesn’t matter. You have to regularly refactor your code to keep up with new features. The more often you can make time to do it the easier it is.
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.
The only thing that has the chance to prevent unmaintainable garbage code is a plethora of linting rules.
That may lead to over-refactoring, leading to unmaintainable garbage code.
yeah thats why I said it only has the chance, not that it leads to good code
I feel this personally today. I just looked at some code in a module where it started out with nice, short functions with good names. I looked back at it today, and it now has a 180 line mega function full of nested conditionals and I don’t know how this happened.
Can’t relate
Huh? Hexagonal Architecture?
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.
