Email: Unmistakable Clarity

Hey Team,

I have talked about "unmistakable clarity" before.  It is very important to me that we all understand each other perfectly.  There is a language barrier because your English is not perfect.  I am not complaining because I ONLY speak English (and a little Spanish).

So, I just want to say that if I ask for more explanation, don't take it personally.  And on the other hand, you can always ask me to be more clear or to talk more slowly.  I want to give a couple examples that cause a lot of confusion.  A LOT of people who speak English perfectly do this:

• "I was talking to John and Ted about the issue, he told me that it was resolved."
• He = John? 
• He = Ted?
• "I was working on issue A last week and then started work on issue B.  It took extra time, so issue C will be late."
• It = issue A
• It = issue B?
• "I talked to John on Monday and Ted on Tuesday about the issue last week.  We decided the issue was closed."
• We = you and John?
• We = you and Ted?
• We = you and John and Ted?

It, he, she, we, they... these words are called pronouns.  Sometimes they are fine to use and there is no chance for confusion.  But sometimes they can cause confusion, and in this case it’s better to just repeat yourself by saying "I talked to John on Monday and Ted on Tuesday about the issue last week.  Ted and I decided the issue was closed."  It sounds kind of dumb but I still do it because I know it’s the smart thing to do.

And again, any time I’m not being clear, please let me know and I will explain more.

Information Science: Exponential, Logarithmic, and Linear Curves

Motivation

I often hear people use the word "exponential" in phrases such as "exponential growth" or "x is exponentially more difficult than y" (which often times doesn't actually make sense) but I rarely hear people use the words linear or logarithmic.  If you value using English correctly, they're all helpful to know and all are simple to learn.  See the Final Note below for more.

The Curves

For use in conversation, it's not necessary to know the math behind these curves, so I won't go into it.  Here are the curves, with exponential in blue, linear in red, and logarithmic in green:*

Pure math is hard to explain without examples.  I didn't grok algebra until I took calculus.  I didn't grok calculus until I took physics.**  I'll give a couple examples to explain these curves.

Learning:

Learning curves are often described by these curves.  I think this was the impetus for this blog post.  Note: This is kind of sciencey, that is to say, it's pretty nonscientific.  That's also to say I bet some people will disagree.

Exponential:

"Easy to do, hard to get very good at"

Example:
Shooting pool.  Pretty much anyone can pick up a pool cue and knock the balls around.  It might take you a half hour to finish a game of eight-ball, but you can do it.  In my experience, to get to even a "hey, you're pretty good" level takes dedication.  It's an incredibly nuanced game and just seeing the right shot to take, let alone making it and leaving the ball set up for the next shot... it ain't easy.

Logarithmic:
"Hard to pick up, easy to get pretty good at"

Example:
Water skiing.  It's not the most relatable thing.  If you've done it, you know that the hardest part is getting your butt out of the water to a standing position for more than 3 seconds.  I've seen people spend hours and hours getting pulled up, then flopping.  Get pulled up, wipe out.  Get pulled up, eat it.  It's pretty hilarious.  And by "I've seen people" I mean "I've been people."  But once you can consistently get out of the water, skiing itself, going outside the wake, that stuff isn't all that tough.  For this example, let's ignore how hard it is to get to the level of a pro.

Linear:

The more time you put into it, you just keep getting better.

Example:

Boy, this is a hard one.  I think whatever I say, people will challenge, so I'll say playing guitar.  It'll take about an hour for someone to learn the chords G, C, and D and they'll be able play dozens of songs, many of which are songs everyone knows.  Developing your barre chords takes some work.  Learning scales takes more.  Being able to improvise a solo takes more.  Being able to solo in D flat mixolydian in 7:4 takes even more.  There's always another hill to climb, but with dedication, you can do it.

Scaling:

In many systems, scaling up can be pose some of the biggest challenges you'll face.  Let's take a few real-world examples of scaling where these curves might apply.

Linear:

The more you add, it just keeps getting more difficult about how you'd expect.

Example: 

Chopping wood.  

If you have 100 logs to chop, maybe it'll take you an hour.  If you double the number of logs, you double the time.

Exponential:
You add a little it might be ok, you add more it's difficult, you add even more it's nearly impossible.

Example:
Making a reservation at a restaurant.
You have 4 people, not a big deal.  You have 10 people, ok that'll take some time - you should call ahead and they might have to rearrange the tables when you get there.  You have 30 people, you should definitely call ahead, some places might make you pay extra for a private room, and some places will tell you not to come.

Logarithmic:
You add some and it gets difficult pretty fast, but then you keep adding more and it's really not much harder.  Or, at first it's hard but as you add more, even a lot more, it's not much harder.

Example:
I had a hard time coming up with an example for this.  I guess the most obvious would be something that takes a lot of setup, but then isn't that hard to actually do, or after the setup, the work gets easier.  This example doesn't feel as good as the others, but I'll go with automation.

The linear example was chopping wood, and when you double the wood, you double the work.  If you decided to build a wood chopper, getting that very first log chopped would take a huge amount of work because you have to design and build the machine for that first long.  But once the machine is operational, just feeding some logs into the hopper just takes a little bit of work.

Final Note:

I appreciate correct use of English.  That's why I get frustrated when people say something like "the Titanic is exponentially bigger than that sailboat over ther."  Actually, it may be linearly bigger, it depends on the data points between those 2 objects.

If you only have 2 data points, it is not possible to know what the relationship is between them, i.e. what the curve they lie on looks like.  The graph below illustrates this: based on different functions, the 2 data points could have a linear relationship or an exponential relationship.

*Thank you graphsketch.com
**When I took physics 1, it really annoyed me that they hadn't give us examples in calculus, because it made it so clear.  Memorizing formulas without context is a waste of time.

Language: Precision vs Accuracy

Motivation

People conflate these words but they are distinct, and I think the distinction is both useful and kind of cool.

In short:

Precision: the degree of refinement with which an operation is performed or a measurement is stated

Accuracy: correctness

Precision has to do with specificity, not necessarily correctness.  Accuracy is all about correctness.

Example 1:

If I said 1 foot is 492.763 millimeters, I would have given you a very precise but inaccurate number.

If I said 1 foot is about 300 millimeters, I would have given you an imprecise, but reasonably accurate approximation.

If I said 1 foot is 304.8 millimeters, I would have given you a precise and accurate number.

Example 2:

If I said the Texas State Capitol building was at latitude/longitude 30.276930, -97.7441325 I have given you a very precise location, but it's not accurate.  It's not correct.  In fact, it's cosmetic surgeon's office.  Notice the red pin in the upper-left:

If I said the Texas State Capitol building was at latitude/longitude 30.275, -97.74 I have given you an accurate location, but the GPS coordinates are of low precision, having only a couple of digits after the decimal place.

If I said the Texas State Capitol building was at latitude/longitude 30.2746742, -97.740345 I have given you accurate, highly precise coordinates for the center of the capitol rotunda.  If you sing in there, it sounds REALLY cool.  It's virtually all marble and granite, so the acoustics are incredible!

QA Strategy: Things a Developer Can Work on During the End of the Sprint

Motivation

I call this QA Strategy because sometimes QA has to fight the battle of preventing development from "getting ahead" or as I'd call it, "violating core agile principles."  One place I worked, everyone seemed ok with having sprint planning on the Friday at the end of the sprint, even if QA was still working on current sprint... a battle I lost.  The devs were apparently not creative enough to come up with things they could do to help the team/project/company that didn't involve writing application code.  Not that it made me bitter or anything.

Ideas

Roughly in the order of what I'd request if I was the QA manager

1. Testing
1. ...other devs' code of course
2. Helping QA do their testing
3. Helping with automation (but not preventing QA from learning/doing automation)
2. Prepping your demo (if devs do demos)
3. Documentation
1. Code comments
2. Documenting features on the wiki
3. Organizing / maintaining the wiki
4. Writing unit tests
1. Should be done in-sprint prior to giving to QA, but sometimes this doesn't happen
2. Backfilling unit tests for old code
3. Fixing old broken unit tests (let's be real)
5. Writing in-house tools
1. Integrations to things like Jira, cloud tools, analytics tools, etc.
2. CI/CD tools
3. (Test) data creation tools...
6. Knowledge sharing
1. Silo busting with other developers
2. Training other groups in the organization (account managers, support center staff, sales team)
3. Learning from other groups in the organization (account managers, support center staff, sales team)
4. Mentoring junior devs
5. Mentoring people from other groups in the org who want to be devs
7. Learning new skills
8. Simple refactoring

Language: Necessary and Sufficient

Motivation

This is a nice piece of language I learned in school long, long ago.  It's very useful when talking about requirements or specifications for a project, acceptance criteria for a user story, etc.  Bonus: it makes you sound smart.

Example

The long and short of it is that what you want in order to work efficiently and effectively is the necessary and sufficient information (or tools or whatever).  Since I like working on cars, I'll use the simple example of changing a tire.

If you have the following, you have the necessary and sufficient toolset:

• a new tire
• a lug wrench
• a car jack

If you have the following, you have tools that are necessary, but not sufficient:

• a new tire

If you have the following, you have tools that are sufficient, but not necessary:

• a new tire
• a lug wrench
• a car jack
• a hammer

If you have the following, you have tools that are not necessary, and not sufficient:

• a hammer

Recap

Necessary defines the lower bounds of what you need while sufficient defines the upper bounds.  If you have both, you have the ability to do the work completely while being perfectly efficient.

Email: Changes to Automation That Fix TestA but Break TestB

Summary

As our Selenium automation team grew, it began to feel like we might be fighting with each other over element locators and library methods.  To try to avoid this, I recommended we look at git annotations while making these little code changes.

--------------------------------------------------------------------------

Team,

I was just going to send this to Andy and Victor, but it might be useful to more of us as more people contribute to the same codebase.  Hopefully this will be a helpful strategy to prevent us from breaking one test while fixing another.

This came to mind when I saw Victor's comment on a pull request:

Victor said "I will check all occurrences again."  This could take a lot of time, and sometimes it will be very difficult to even determine all the tests that use a certain library method or page element.

These little changes are at the front of our minds in OMS since we're going to be executing and re-executing over and over, trying to get tests to run consistently, fixing the little things that are breaking our tests.  In the example above, if 2 tests use the page element that Victor is changing, it's very possible that the locator is actually different in the scenarios in those 2 tests.  I think a good way to avoid fixing testA but breaking testB is to view Annotations in IntelliJ.  Just right-click in the gutter between the line numbers and the code area and choose Annotate:

If I were changing one of these page elements that was last updated several months ago, I would feel pretty confident that my change wasn't going to break any other tests.  But if the last changed date was a couple weeks ago, then I should ask that person, or just look at that commit.  IntelliJ makes that very easy too – just right click on the date or the person's name and choose Show Diff:

If you want to see their git commit message (this is why we write good commit messages!), you can just hover over the date or person's name, or from the menu above, select Select in Git Log.

This won't work all the time, but it should keep us from thrashing – where one person fixes testA, breaking testB, and then someone else fixes testB, breaking testA.

If anyone else has bright ideas on this, feel free to share them here...

Information Science: What do Digital and Analog Mean? It's Fairly Simple Really...

Motivation

People frequently use the word "digital" to describe anything that's modern.  It means something specific, and it's pretty easy to learn.  And learning is cooool.

"Digital"

In modern society, "digital" is often used in non-scientific ways from "digital music" to vague sentiments like "the Digital Age."  Digital and analog have simple meanings, and neither has anything to do with computers.  Digital simply means you're using a set of values that you know the exact values of.  In computers, that set of values is 0 and 1.  It is a discrete set of values.

"Analog"

Analog simply means you're using the full, continuous range all values between your minimum and maximum.  There are an infinite number of values between 0 and 1.  For example, 0.5 and 0.6.  But I can "go between" these numbers with the value 0.55.  and I can "go between" 0.55 and 0.6 with 0.575.  I can keep doing this infinitely.  Analog systems do not measure, track or store discrete values.

Examples

The simplest example of this I can think of involves musical instruments.

Imagine a trombone: you can play an E by holding the slide in a certain position.  To play an F, you move the slide a little closer in, but if you move it a little less than you should, you're between the two notes.  Since you're not playing an E or an F, it's probably going to sound bad because you'll be flat.  You can play an E and an F, but you can also play the full, infinite range of pitches between those 2 notes.

On piano however, you press the E key, you get an E, you press the F, you get an F.  You cannot play the pitches between those notes.  That's nice because it's one less thing to worry about... but you also can't play the "womp womp" sound.

The trombone is analog and the piano is digital.

A few more quick examples are a full-on rainbow, versus a simple rainbow:

And slider belt versus a belt with holes:

The Physical Medium vs How It's Used

In the case of the belts above, you might notice something: The "digital" belt with the holes cannot be used in an "analog" way.  The "analog" belt however... if you used white paint to make lines on it every inch or so, and you chose to only use the belt at those increments, you would effectively be using the "analog" slider belt in a "digital" way.  In fact this is true of cassette tapes (think 1980s).  Cassette tapes were primarily used to store music, for example MC Hammer's "Too Legit to Quit," but they were also used in computer systems (Atari, Commodore, etc.) to store binary (digital) data.

I used them some in the 80s and was surprised how well they worked.  I'm guessing the error rates on these tapes wasn't too bad because with binary data, only having 2 values to represent meant you could make it pretty clear which was which.  It wasn't like playing an E versus an F on a piano (most humans couldn't tell you which was which) it was probably more like playing the very lowest note on a piano versus the very highest (most humans could easily tell you which was which).

Digital as "Better"

The reason people think of digital as better than analog is because you can make a perfect copy of it.  A cassette tape with music on it is analog.  If you recall, every time you made a copy of one, the quality deteriorated a little.  If you made a copy of your friend's tape, then another friend made a copy of your copy, it sounded noticeably worse than the original.  An analogy for modern times might be if you take a picture with your phone, and then someone takes a picture of your phone's screen, and then someone else takes a picture of their phone's screen.  That 3rd picture's not going to look too good.

If you made copies with a low quality tape recorder vs a higher quality one, it made a difference.  It might even make a difference if you made the copy in a room that was really hot or humid.  This is because the data on the tape was analog, and the tape recorder reading that tape is not precise enough to read the data exactly.  In the same way, while the best trombone player in the world is very very close to hitting that E on their instrument, their finger placement will probably actually be sharp or flat by at least a nanometer or two...

However, if you make a copy of a music CD, you can make a copy of that copy, and a copy of that copy, etc. and it will be an exact copy of the original.  The original and all of the copies are perfectly identical.  The modern analogy would of course be just emailing the picture to your friend so that they have a copy.

Why We Care

Basically, it's simply much easier to make an exact copy of something that is stored using discrete values.  For computers to execute computer programs exactly the same way every time, digital is the way to go.  Most of the time, when a program crashes or doesn't do what you want, it's not running it wrong.  It's running the program - with all of its bugs - exactly as it was written.