Hacker News Reader

Comment by keyle | Hacker News Reader

It's always fun and games, until you have a team of 5+ and are always short on time.

I'm yet to see a project that was clean from inception to retirement. They seem to go through waves. Starts clean, get messy, a big clean up happens, happy days, back to messy, then comes the permanent architecture which is reasonable, and it gets slowly messier through maintenance updates and developers become too scared to wake the dragons...

Most of the devs move onto the next green project and ride the refactoring choochoo once again, having learnt almost nothing in the process and chasing the newest shiny abbreviations that ensures that this time, it will be different!

These types of graphics and biblical design akin to "this is the way" always put a smile on my face.

View on HN

Systems do indeed go through waves of clean and messy states, and teams may jump from green project to green project.

The problem often starts with viewing software as just a project with a clear beginning and end. In reality, long-living systems are more like products or even living things—they need constant care, iteration, and a guiding hand to keep them from spiraling into chaos.

Architecture is about making those strategic decisions that help systems adapt and stay solid, even as people come and go or requirements change. Not every part of a complex system needs the same approach—some areas can be built quickly, while others need a solid foundation to avoid trouble down the road.

The goal isn’t to follow every buzzword or pretend there's one universal solution. It’s about having the right set of patterns and tools to make smart trade-offs and apply the right solutions for each part. To me, the real value of architectural patterns is that they give us common vocabulary to discuss different approaches even if we end up rejecting them. Systems need to be kept maintainable and resilient, even as they inevitably go through cycles of change.

Well but that is the normal course even if the project has all the time in the world, because you only know what you know at the time of conception and implementation and software always ends up describing complex systems (in the sense that adverse behaviors are emergent) and you can only know some stuff in restrospective.

The question is always "is the team aware of the issues?" and "is management aware of the business risk technical debt poses?" and maybe "do they care?".

Software sometimes is just a means to making money and if that is what the company wants, it will throw suffering at it because clean architecture, DDD etc... although nice to have are all tangential to the ultimate purpose of it.

If you read these articles looking for generalisms, ground truths or recipes, you are setting yourself to failure. Context is always crucial to implementation.

> It's always fun and games, until you have a team of 5+ and are always short on time.

I save time doing this. I build my application in terms of simple, testable operations on pojos. Storage is hashmaps. When I found I've built it wrong, I redo my pojos and functions. When I want to move beyond the hashmap-storage phase, I don't throw them out, I interface them and plug in a postgres connection as well. The unit tests can still run on the hashmaps.

Contrast this with what was called 'steel threads' here a while ago. You might implement some authentication end-to-end, then implement some authorisation end-to-end. You realise you accidentally put 'whitelisting' in the wrong place, and now have to spend 80% of your effort debugging opaque integration tests which test the whole system.

This general method has worked well for me, too.

Keep things as simple as possible for as long as possible, identify abstractions later rather than sooner, build the system knowing it will change and optimize for as little friction as possible when that change inevitably happens.

We shouldn't dismiss the theory of how to do things right just because it is common to do things poorly.

The suggested hodgepodge of over-engineering and mindless indirections in the fine article are far from “doing things right”, though. Stop chasing magic bullets and consider the actual current requirements, while being relatively flexible about them (this will mean something different in each case). Everything else is just a waste of effort and will come back and bite in the long run.

Reply on news.ycombinator.com