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:
- 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.