It allows us to ensure that our code is properly and adequately abstracted.

The current line of thinking -

A codebase is maintainable inasmuch as it is properly and adequately abstracted.

Q) How do we know our abstractions are improper or incomplete?

A) When we cannot write succinct code in some place. That is, either we have awkward, overly long, error-prone, or duplicated expressions.

We endeavor to write succinct code in order to reveal where writing succinct code is infeasible with our current abstractions.

The only way to reveal improper / inadequate abstractions is to legitimately fail to write succinct code.

The only way to fix and complete abstractions is by fixing or introducing new abstractions as they are needed (or sometimes even removing existing abstractions). Succinctness will even reveal the fundamental limitations of your implementation language, leaving you pining for a better one (which, imo, is a very very good thing).

You can replace all use of 'code' here with 'english' and abstraction with 'words' or 'vocabulary'. Also could be done with 'mathematical expressions' and 'mathematical symbols'.

Endeavoring to write succinct code is a great way to build a maintainable codebase. Succinctness applies equally in english and mathematics, and probably most other fields of expression.

--BryanEdds

----
// I have made this function so long only because I did not have the time to make it shorter.

 /*
  * Requirement: NEED 2-FUNCTION SCRIPT IN TWO DAYS.
  * Implementation Note: NO CAN DO 2 FUNCTIONS IN TWO DAYS. 
  * CAN DO 30 FUNCTIONS 2 DAYS. NEED 30 DAYS TO DO 2 FUNCTIONS.
  */

''Of course, we strive for succinctness where possible in practice rather than making it a stringent requirement. Here the trying is more important than the achieving. That we don't always expect to be succinct doesn't mean we shouldn't try.'' -BryanEdds
-------
I tend to think of this in terms of economics weightings (which is sometimes controversial here). Overhauling code to make it more succinct can be expensive. However, it can be worth it if it saves sufficient work down the road. But, how far down the road do we calculate? FutureDiscounting offers some suggestions. 

Also, succinct code is not always flexible code. Sometimes I assume abstractions based on current patterns that fall apart in the future (AbstractionsThatFallApart), such that one has to yank out the original abstraction, or add ugly band-aides. One needs to ask themselves, "is this abstraction really likely to fit the domain down the road, or merely happenstance?"

--top