4 ms·

>> Make a simple conceptual model. simple, simple - ok I get it. >> This model should cover all aspects, so also the key business aspects. a simple model tha

>> Make a simple conceptual model. simple, simple - ok I get it. >> This model should cover all aspects, so also the key business aspects. a simple model that covers all business aspects? This is where the complexity comes from. Your all-encompassing "simple model" is likely a high-level abstraction that is not implementable. Software systems that model complex domains by definition are complex or incomplete or, and this is what we should avoid, both. This post is either naive or intentionally glosses over why we end up with complexity. All good software starts will the ideal of a clear & simple integrity; the only software that keeps it is likely not used.

adrianmonk 7y ago
> This is where the complexity comes from. It's definitely a major source of complexity. But also there's nothing stopping you from adding in unnecessary complexity on top of that. Part of the trick is to know which is which.
- gmueckl 6y ago
  I've produced the cleanest solutions when I had the luxury of having the problem domain spelled out in detail and locked in place. I could design a system to cover those aspects without second-guessing myself needlessly about future extensibility and other things. If the specs are fluid, all design confidence flies out the window and the resulting system is over-engineered to cover eventualities.
  - flukus 6y ago
    > If the specs are fluid, all design confidence flies out the window and the resulting system is over-engineered to cover eventualities. IMO that achieves the worst of both worlds. If the specs are fluid you have to be able to iterate quickly, dive in, modify code and deploy. Any time code gets over-engineered to elegantly handle future changes it just slows down those changes. You need to accept or even embrace that the requirements will change, not to try and preempt the changes. For 90% of the corporate web apps I've seen a simple CGI site would have been the correct solution, able to change quickly with no layers upon layers of dependencies.
    - gmueckl 6y ago
      Your approach works when you are around to accomodate changes easily. With more red tape in the process (worst case, code developed externally), the incentives to overengineer the the initial solution grow. As you point out, this is bad. But that's how I see things play out.
dllthomas 7y ago
> Your all-encompassing "simple model" is likely a high-level abstraction that is not implementable. I find the simple models are usually easier to implement, but are made simple by ignoring details that are actually important.
rusticpenn 6y ago
The requirements should be seperated into "minimum in-out workflow or MVP", then slowly add features which are a balance between high priority and easy to implement (With a clear way of saying "No" to impracticle requirements). This is generally the "Agile" approach. However at some point its always better to have a complete architechture diagram and work from there. Of course choosing between a monolithic approach or modular approach (or microservices) is also very important at the beginning of the project.

adrianmonk 7y ago

> This is where the complexity comes from. It's definitely a major source of complexity. But also there's nothing stopping you from adding in unnecessary complexity on top of that. Part of the trick is to know which is which.

gmueckl 6y ago
I've produced the cleanest solutions when I had the luxury of having the problem domain spelled out in detail and locked in place. I could design a system to cover those aspects without second-guessing myself needlessly about future extensibility and other things. If the specs are fluid, all design confidence flies out the window and the resulting system is over-engineered to cover eventualities.
- flukus 6y ago
  > If the specs are fluid, all design confidence flies out the window and the resulting system is over-engineered to cover eventualities. IMO that achieves the worst of both worlds. If the specs are fluid you have to be able to iterate quickly, dive in, modify code and deploy. Any time code gets over-engineered to elegantly handle future changes it just slows down those changes. You need to accept or even embrace that the requirements will change, not to try and preempt the changes. For 90% of the corporate web apps I've seen a simple CGI site would have been the correct solution, able to change quickly with no layers upon layers of dependencies.
  - gmueckl 6y ago
    Your approach works when you are around to accomodate changes easily. With more red tape in the process (worst case, code developed externally), the incentives to overengineer the the initial solution grow. As you point out, this is bad. But that's how I see things play out.

dllthomas 7y ago

> Your all-encompassing "simple model" is likely a high-level abstraction that is not implementable. I find the simple models are usually easier to implement, but are made simple by ignoring details that are actually important.

rusticpenn 6y ago

The requirements should be seperated into "minimum in-out workflow or MVP", then slowly add features which are a balance between high priority and easy to implement (With a clear way of saying "No" to impracticle requirements). This is generally the "Agile" approach. However at some point its always better to have a complete architechture diagram and work from there. Of course choosing between a monolithic approach or modular approach (or microservices) is also very important at the beginning of the project.