Rabbit Holes

Rabbit holes, also known as Coding Safaris, have these attributes:

• They started out with a good design
• They ran into some issues
• Those solutions caused more issues
• They have a lot of indirect code to get to the solution.
• It feels like a mess, it is a mess, and it gets uglier by the day.
• We are inventing ways to get things done.
• The Scrum master asks us every day at the stand up "What's the status" or "Do you need any help?" and we reply "No issues, we're getting there".
• Weeks pass instead of days

The truth is that there's almost no problem we can't solve. It's just a matter of time.

The questions however, should always be:

Spotless Code

• Is the code "spotlessly" clean
• No more than one layer of indirection, e.g. GetData calls.
• The data easily binds to our templates and has hooks to determine events to easily access records.
• Is the code bullet proof.
• Is the code easily readable for future programmers?

As cute as the Schnauzer is; escaping from the Rabbit hole (after 4 days), the owners weren't too happy about it all.

JWP 2020