This is a reply to another blog. Both are about the question can you have “readability, hackability, and abstraction” simultaneously. I would argue that this is a very important question, indeed one of those “too important to immediately settle on an answer questions”.
The simple answer, in the OP, from Bob Martin, an experienced systems architect and design guru, is no. I’d agree this is the overall experience someone takes away from any large scale development with the present day technology/skill/organization.
I think this experience and situation is very important, one could say it describes the inherent limits of software - that in the “ordinary realm” or ordinary experience, you get a diminishing return in development time as the size of the system increases.
The thing about this important experience “in the large” is that I’d claim that no one can capture it “on the small”. That given some specific sort of problem with readability, hackability and abstraction, you can a specific solution that seems to solve that problem - OO gives seemingly simple ways to write per machine code, software patterns and programming devices all solve a broad swatch of problem etc. Rather than any particular, visible problem It’s the way all the problems are kind of “nested” in other, larger problems of this sort that makes this kind of problem unavoidable. And an even then, if you can specify how a class of problems is nested, you can find a solution.
So I think that situation is interesting, that if someone could do something like isolate atoms of unhackability or find some similar measure of this, things would interesting.
This is a reply to another blog. Both are about the question can you have “readability, hackability, and abstraction” simultaneously. I would argue that this is a very important question, indeed one of those “too important to immediately settle on an answer questions”.
The simple answer, in the OP, from Bob Martin, an experienced systems architect and design guru, is no. I’d agree this is the overall experience someone takes away from any large scale development with the present day technology/skill/organization.
I think this experience and situation is very important, one could say it describes the inherent limits of software - that in the “ordinary realm” or ordinary experience, you get a diminishing return in development time as the size of the system increases.
The thing about this important experience “in the large” is that I’d claim that no one can capture it “on the small”. That given some specific sort of problem with readability, hackability and abstraction, you can a specific solution that seems to solve that problem - OO gives seemingly simple ways to write per machine code, software patterns and programming devices all solve a broad swatch of problem etc. Rather than any particular, visible problem It’s the way all the problems are kind of “nested” in other, larger problems of this sort that makes this kind of problem unavoidable. And an even then, if you can specify how a class of problems is nested, you can find a solution.
So I think that situation is interesting, that if someone could do something like isolate atoms of unhackability or find some similar measure of this, things would interesting.