Hard Problem? Stop Staring At The Code

BLUF

Can't get the software to work?

Stop Staring At It.

Often, there are two problems:

  • The code doesn't work.
  • You're making faulty assumptions about why it doesn't work.

It's essential to stop staring (and hand-wringing) over the code and gather evidence.

This will allow you to challenge your faulty …

more ...

Hard Problem? Try Shifting Position

BLUF

Can't get the software to work?

Rewrite it.

Seriously.

It's often faster to pick a new paradigm and start a rewrite than to bang your head against a wall.

Modern languages (like Python) don't require a lot of overhead or boilerplate to start again.

Can't get the object model …

more ...

OO Design and Card Games

Lets look at my favorite OO-Design problem domain: card games.

We'll compare the design of two games: Cribbage and Canasta.

Why? Because they have three common abstractions: cards, hands, and a score.

Overall the players are dealt cards, form hands, and at some point, accumulate a score. Of course, all …

more ...



Coping with Complexity

I'm struggling with brain cramps trying to understand something my past self wrote. Current me needs to go outside and do something that doesn't involve software or complexity. Sadly, current me is trying to make one small change and it feels like the software has passed out of the realm …

more ...



Architectural Boundaries: Which Package/Module/Class Owns That Responsibility?

The SOLID design principles beat the design boundary issue to death. Here are the principles in my preferred order. (See https://www.linkedin.com/learning/learning-s-o-l-i-d-programming-principles)

  1. Interface Segregation -- minimize the boundaries. Do this first.
  2. Liskov Substitution -- keep the boundaries consistent. Do this for hierarchies.
  3. Open/Closed -- keep the boundaries stable …
more ...