• About

Software For Profit

~ How to Build Incredible Software

Software For Profit

Category Archives: TDD

The Generalization Myth

20 Tuesday Aug 2019

Posted by Kyle in Philosophy, SOLID, TDD, Technique

≈ Leave a comment

Generalization is beautiful and exciting – and offers many glorious health benefits.  It reduces the amount of code we have to write, and solves problems before they even arise.  With just a tiny amount of forethought – we can make any future work we do trivial, simply by achieving the right generalization.  It makes you more attractive to the opposite sex – and if done *just* right even grants you eternal life.

elsa-reaching-2

“I can almost reach it Indie”

No wonder, like Elsa in the Indiana Jones movie, we neglect our own lives to attain it.  “I can almost reach it, Indie”…

The Holy Grail, is of course, a myth.  Though it makes for a good tale – sprinkle in some Nazis, some betrayal, some family tension.  What a story.

In reality – the generalization that we all grasp for is also a myth.  There is no way to know ahead of time what generalization will meet all of (or even one of) our upcoming use-cases.  This is based mostly on the fact that we don’t know even what our upcoming use-cases are – let alone what kind of structure will be necessary to meet them.  And the generalization you choose ahead of time, if it doesn’t match what you need in the future, is wasteful, because it limits the moves you can make.  This is what generalization does, it limits expressive options to the abstraction that you select.  And since you can never know the generalization you need, this always results in negative ROI.  (Not as bad as falling into a bottomless pit, but still not exactly what we are going for)

The challenge is that it always SEEMS so obvious that it will result in nothing but advantage in the context we are working in, to generalize.  This instinct is good – if you let it push you toward moderate flexibility in design, and refactoring (after you’ve solved a use-case) to a more generalized structure.  Generalization that you arrive at AFTER you’ve learned what the use-cases will be (that is, after you’ve tested and coded them), and moderate flexibility in your design are both highly profitable.  But they are both the result of disciplined, after-the-fact thinking; not a result of the magical thinking that we can somehow avoid work if we divine the right generalization before-the-fact.

This is also another reason that before-the-fact generalization seems so appealing – because it appears to give us something for nothing.

lastcrusade

“Let it go…”

After-the-fact generalization that results in clean, easy to maintain code, that has a very positive return tends to seem simply like the diligence of a mature adult.  Obviously the former, while maybe not tied to reality, is far more Rock-n-Roll.

As mature Craftsmen – we should do like Mr. Jones, and listen to the advice of his dad – “let it go, Indie, let it go…”

Once we’ve let this temptation go, we can take the following methodical approach – which will satisfy our impulse to generalize, but do it in a way that will result in a powerful, positive outcome.

  1. Solve the use-case(s) at hand, directly, with the simplest possible code.  Use a test (or tests) to prove that you’re doing this.
  2. Solve with designs that are SOLID.  SOLID leads to flexibility – flexible systems are easier to change systems.
  3. Refactor: remove anything creating a lack of clarity, generalize where there is unnecessary duplication.
  4. Rinse and Repeat

If we do this we will be creating amazing software!

Happy Coding!

Kyle

 

 

Partial Mocking and Scala

13 Thursday Dec 2018

Posted by Kyle in Scala, TDD, Technique

≈ Leave a comment

I don’t know how to get this across with the level of excitement it brought to me as I discovered it.  But I’ll try.

I love TDD – the clarity, focus, and downright beauty it brings to software creation is absolutely one of my favorite parts of doing it.  I love the learning that it drives, and I love the foundation it lays for a masterpiece of simplicity.  It’s unparalleled as a programming technique — I only wish I would have caught on sooner.

I love Scala.  I can’t seem to find the link – but there was a good list about how to shoot yourself in the foot in various languages – in Scala, you stare at your foot for two days and then shoot with a single line of code.  The language is amazing in its ability to let you get across your meaning in a radically concise, but type-safe way.  I often find myself expressing a thorough bit of business logic in one or two lines.  Things that would have taken 20-30 lines in a typical C-derivative language.  It’s a fantastic language.

Writing Scala – I’ve gotten into a situation that finally, powerfully, crystallized in an experience this morning.  I spent probably an hour struggling to get at the most understandable, most flexible solution.

The situation is this – I have a class that’s definitely a reasonable size – 30-50 lines or so.  In this case, most of the methods were one-liners.  And they were one-liners that built on each other.  The class had one Responsibility, one “axis of change”.  I liked it as it was.

One problem that arose was that one of the methods was wrapping some “legacy code” (read: untestable – and worse unmockable).  In my Java days – this wouldn’t have even arisen as a problem, because the method using the legacy code would have probably warranted its own class, and thus I could have easily just mocked that class.  As it was, I considered it.  But as I said, the class was very expressive, and said as much as it should have, without saying any more.  To cut a one line method and make it a one line class…would have bordered on ridiculous – it would have been far too fine grained at any rate.

So what’s a code-monkey to do?  Well – I tripped across this idea of a partial mock.  Which, I would have derided as pointless in my Java days – and in fact, the prevailing wisdom on the interwebs – was that partial mocking is bad.  I don’t want to do bad.  By the way, if you haven’t googled it already – partial mocking is simply taking a class, mocking out some methods, but letting others do their original behavior (including calling the now mocked methods on the same class).

Anyway – the more I stared at the problem and balanced the two forces at play, the more I realized how right the solution really is.  In my experience, in Scala, the scenario I just laid out is common, and the only real way to solve for it is with partial mocking.

(Big thanks to Mockito for providing this capability – so awesome!)

Recent Posts

  • Killing Software Development Capacity, Part 3: Superficial Thinking
  • Killing Software Development Capacity, Part 2: Philosophizing
  • How To Use Systems Thinking To Destroy Your Team
  • The Text-Native Communicator, Remote Work & Serendipity
  • Silos Are A Good Thing ™

Archives

  • February 2020
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • June 2019
  • May 2019
  • April 2019
  • December 2018
  • August 2018
  • July 2018
  • June 2017
  • May 2017
  • February 2017
  • January 2016
  • November 2015
  • June 2014
  • October 2013
  • January 2013
  • September 2012
  • August 2012

Categories

  • agile
  • General
  • Management
  • Philosophy
  • Scala
  • SOLID
  • TDD
  • Technique
  • Uncategorized

Meta

  • Register
  • Log in
  • Entries feed
  • Comments feed
  • WordPress.com

Blog at WordPress.com.

Cancel
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy