I’m working with a collection of clients these days providing data integration, cloud, and DevOps advice. I love architecture work! My clients love the results. Everyone wins.
Kent Bradshaw and I are tag-teaming with a couple clients who are converting data integration from other platforms to SSIS. In a recent meeting Kent mentioned “the 2:00 AM test.”
“What’s the 2:00 AM Test, Andy?”
I’m glad you asked! The 2:00 AM test is a question developers should ask themselves when designing solutions. The question?
“Will this make sense at 2:00 AM? When I have – or someone else has – been awakened by a job or application failure? Will I be able to look at this and intuit stuff about how this is supposed to work?”
Future You Will Thank You
The reason the 2:00 AM test is important is because later – at some point in the future when you’ve long-since stopped thinking about the stuff you’re thinking about when you designed this solution – you (or someone) will be awakened at 2:00 AM by some failure. Even if it’s you, there’s a good chance you won’t remember all the nuances of the design. Even if you do, you may not remember why you designed things the way you did.
So…?
Be like Hansel and Gretel. Leave yourself some breadcrumbs. What kind of breadcrumbs?
Comments
Code comments are the best way to record what you are thinking at the time you are thinking it. Consider the lifetime of a software solution. It may take an hour, a day, week, or month to build; but it may be in production for years. Are you going to remember why you made each decision you made? Are you going to be able to recall – years later – why you zigged instead of zagging?
Call out anything not readily accessible, anything invisible on the initial view of the immediate coding surface. If you’re writing VB or C#, include a comment explaining – at a minimum – where to learn more about classes and objects not readily available. If you used NuGet to import stuff, will it kill you to copy and paste the command into a comment?
In SSIS, if you’re using variables or parameters or event handlers, add annotation to the control flow or data flow task.
Leave yourself a note.
Practice Good Naming
My friend Joel has a t-shirt based on this tweet:
One the two hard things is naming things. I suggest descriptive names for stuff. Which stuff? In VB or C#, variables, methods, and classes for starters. For SSIS I heartily recommend Jamie Thomson’s iconic post titled Suggested Best Practises and naming conventions.
Good naming conventions promote self-documenting code.
Small Chunks
Coders on all platforms develop a sense of a “good size.” An easy trap to fall into is attempting to “boil the ocean.” Break things up. Practice separation of concerns. Write decoupled code.
You will find decoupled, small, function-of-work code is simpler to test, easier to maintain, and promotes code reuse.
Conclusion
Future you will thank for incorporating these best practices in your coding, regardless of your software development platform.
