Michael Norton (Doc) is a software delivery professional working to make the world of software development a better place. His experience covers a wide range of development topics. Doc declares expertise in no single language or methodology and is immediately suspicious of anyone who declares such expertise. A frequent speaker, Doc is passionate about helping others become better developers, working with teams to improve delivery, and building great organizations.

In Chapter 9, Martin covers unit tests. In listings 9-3 and 9-4, Martin shows the "simplification" of a unit test. Listing 9-3 makes two method calls followed by five assertions. Each assertion checks a specific state. Each state is clearly identified. I do not particularly like the five assertions. But this is not the point that Bob makes. This is not the correction he covers. Instead, he condenses all five assertions into a single assertion by introducing a string of seemingly arbitrary characters.

He goes on to explain that each character in our string represents a possible state; Capital is true, Lower is false. He follows up with, "Notice, once you know the meaning, your eyes glide across that string and you can quickly interpret the results. Reading the test becomes almost a pleasure."

WHAT?

"Once you know the meaning"? This is not from a solution domain. This is not from the problem domain. This removes clarity under the guise of improved readability. How, pray tell, am I to know the meaning? Is there a comment in the code to explain the meaning? Is he really suggesting that a blatant code smell is better than methods that clearly indicate the intended behavior? And what happens when getState needs to also return the humidifier State? How much code breaks? I should be able to introduce a new behavior without these issues.

I have to disagree with Uncle Bob on this one. This is NOT a better solution. It does NOT make the code more readable. I am suprised to see this recommendation and I bet it does not appear in the Second Edition.

Break each assertion out into their own test within the class, put them all into their own test class with a shared setup and tear-down, or use a Template Method pattern. Frankly, you could just leave them all in a single test given they all test the same single concept. But this string of place-holders with case representing on or off state is a fart in a garden of beautiful code. It just smells bad.

In this post, we are going to cover a very simple way to implement authentication in your application. This is not an appropriate technique for securing a commercial application in production. I use this technique to quickly "secure" an application while in User Acceptance. It allows me to put the application out on the internet and give it a single user name and password. This technique can also be used for easy REST authentication.

Let's assume your intention is to secure the entire application. Add the following to your application controller:

I encourage you to read both articles along with the comments attached to each.

In McConnell's article was a paragraph that made me stop and think for a bit:

"Another factor is that, while numerous studies have found 10x differences among individuals, researchers have not found 10-fold differences among programmers working within the same organizations. Some research has found that good programmers tend to cluster within certain companies, average programmers tend to cluster within other companies, and so on (Mills 1983). So even if there’s a 10x difference industrywide, the difference you’d typically see within a given company is more like 3-5x from best to worst, which means the difference from best to average is more like 1.5x or 2x within any given company."

So which company am I in and with whom have I clustered? What about you?

I can say with certainty that I've spent some time at the bottom of the scale. Rallying against not only the organization as a whole, but against the fear and apathy of my own team. Clustered they had. And they settled in an environment that supported them. I posit to you - should you ever find yourself in this situation, it is far easier to change your circumstance that it is to change an organization. I should have left far sooner than I did.

Today, I find myself surrounded by wonderful, talented, people. I suspect I pull down the multiplier, but I aspire to be one of them. And the best way I know to improve yourself is to surround yourself with people who are much better than you. People who can push you, challenge you, and teach you. It worked for me as a musician. It worked for me as a runner. I am certain it will work for me as a software developer.

Look around. What end of the multiplier do you think you are on in your current organization? And are you clustered with the top, middle, or bottom of the scale?