Gaming Unit Test Metrics

Unit Testing is a popular buzzword - most developer jobs request it, teams want to say they have it, and most coding leaders actively endorse it. However, you won't be able to hire a team of devs who don't want to write unit tests, and then "force" them via measuring certain metrics. Developers can game metrics.

1. Metric: Code Coverage
The #1 unit testing metric is code coverage, and this is a good metric, but it's insufficient. For example, a single regular expression to validate an email could require many different tests - but a single test will give it 100% code coverage. Likewise, you could leverage a mocking framework to artificially get high code coverage by mocking out all the "real" code, and essentially having a bunch of "x = x".

2. Metric: Number of unit tests
Sure, everything being equal, 10 tests probably does more work than just 1 test, but everything is not equal. Developer style and the code-being-tested both vary. One dev may write a single test with 10 asserts, another dev may put each of those asserts in its own test. Also, you could have many tests that are useless because they're checking for the "wrong" thing or are essentially duplicates of each other.

3. Metric: % of tests passing
If you have a million LOC with merely 5 unit tests, having 100% tests passing because all 5 pass is meaningless.

4. Metric: Having X tests for every Y lines of code
A general rule of thumb is to have X unit tests (or X lines of unit testing code) for every Y lines of code. However, LOC does not indicate good code. Someone could write bloated unit test code ("copy and paste"), so this could be very misleading.

5. Metric: How long it takes for unit tests to run
"We have 5 hours of tests running, so it must be doing something!". Ignore for the moment that such long-running tests are no longer really "unit" tests, but rather integration tests. These could be taking a long time because they're redundant (loop through every of a 1 GB file), or extensively hitting external machines such that it's really testing network access to a database rather than business logic.

6. Metric: Having unit testing on the project plan
"We have unit testing as an explicit project task, so we must be getting good unit tests out of it!" Ignore for the moment that unit tests should be done hand-in-hand with development as opposed to a separate task - merely having tests as an explicit task doesn't mean it's actually going to be used for that.

7. Metric: Having high test counts on methods with high cyclometric complexity
This is useful, but it boils down to code coverage (see above) - i.e. find the method with high complexity, and then track that method's code coverage.

Conclusion
Obviously a combo of these metrics would drastically help track unit test progress. If you have at least N% code coverage, with X tests for every Y lines of code, and they all pass - it's better than nothing. But fundamentally the best way to get good tests is by having developers who intrinsically value unit testing, and would write the tests not because management is "forcing" them with metrics, but because unit tests are intrinsically valuable.

Writing tip: Concise language

You are "paying" for each word, and if your idea is too expensive to communicate, it will never be heard - let alone implemented. Therefore it's imperative that developers have good writing skills if they want to become influential. One metric of good writing is that it is concise. Here is a brainstorm of tips.

Tip: Remove un-needed words and phrases

If the word adds zero value, then remove it.

//Remove "Anything about"

Anything about schemas will drive architecture.
Schema will drive architecture.

//Remove phrase "my approach"
I’ll need to confirm my approach with Bob
I’ll need to confirm with Bob

//Restructure sentence to remove the word "it"

It takes effort to ask for something.
Asking for something takes effort.

Tip: The word is implied, so you don't need it.

//Implied that you're concerned, which is why you're talking about it

My concern is that X is bad.
X is bad

//The word "something" is implied

If there’s something more to it.
If there's more to it.

//The word "about" is implied by estimate, and the number being rounded
We estimate the list to have about 10,000 rows.
We estimate the list to have 10,000 rows.

//The phrase "Ed mentioned" implies "Discussing with Ed"

Discussing with Ed yesterday, he mentioned that...
Ed mentioned yesterday that...

Tip: remove duplicate words

Sometimes people use duplicate words. Maybe because (1) they think it drives the point home, (2)
they feel like it has to be long (schools trained them to write "at least 500 words"), (3) they
can't think of a single word to describe both sub-words.

//Just pick one - either "harsh" or "ruthless"

The production environment is harsh and ruthless
The production environment is ruthless

Tip: Replace a phase with a single word

Sometimes a big phrase can be replaced with a single word because that single word is the definition of the big phrase.

//Replace the entire phrase with one word that means the same thing

The application must be able to handle an increasing amount of demand.
The application  must be scalable.

Tip: Condense two sentences into one

//Remove a descriptive sentence by applying it to the noun directly.
I'd like to set up a call. An hour should be enough time.
I'd like to set up a one-hour call.

Tip: Avoid un-needed commas

If you have a bunch of small phrases joined by multiple commas, consider restructuring it into a single sentence. Even if it doesn't make it more concise, it will probably make it easier to read.

//Remove comma
and for each line, trims it.
and trims each line.

//Merge two short sentences into 1:
We are creating a custom list. It will have 1000 rows.
We are creating a custom list containing 1000 rows.
 

//Restructure sentence

Yesterday, Ed mentioned that...
Ed mentioned yesterday that...
 

//Restructure sentence

If you approve of this design, please let me know.
Please let me know if you approve of this design.

Writing tip: Avoid abstract words

We all know that influential developers need good communication skills. I love technology, but if you can't communicate your technical ideas to your coworkers, then they won't be adopted.

You need to be concise, else people will just tune you out. One way to do that is to choose a more descriptive work that packs more meaning.  Your word count remains about the same - it's absolutely not just rambling on - but the sentence caries more meaning.

Of course sometimes you deliberately want the more abstract word, but it's good to be aware of the more-descriptive alternatives so that you can make a conscious choice of what's best for the situation.

Weak word	Comment	Consider Instead	Example
Do, Does	Does what?	create, build, make, install	Bob does builds Bob installs builds
Run	What does the "running" do?	scrubs, cleans, updates, processes, installs, configures	The service runs on the directory The service cleans the directory
Change	How does it change?	insert, update, delete, improves	The tool changes the file The tool updates the file
Processor	What does the process do?	copier, uploader	FileProcessor tool FileUploader tool
It, Object, Thing	What kind of thing?	C# class, SQL script, COM+ object	It runs fast. The C# class runs fast
Talk	What kind of talking?	discussed, reasoned, concluded, negotiated, argued, explained	Bob talked about structs Bob explained structs
Issue	What kind of issue?	bug, feature request, task, problem	This is an issue This is an error
Other	In what way?	previous, next, remaining, bigger, smaller	I need the other node I need the previous node
Good	In what sense?	faster, more reliable, higher revenue	This feature is good This feature is faster
People	What kind of person?	manager, employee, developer, analyst, users	People will like this feature Managers will like this feature
Sent	How?	FTPd, emailed, faxed	I sent the files I emailed the files

They should not complain if...

Every project and team always has issues. I'm a big fan of making things better. No one wants to hear complaining (not to be confused with constructive criticism or a call for action). Here's a brain dump of when people should not complain:

• They don't have a better alternative
• They can't specify what the actual problem is (saying "something seems wrong, but I don't know exactly what" isn't complaining)
• If their manager asks "what can I do", and they can't tell them
• They caused the problem
• They were warned, and did it anyway
   

Migrating blog

I've officially migrated my blog from .Net Developer's Journal (http://www.timstall.dotnetdevelopersjournal.com/) to my own domain - http://www.timstall.com/. .NDJ dropped their blogs, so it was inevidable.

It was an interesting technical adventure - I decided to use blogger based on some friend's recommendations, and was pleased with their API - it just worked:
http://code.google.com/apis/blogger/docs/2.0/developers_guide_dotnet.html#CreatingPublicEntries

I was able to set titles, publish dates, suggested Urls, and even dynamically add categories.
I could then write a simple app that posts 40+ entries a day (Blogger only allows a certain limit, so I couldn't do all 500 posts in an hour), so I made the migration tool run over several days.

[UPDATE] I added a page: http://www.timstall.com/p/timstalldotnetdevelopersjournalcom.html to help redirect traffic.

How does a techie know when they're learning the business?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_does_a_techie_know_when_theyre_learning_the_business.htm]

Obviously there's a gradual scale, but here's a brain dump:

• You can talk to a non-tech person without using tech speak (Your business skills are strong enough that you don't need to "hide" behind your tech skills to bail you out).
• You can list at least three industry-specific success metrics (besides standards like "revenue" and "profit").
• You can use business decisions as a "tie-breaker" between technologies.
• You can prioritize features and defend your reasoning.
• You know why your CEO or supervisor is upset.
• You know where your revenue comes from, and how it flows through the company’s various systems and departments. Looking at the production database (that records transactions), you can make an educated guess if this year was financially better than last year.
• You can read the year-end report.
• When a new boundary case comes up in the code, you can make an educated guess before verifying with the business analyst. Then you send the business analyst (BA) an email like "I think it's X because of A and B, would that be right?", and the BA can just reply with a "yes" instead of a detailed email correcting all your concepts.

Secrets to Winning at Office Politics - Part 2

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/secrets_to_winning_at_office_politics__part_2.htm]

Following up on my previous post, here are several good quotes from the other chapters of the very good book, Secrets to Winning at Office Politics.

Chapter 4: Political Psych 101: Allies and Adversaries

• "Positive relationships build political capital." (pg. 53)
• "Allies can be grouped into three categories: Friends, Partners, and Connections." (pg. 55)
• "colleagues usually judge your personality and your competence separately." (pg. 55)
• "Those who loudly complain that 'it's who you know' are usually the same ones who never take the initiatives to get to know anyone." (pg. 59) --> as an introverted hermit, this hits home with me.
• "adversaries fall into three groups: focused, emotional, and vengeful" (pg. 63) --> you want to be aware that someone who seems adversarial because they're just focused on their goal is not necessarily out to get you personally.
• " is not an adversary - [they're] simply a difficult person." (pg. 67)
• "Usually, the most effective containment strategy [with adversaries] is to increase your leverage." (pg. 68)

Chapter 5: Political Games: Moves and Countermoves

• "Political games re played for emotional rewards" (pg. 83)
• "Political game players always have a socially acceptable explanation for everything they do." (pg. 83)

Chapter 6: How to commit political suicide

• "If you want to commit political suicide, simply start engaging in any behavior that consumes a disproportionate share of management's time and attention." (pg. 107)
• "Once people arrive at a conclusion, they unconsciously continue to gather evidence that supports their opinion." (pg. 109)
• "There are four common causes of career destruction: (1) poorly controlled emotions, (2) a victim mentality, (3) self-centered foals; and (4) foolish reactions to change." (pg. 110)
• "Many political suicides are so caught up in their own concerns or delusions that when the ax falls, they are totally shocked." (pg. 121)
• "It's a heckuva lot easier to blame somebody else." (pg. 123)
• "if your colleagues are happily  and productively engaged while you're fuming with rage, then you need to take a closer look at yourself." (pg. 124)
• "When someone indicates that your behavior is a problem, don't automatically reject that possibility." (pg. 126)
• "When you are trying to recast your image, remember that others will not immediately notice the change in your behavior. If you're waiting for the applause, it may seem awfully quiet for a while." (pg. 127)
• "if you're not the problem, but people think you are, the political effect is unfortunately the same." (pg. 127)

Chapter 7: Power, Power, Who has the Power?

• Don't confuse "power" with "authority".
• "... any strength, carried too far, becomes a weakness." (pg. 137)
• "Here are some questions to consider in determining a person's power level: ... Do they talk more about the past or the future? ... Who can they go see without an appointment? ..." (pg. 137)
• "Some timid souls, fearing that they will be perceived as pushy, overbearing, or insensitive, simply give their power away." (pg. 138)
• "If you want to look ridiculous, just try using power that you don't have." (pg. 140)
• On pg. 147, the author presents a 2x2 "Power Grid":
  • High level of position and high degree of influence --> Power Players
  • High level of position and low degree of influence --> Empty suits
  • Low level of position and high degree of influence --> Persuaders
  • Low level of position and low degree of influence --> Weaklings
• "An organization's culture is largely determined by the beliefs, values, and preferences of the Power Elite... you must adjust to the culture established by the reigning Power Elite. There is not one chance in a million that you are going to change it." (pg. 149)