Ask HN: How do I stop being obsessed with software architecture?

I used to struggle with this.

Good engineering is not about good code. Good engineering is about taking the actions you need to take to solve a problem while minimising costs. Usually the problem is making money and usually the biggest expense is time. Writing good code can be useful but knowing when not to spend the time makes you a better engineer.

Our school took us to the engineering department at the local university for a taster day. They challenged us to build a wheeled robot which could cross a swimming pool in the shortest time possible. I got together with my geeky friends and at the end of the day we proudly presented our clever tower of gears robot which kept the motor above water while transferring power to the wheels

The trouble makers in the class also teamed up and spent the whole day throwing around bits of Meccano at each other and at us. As the teachers announced end of time they quickly attached a couple wheels to their motor and called it a day.

When it came time to race, their entry sank straight to the bottom, hit the floor and sped across to the other side before ours had a chance to get its coat on. They won by a large margin, and for good reason! None of us had thought to wonder if the batteries and motor could run under water, it would only need to do it once and last say 30 seconds, none of us had questioned the requirements and we’d spent the day building something slow and complicated. If I find myself spending too long on abstractions and not the problem I think back to this

> How do I stop being obsessed with software architecture and actually focus on getting shit done?

Write the documentation of the current and besides it write documentation of the new version. Refactoring is important and it helps further to have the documentation of the new before you've rewritten the old. Unless it's a brand new application; it's going to be the same right?

Articulate your current application so you have a visual proof of that it is doing what it should be doing. how is it's functioning and ensuring you can rebuild said app from scratch from documentation alone.

With that documentation you then start to unbundle the knots you've created in your mind and code. You see the faults, lags and notice where improvements and new features can all the rest.

The newly documented pseudo-code then presents the foundation plan of your next version and enables the ability of implementation of feature sets, the fixes required that would be a struggle to retrofit.

It's tedious, boring, a great effort and hard discipline but when you've got it down on paper you've then got true focus to the software architecture. It opens your mind.

Documentation plays a big part in all code and your app/program will always feel not-it without it. I'm currently writing mine and it's a chore. I would love to implement my new discovery feature or to create an editor to document my own code but the deeper I go without documentation the more thicker dark mist I encounter.

this answer might seem off topic, but it really isn't. your problem isn't really architecture here - it's getting stuck in an unproductive mental rut. do you agree?

if you do agree, then the solution is something along the line of avoiding the rut in the first place:

1. strengthen your resolve to think things through before committing to them - is it worth the risk?

2. get a second opinion - talk to your social network (in person preferably), about your idea, your concerns about it, and ask them to check up on you a quarter of the way through - if it seems like it's not a good idea, it's often easier for others to spot it in our behaviour.

for the first one, you could consider things like mindfulness meditation/reading Stoic literature - these help you build the mental skills to step back and ask questions instead of being dragged around by what is ultimately an emotional excursion.

It's the same "make it work; make it right; make it fast". The issue is that Scrum has emphasized the first one at the expanse of the other two. Minor changes over the lifetime of the project snowball into an inconsistent and complicated codebase. No time is given to reflect on the project and each module to refactor it into something sane every once in a while. It's all about velocity instead of maintainability, correctness, and performance. The craftsman in you will certainly react to that.

> The sad thing is that I start the refactor, realize midway that I did not think it through, waste a day of my life, go to sleep, and repeat the same tomorrow thinking that I have found a "better way" to do it, just to make the same mistake again in a different place.

FWIW, this isn't wasting your time. This is exactly how your learn your craft. You don't learn much from things that work right first time, you learn from making mistakes, and understanding why they failed. Over time, that turns into intuition - a gut feeling that approaching a problem one way will fail because you remember that time you did something a bit similar and it turned out to be a bad idea. Given enough experiences like this, when you encounter a new problem, you'll very quickly be able to limit the solution space down to something manageable and then you have a good chance of coming up with a good solution almost right away. You might still make mistakes or bad decisions, but the more of those you've had in your past, the less likely they'll be in your future.