Avoiding Herd Mentality by Asking “Why?”

My two-year-old daughter is in a phase of her development where she questions everything she  doesn’t understand. She throws questions at us faster than a 90mph curve ball. I’ll admit there are times where the incessant “why is this blue?” and “why did you open the bottle?” become hard to tolerate but this is an important stage of her development which we really need to encourage and not suppress.

You see, her search for deeper understanding of things is helping to build her internal decision-making engine. She’ll be able to make better choices once she understands “the why”. I guess this is something that I learned from my father who would hammer this point to me over and over again, “If you don’t know why you’re doing something, then there is a strong likely hood that you’re making a bad choice”.

 

 

The field of social psychology presents us with a very potent example. Soccer fans often breakout into fights before games for the most silliest reasons. What originally started as a misunderstanding between between two opposing fans might turn into a big riot. Why? Because people just jumped into the fight without understanding why they were even fighting. In psychology this is known as mob psychology or herd mentality.

As developers, we’re faced with similar but different choices. When you get that dream job you’ve been waiting for you’re whole life and you’re asked to build  a new feature, we often don’t question why things are being done the way they are and jump in head first. Let’s be honest, it’s easy to follow existing conventions without asking questions.

The problem with this approach is that, we become like soccer fans who start vandalizing existing structures without understanding why they’re doing it in the first place.

Questioning or seeking deeper understanding from your colleague,manager,wife or friend can sometimes come across as being rude or even disrespectful. When I first began my career I used to harbor feelings of animosity toward our team lead who would incessantly question my code choices. I later learned how beneficial this was in being able to make better choices.

Developing complex applications will always present tough challenges and choices. However, understanding why you’re choosing one development approach as opposed to another will definitely go a long way to enhance your chances of success. In code reviews it’s important that we not follow a “herd mentality” way of thinking and simple nod our heads. We must question and seek clarity in order to drive us on the path to success.

Guidelines for unit testing

Have you ever wondered what it takes to build a commercial Jet? It often blows my mind to think of the hours engineers spend assembling components together to build the plane. Interestingly enough there are similarities between building software and assembling planes. The individual units for each part of the software application or plane must be thoroughly tested to ensure the overall functionality of the app or plane. The testing of these units is what has become known as unit testing.

Unit testing requires you to test the functionality of individual units/parts/sections of your application in isolation. Testing in isolation ensures that you can confidently pinpoint bugs in code and verify that they have been fixed.

Phases of a Test – Arrange, Act, Assert

There are 3 generally accepted phases for any unit test.

The Arrange phase, is where you create an instance of the class you need to test and also setup up the initial state of any objects. The Act phase, requires you to call the functionality that represents the behavior being tested. Lastly, the Assert phase is where you check what actually happened was expected.

Tips for writing good unit tests?

The primary objective of unit tests is to prove correctness and you can do that by following these simple guidelines.

Prove a contract has been implemented

This is the most basic form of unit testing which verifies that the contract between the caller and method is being adhered to. For example this test validates a driver’s license number . Verifying that a method implements a contract is one of the weakest unit tests one can write.

[Test]
public void ShouldBeValidWhen8DigitsAndStartsWithLetter()
{
var sut = new DriversLicenseValidator();
const string driversLicenseNumber = "A5522123";
Assert.That(sut.IsValid(driversLicenseNumber), Is.True);
}

Verify Computation Results

A stronger unit test involves verifying that the computation is correct. It is useful to categorize your methods into one of the two forms of computation:

  • Data Reduction: occurs when a test accepts multiple inputs and reduces to one resulting output. For example, the verify division test accepts 2 parameters and returns a single output.
  • [Test] public void VerifyDivisionTest()
    {
    Assert.IsTrue(Divide(6, 2) == 3, "6/2 should equal 3!"); 
    }
  • Data Transformation : These tests operate on sets of values

Establish a method correctly handles an external exception

When your code connects to an external service, it is important to determine that your code will handle exceptions gracefully. Attempting to get an external service to throw a specific error is tricky and so the use of Mocking tools will help in this process.

Prove a Bug is Re-creatable

Tests should be repeatable in any environment. They should be able to run in production, QA or even on the bus.

Write positive and negative tests :

Negative tests prove that something is repeatedly not working.They are important in understanding the problem and the solution .Positive tests prove that the problem has been fixed. They are important not only to verify the solution, but also for repeating the test whenever a change is made. Unit testing plays an important role when it comes to regression testing.

[TestMethod] 
[ExpectedException(typeof(ArgumentOutOfRangeException))] 
public void BadParameterTest() 
{ 
    Divide(5, 0);
}

Verify Tests are independent:

Tests should not depend on each other. On test should not set up the conditions for the next test.

These simple guidelines will set you off on the journey of unit testing. Feel free to share any ideas you might have stumbled on.

Breaking down Interfaces

I often hear heated debates between developers about the usage of interfaces. Unfortunately, many of these debates are skewed toward the personal preferences of developers who fail to understand what an interface is and what it does.

So let me use a couple of minutes to break it down for you…..

Take a Digital Video interface (DVI) port, which is used to connect a computer and a display device. The DVI port doesn’t need to know whether the display device is a Samsung flat screen monitor or Acer LCD monitor.Neither does it need to know how the Samsung monitor will connect internally to the computer. All the interface provides is a means of connecting any computer to any display device. Essentially, it says “Hey Computer, connect to this monitor” and ‘Hey Presto!’ they’re connected.

In the realm of programming, an interface does exactly the same thing. It provides a way for objects to interact without each object having to specify the inner details of how they intend to interact with another object. Here is a brief summary of the role of an interace

  • An interface allows us to separate the usage of something from how it is implemented
  • Interfaces are like contracts which define what operations should be performed
  • An interface constitutes a declaration about intentions
Benefits of Interfaces
  • Code readability: Using interfaces will improve your code readability because you’re interfaces will define and state your intentions. If you implement ISortable you’re clearly stating that your class can be sorted, same for IRenderable or IConvertible.
  • Code Semantics: By providing interfaces and implementing them you’re actively separating concepts in a similar way HTML and CSS does
  • Code maintainability: Interfaces helps to reduce coupling and therefore allow you to easily interchange implementations for the same concept without the underlying code being affected
Things you should know
  • A class can implement multiple interfaces
  • Interface members are all implicitly abstract
  • An interface can contain only methods, properties, events and indexers
Example

In this example, we define a very simple interface called IConnectable. IConnectable defines a new contract which states that any class which implements me must define a method called connect. In a real world application, the connect method in the Lenovo and series9 objects would then provide the necessary details about how to connect.

namespace InterfaceExample
{
      public interface IConnectable
      {
            void Connect();
      }
 
      public class Computer : IConnectable
      {
            public void Connect()
            {
 
                  Console.WriteLine("I can connect to any display device attached to me");
            }
      }
      public class SamsungMonitor : IConnectable
      {
            public void Connect()
            {
                  Console.WriteLine("I can connect to any Computer attached to me");
            }
      }
 
      class Program
      {
            static void Main(string[] args)
            {
                  Computer lenovo = new Computer();
                  SamsungMonitor series9 = new SamsungMonitor();
 
                  lenovo.Connect();
                  series9.Connect();
 
                  Console.Read();
 
            }
      }
}