Tipping Point

There is a psychological tipping point that affects DI Refactoring1.

At some point, there is too much code and the solution becomes “too big to re-engineer”.

At that point, coding overrides solving. We retain the code and throw away possible improvements.

What is that “tipping point”?

I haven’t measured it.

I know that if I use Lisp, I am more likely to throw my code away when I think of design changes.

I know that if I use towers of data structures in just about any PL2 I am more likely to ignore late architectural changes, or, suffer horribly.

I know that if I draw my solution on a whiteboard, I am more likely to accept and implement design changes.3

I know that if I can see my whole solution - say in one eye-full (a window, a page) - then I am more likely to accept and implement design changes.

See Also

References
Table of Contents

  1. DI means Design Intent. Often, the term Software Architecture is overloaded to mean DI. ↩

  2. PL == Programming Language. ↩

  3. In fact, I have figured out how to automate drawings. I can make drawings that can be automatically compiled to code. I favour the use of a minimal subset of SVG as the atomic syntactic element (intead of single characters) - rects, ellipses, lines, text. ↩