4 ms·

Ultimately, software design is a prediction of the future. You make those parts flexible where you will need it. You make other parts simple and opinionated whe

by qznc 10y ago

Ultimately, software design is a prediction of the future. You make those parts flexible where you will need it. You make other parts simple and opinionated where you need no flexibility. Like all predictions we are often wrong, which leads to either over-engineering or lack of features.

blazespin 10y ago
Which is why you want to iterate rapidly with your ideal core customer base so you don't have to predict, just delight and please.
raverbashing 10y ago
Hence, Agile. So you don't waste time planning all your work, when the customer will have changes or additions in the future And more flexible languages and frameworks
mmazing 10y ago
I tend to operate under the assumption that everything will need to change, so I need to make it easy to change.
csydas 10y ago
It depends. How much the scope and vision of a project will vary in 2-5 years and 5+ years will vary greatly depending on the project. A small internal app for an institution or business probably should be far more cautious and simplistic than a consumer program designed to scale out as the business grows and customer needs change. Fit for purpose seems to be the idea that the author is conveying for an end-user level, and I feel that's something that gets lost in Slack chats/at the conference table whiteboard when designing things. A program that just does what it's supposed to isn't really lacking features, it's just doing what it should. I've seen this countless times with project management just hitting feature bloat after the initial part got to the "works somewhat reliably" stage, and suddenly it's time for the feature set to expand for some reason. In the projects I was dealing with, it happened as people tried to satisfy their egos and to show off; this isn't always the reason, but it's a reason. Other times I'd assume it's just a neat feature that someone wants to work on but has no where else to put it. I think it's just important from the get-go to determine do you really need software that evolves or do you need software that works really well at what it's supposed to do. I'm sure you can do both, but at a certain point it seems like these two directions start to pull too far away from each other.
jasim 10y ago
And it is incredibly hard to predict the future. So I just try to engineer things forcefully for only today's needs. And instead of future-proofing, I try to make it easily comprehendible. Make their intentions as explicit as possible. Comprehension trumps everything. Because before we can actually change code by typing it in, we need to be able to hold it in our head and mend it there. And if you can clearly see in your mind's eye what is currently there, you can see what it can become. The above applies only when we have to 'predict' the future. Oftentimes we know the future already - there is going to be ton of traffic, we are going to need an API for this use case, we are actually going to stay in business etc.
- tempodox 10y ago
  > Comprehension trumps everything. I couldn't agree more. This is as close to a “silver bullet” as we will ever get.
- xupybd 10y ago
  This comment is so on point, I love working with code that has been built with that philosophy. The code remains simple and you don't waste hours trying to seperate useful complexity from bloat.
- qznc 10y ago
  > ton of traffic This comes with assumptions. Depending on the magnitude of the traffic you need very different architectures. For example, see Pokemon Go https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html https://cloudplatform.googleblog.com/2016/09/bringing-Pokemo... > an API How flexible should the API be? For example, do you need multiple representations (JSON, YAML, XML, etc)? Maybe it makes sense to build it representation-agnostic, but maybe it is over engineering.
  - 0xCMP 10y ago
    This is true, but unless you understand the problem then (which you might not since not all of us work at 50x expected load) then how do you architect it properly while also not wasting time?
speedplane 10y ago
In virtually every feature of every piece of software (or device, or product), some aspects will be over engineered, and some will be under-engineered. I think however, the point of the article was that often engineering "narcissism" gets in the way. But to some, that narcissism is just beautiful code or doing it "right". This article is hopelessly subjective, but makes its point clear enough.
xg15 10y ago
There is another point though, which is separation of concerns. E.g. if I have a system with different features and some of those features require authentication, I don't want to write a separate authentication system for each feature - here, an abstraction that separates the authentication system from the actual features is really useful.
deleted 10y ago
[deleted]

by qznc 10y ago

blazespin 10y ago

Which is why you want to iterate rapidly with your ideal core customer base so you don't have to predict, just delight and please.

raverbashing 10y ago

Hence, Agile. So you don't waste time planning all your work, when the customer will have changes or additions in the future And more flexible languages and frameworks

mmazing 10y ago

I tend to operate under the assumption that everything will need to change, so I need to make it easy to change.

csydas 10y ago

It depends. How much the scope and vision of a project will vary in 2-5 years and 5+ years will vary greatly depending on the project. A small internal app for an institution or business probably should be far more cautious and simplistic than a consumer program designed to scale out as the business grows and customer needs change. Fit for purpose seems to be the idea that the author is conveying for an end-user level, and I feel that's something that gets lost in Slack chats/at the conference table whiteboard when designing things. A program that just does what it's supposed to isn't really lacking features, it's just doing what it should. I've seen this countless times with project management just hitting feature bloat after the initial part got to the "works somewhat reliably" stage, and suddenly it's time for the feature set to expand for some reason. In the projects I was dealing with, it happened as people tried to satisfy their egos and to show off; this isn't always the reason, but it's a reason. Other times I'd assume it's just a neat feature that someone wants to work on but has no where else to put it. I think it's just important from the get-go to determine do you really need software that evolves or do you need software that works really well at what it's supposed to do. I'm sure you can do both, but at a certain point it seems like these two directions start to pull too far away from each other.

jasim 10y ago

And it is incredibly hard to predict the future. So I just try to engineer things forcefully for only today's needs. And instead of future-proofing, I try to make it easily comprehendible. Make their intentions as explicit as possible. Comprehension trumps everything. Because before we can actually change code by typing it in, we need to be able to hold it in our head and mend it there. And if you can clearly see in your mind's eye what is currently there, you can see what it can become. The above applies only when we have to 'predict' the future. Oftentimes we know the future already - there is going to be ton of traffic, we are going to need an API for this use case, we are actually going to stay in business etc.

tempodox 10y ago
> Comprehension trumps everything. I couldn't agree more. This is as close to a “silver bullet” as we will ever get.
xupybd 10y ago
This comment is so on point, I love working with code that has been built with that philosophy. The code remains simple and you don't waste hours trying to seperate useful complexity from bloat.
qznc 10y ago
> ton of traffic This comes with assumptions. Depending on the magnitude of the traffic you need very different architectures. For example, see Pokemon Go https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html https://cloudplatform.googleblog.com/2016/09/bringing-Pokemo... > an API How flexible should the API be? For example, do you need multiple representations (JSON, YAML, XML, etc)? Maybe it makes sense to build it representation-agnostic, but maybe it is over engineering.
- 0xCMP 10y ago
  This is true, but unless you understand the problem then (which you might not since not all of us work at 50x expected load) then how do you architect it properly while also not wasting time?

speedplane 10y ago

In virtually every feature of every piece of software (or device, or product), some aspects will be over engineered, and some will be under-engineered. I think however, the point of the article was that often engineering "narcissism" gets in the way. But to some, that narcissism is just beautiful code or doing it "right". This article is hopelessly subjective, but makes its point clear enough.

xg15 10y ago

There is another point though, which is separation of concerns. E.g. if I have a system with different features and some of those features require authentication, I don't want to write a separate authentication system for each feature - here, an abstraction that separates the authentication system from the actual features is really useful.

deleted 10y ago

[deleted]