3 ms·

Agreed, good architecture doesn't come into play until you need to add a lot of complex features or scale significantly. Initially architecture doesn't really m

Agreed, good architecture doesn't come into play until you need to add a lot of complex features or scale significantly. Initially architecture doesn't really mean squat. I would concentrate on making the codebase flexible, but that's about it. I've regretted making some of my software with a cool but complex architecture when I should have been focused on what the product does.

humanrebar 9y ago
> I would concentrate on making the codebase flexible, but that's about it Arguably that's the property of good architecture. Standardizing your entire codebase also works, but only as long as those initial standards stay smart (1), and even then, that relies on discipline, tools, and incentives that are typically not all in place. (1) A standard might be "all webservers will be written in Java 6". The benefits of choosing that standard tend to be front-loaded with a gradual decline into net-negative with no affordable path to a better standard.
- qznc 9y ago
  To design your software perfectly requires to know the future. You want the things that will change flexible and the rest simple. In practice, you will not hit the sweet spot and either over-engineer too much or hardcode too much (or both in different parts).
  - gregmac 9y ago
    I tend to place the most emphasis on loose coupling, and being very strict about interfaces between components -- both in terms of documentation and addition/changes. Ideally documentation includes unit or integration tests. This applies to separate high level services as well as it does to internal code structure (classes/modules/etc). Well documented and tested interfaces of a component make that component easy to replace or rewrite if needed. Nearly anytime I have worked on or been involved with a project where I or someone else tried to design specifically for a vague future requirement that wasn't entirely clear or guaranteed, it didn't work out: either the requirement never happened, or was so materially different that what we wrote was wrong. As a result, the code we wrote went unused or worse, just got in the way and ended up as unnecessary technical debt.
madisonmay 9y ago
In Knuth's words: "Premature optimization is the root of all evil". Although I guess in this context, you're emphasizing that it's more valuable to solve the right problem poorly than it is to solve the wrong problem well.
- Clubber 9y ago
  I didn't say anything about solving the right problem poorly, but you are probably speaking a truth, depending on what poorly means. It certainly isn't ideal. I've seen solutions designed so poorly that when it came time to add features that paying clients wanted, it was significantly more difficult (significant risk) than if it was designed well. I'd say solve the right problem well, without spending time on requirements you don't yet have. These would include a large scalability requirement and over-modularization, like breaking out 10 "micro services."

humanrebar 9y ago

> I would concentrate on making the codebase flexible, but that's about it Arguably that's the property of good architecture. Standardizing your entire codebase also works, but only as long as those initial standards stay smart (1), and even then, that relies on discipline, tools, and incentives that are typically not all in place. (1) A standard might be "all webservers will be written in Java 6". The benefits of choosing that standard tend to be front-loaded with a gradual decline into net-negative with no affordable path to a better standard.

qznc 9y ago
To design your software perfectly requires to know the future. You want the things that will change flexible and the rest simple. In practice, you will not hit the sweet spot and either over-engineer too much or hardcode too much (or both in different parts).
- gregmac 9y ago
  I tend to place the most emphasis on loose coupling, and being very strict about interfaces between components -- both in terms of documentation and addition/changes. Ideally documentation includes unit or integration tests. This applies to separate high level services as well as it does to internal code structure (classes/modules/etc). Well documented and tested interfaces of a component make that component easy to replace or rewrite if needed. Nearly anytime I have worked on or been involved with a project where I or someone else tried to design specifically for a vague future requirement that wasn't entirely clear or guaranteed, it didn't work out: either the requirement never happened, or was so materially different that what we wrote was wrong. As a result, the code we wrote went unused or worse, just got in the way and ended up as unnecessary technical debt.

madisonmay 9y ago

In Knuth's words: "Premature optimization is the root of all evil". Although I guess in this context, you're emphasizing that it's more valuable to solve the right problem poorly than it is to solve the wrong problem well.

Clubber 9y ago
I didn't say anything about solving the right problem poorly, but you are probably speaking a truth, depending on what poorly means. It certainly isn't ideal. I've seen solutions designed so poorly that when it came time to add features that paying clients wanted, it was significantly more difficult (significant risk) than if it was designed well. I'd say solve the right problem well, without spending time on requirements you don't yet have. These would include a large scalability requirement and over-modularization, like breaking out 10 "micro services."