2 added 142 characters in body
source | link

Sure: Joel Spolsky (you may have heard of him) says:

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions.

It's really hard to create good abstractions -- it's a whole lot easier to create crappy ones.

Also, see KISS and YAGNI which Jeff Atwood discusses:

As developers, I think we also tend to be far too optimistic in assessing the generality of our own solutions, and thus we end up building elaborate [solutions] around things that may not justify that level of complexity. To combat this urge, I suggest following the YAGNI (You Aren't Gonna Need It) doctrine. Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become.

(see the link for the exact quote)

So for example, if you add an abstraction for which there is no need, now you have extra code that needs to be tested, debugged, and maintained.My interpretation of these quotations:

  1. It's really hard to create good abstractions -- it's a whole lot easier to create crappy ones.

  2. If you add an abstraction for which there is no need, or which is wrong, now you have extra code that needs to be tested, debugged, and maintained. And if you have to go back and refactor, you now have more dead weight dragging you down.

Sure: Joel Spolsky (you may have heard of him) says:

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions.

It's really hard to create good abstractions -- it's a whole lot easier to create crappy ones.

Also, see KISS and YAGNI which Jeff Atwood discusses:

As developers, I think we also tend to be far too optimistic in assessing the generality of our own solutions, and thus we end up building elaborate [solutions] around things that may not justify that level of complexity. To combat this urge, I suggest following the YAGNI (You Aren't Gonna Need It) doctrine. Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become.

(see the link for the exact quote)

So for example, if you add an abstraction for which there is no need, now you have extra code that needs to be tested, debugged, and maintained.

Sure: Joel Spolsky (you may have heard of him) says:

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions.

Also, see KISS and YAGNI which Jeff Atwood discusses:

As developers, I think we also tend to be far too optimistic in assessing the generality of our own solutions, and thus we end up building elaborate [solutions] around things that may not justify that level of complexity. To combat this urge, I suggest following the YAGNI (You Aren't Gonna Need It) doctrine. Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become.

(see the link for the exact quote)

My interpretation of these quotations:

  1. It's really hard to create good abstractions -- it's a whole lot easier to create crappy ones.

  2. If you add an abstraction for which there is no need, or which is wrong, now you have extra code that needs to be tested, debugged, and maintained. And if you have to go back and refactor, you now have more dead weight dragging you down.

1
source | link

Sure: Joel Spolsky (you may have heard of him) says:

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions.

It's really hard to create good abstractions -- it's a whole lot easier to create crappy ones.

Also, see KISS and YAGNI which Jeff Atwood discusses:

As developers, I think we also tend to be far too optimistic in assessing the generality of our own solutions, and thus we end up building elaborate [solutions] around things that may not justify that level of complexity. To combat this urge, I suggest following the YAGNI (You Aren't Gonna Need It) doctrine. Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become.

(see the link for the exact quote)

So for example, if you add an abstraction for which there is no need, now you have extra code that needs to be tested, debugged, and maintained.