HN Theater @HNTheaterMonth

Architecture is also really useful in another regard: making the right (or at least "good enough") decisions on things that will be really painful to change later.

Think for example the choice of programing language or the DB technology used.

Architecture must strike the correct balance between vague guidelines and over-specification upfront. It should provide a framework which ensure homogeneity between components without restricting the teams/developers excessively.

On this subject, I found this presentation (by Stefan Tilkov): https://www.youtube.com/watch?v=PzEox3szeRc

Also, I'm currently reading "Designing Data-Intensive Applications", which is quite interesting and full of insight on the architecture trade-offs for data management and querying.

⬐ bluGill

Note that sometimes the right DB is one specific one. Other times it is enforcing everyone use a DB abstraction so that you can switch DB. If you choose the later make sure you have 3 databases at all times to enforce using the abstraction. Ideally one isn't sql.

Likewise sometimes you choose the language (or maybe two), sometimes you choose an inter language communication protocol and allow any language. Either can be good or bad. The right answer for you is important.

Some choices above are hard to undo if you are wrong. However the hardest to undo often have significant advantages if it all works out.

⬐ kakwa_

Moving from a DB engine to another, even if technically possible (right abstractions and everything), is often extremely painful once you have a few years of data.

(I'm currently involved in migrating quite a few large DBs, and it's a pain for everyone: SREs, support teams and the customers).

But yes, there is no "one size fits all", it depends pretty much on how your org is operating.

⬐ bluGill

That isn't the only reason to support more than one engine. Sometimes you don't need to move data to change the engine.

If you sell a product that needs a database you probably want an abstraction so you can use the customer's database and schema.

⬐ montroser

I agree with the idea that you should take most seriously the decisions that will be hardest to undo.

However, using a database abstraction layer in this way is counter to optimizing for simplicity, and in a way is not making a decision at all.

If you are using a database abstraction layer so thoroughly that you really can switch between different database implementations, then you are almost certainly not leveraging the strengths of any underlying database engine to begin with. So you are limiting your performance, at the same time as introducing complexity.

⬐ bluGill

That is exactly the trade off. Which is why sometimes it is wrong despite the obvious advantages of being able to change

⬐ transitivebs

I wish I understood the distinction earlier on in my career between scalable solutions and doing things "the right way" from the perspective of a CompSci background versus focusing on product / business and having an architecture that's "good enough".

Great talk - this type of mentality should be required understanding for software engineering & computer science students.

⬐ foxfired

"Good Enough" is unfortunately something you learn after you destroyed a system. Everything makes sense when you are building the new architecture until someone else complains.

⬐ pezo1919

To me good enough practically means almost perfect, because it's just matter of time you go broke with an imperfect architecture.

To me the relevant keywords for the futures programming environment and architecture: FRP, Cycle.js, Idris.

⬐ douchescript

All tech will go the way of rational rose Sooner than later.

⬐ codr7

Just breathe through it, it's a phase.

Every good solution will be some kind of compromise, keeping it simple is more important than picking "perfect" tools.

⬐ lolc

Nice talk. Somewhere in the middle I realized it was a room full of people and we don't do that anymore. How long will it be? Anyway, back to topic.

To hear him tell it, the situation is clear. And the path forward doesn't need discussion because analysis and recommendations are done. I shuddered at the insane 6 month change process story. Yet it's not that clear when you're in the middle of it. There are all these frustrations. People talk about rewriting. And a lot of things should have been completed yesterday. The tests are not written. Deployment relies on hacks you won't tell.

It helps a lot to have an outsider come in, look at the architecture, the processes, and just ask why. They say "look if you do this you'll have x, y, and z problems." And you realize that you indeed have x, y, and z. It's just always been that way. And often you understand you're stuck with it for the foreseeable future. Talking about architecture so that you know where you want to go, will allow taking incremental steps in the right direction.