The 2:00 AM Test

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.

Agile Bashing

from http://dilbert.com/strip/2007-11-26

I keep reading posts about how agile died. And I get it. All I ask is one small favor: Please don’t confuse agile with mis- implementations that go by the same name.

Is agile for everyone? Every business? Every project?
Goodness no!

But…

Agile recognizes some uncomfortable facts about delivering software. For some projects, the answer to some of the questions some of the time (especially at the beginning) is: “We don’t know.”

Like I said, uncomfortable.
Also like I said, fact.

One benefit of agile is it helps some people at some companies on some projects innovate. There’s a word for companies that don’t innovate: not first.

If you read that and thought, “That’s two words, Andy,” you’re right.

Peace.

 

I am a Product Manager (No, I’m Not… But I Can Explain)

I was about to click the Publish button for this post about my new role as a product manager when my friend and brother, Scott, called. I mentioned it and Scott said, “You’re not just a product manager. You’re a problem-solver.”

Scott is correct. Hence the parentheses in the title of this post.

“Is This The Best Use of Your Time?”

A friend used to ask me this question all the time. It’s a fantastic question. The question made me pause and think. Pausing and thinking is mostly good most of the time. When is pausing and thinking not good?

When it delays action you desperately need to take; action you are uniquely positioned to take.

Evolution of a Response

For a couple years my response to this question was to answer, “No,” and then I would feel silly for considering the thing I had wanted to do. But then a funny thing began to happen: I increasingly felt cornered by “the best use of my time.”

<TimeOut>

Let’s pause right here and consider a different perspective. I was being selfish. I wanted to do what I wanted to do, the consequences be damned.

</TimeOut>

This is an accurate description right up until the point where I didn’t do what I wanted to do – what I felt desperately needed to be done – to help people attempting DevOps with SSIS. Instead I stuffed the ideas back down inside, put my head down, and went back to doing what was a good use of my time.

Was I in any position to make this determination?
Was I qualified to make this call?

Yes. Yes I was.

Coming Out of the Corner

Over time, my response evolved. I stopped feeling silly about wanting to solve DevOps for SSIS and started feeling silly for placing myself into a position which offered more obstacles than opportunities.

The short version of a long story is: I extricated myself from that corner.

Before I did anything else – I am not making this up, I can produce witnesses – I started writing SSIS Catalog Compare. I started coding within minutes of announcing my decision.

I did not know what I was doing.
I am still learning.
I feel like I only recently worked my way up to being a n00b C# developer.
I didn’t know anything about designing a software product. I know more now but (still) not enough.
I didn’t know anything about marketing a software product.
I didn’t know anything about managing a software product.

I continue to learn. Here’s the latest thing I’ve learned:

I am not afraid.

I am not afraid of not knowing. Frank Herbert got it right (in Dune): Fear is the mind-killer. The only way to learn is by using my mind – the same mind battling fear of not knowing.

Was the question about the bet use of my time well-intentioned? Absolutely. My friend was watching out for me, he had my back. I learned from the experience and walked away more mature and with broader perspective. I learned. I grew. I would not be where I am now had I not.

I am a Problem-Solver

Scott reminded me I am a problem-solver. I always have been a problem-solver. Lord willing, I will continue to be a problem-solver.

Becoming a software product manager was required in order to solve a problem.

Next.

Dude, Where’s My Controls? (Visual Studio 2017 Behavior)

I’m coding along on the next release of SSIS Catalog Compare, happy as a clam, when I realize it’s time to add a new menu item. I open the form and… nothing.

To say my heart sank would be an understatement. I had questions. “Dude, where’s my controls?” “What happened?!” “Will I be able to recover?” “How long has this been going on?”

I react this way. It happens all the time and it concludes in a couple seconds. I think about it and often tell myself, “You are not the first person to encounter this issue.”

And then I search for the answer.

I found the answer in less than two minutes here.

The Problem

My designer code was no longer nested beneath the form You can see it here:

See that circled part in the image above? frmConfirmation.Designer.cs should be nested beneath the node above it named frmConfirmation.cs. It’s not, and that’s the problem. When I execute the code in the VS debugger the controls show up. I just can’t edit them.

The Solution

As two respondents mentioned in the link above, the solution is to exclude the Designer.cs file from the project:

Re-add it by right-clicking the project, hovering over Add, and then clicking Existing Item:

Navigate to the Designer.cs file and select it to re-add it to the solution:

This fixes the missing controls:

:{>