Continuous Integration Is Not an Option

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. […]CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests in the developer’s local environment and verifying they all passed before committing to the mainline. This helps avoid one developer’s work-in-progress breaking another developer’s copy. If necessary, partially complete features can be disabled before committing using feature toggles.”

http://en.wikipedia.org/wiki/Continuous_integration

One of my favorite questions to ask other software engineers and project managers is, “How do you implement continuous integration where you work?” The answers usually vary based on specific tools and technologies, but they fall into two categories. The first category includes a list that includes most or all of the following:

  1. An issue tracking tool.
  2. A tool to handle revision control.
  3. A code review process or some way to bless what gets merged to the mainline.
  4. A continuous integration server that …
    1. Automatically builds the solution at every commit.
    2. Automatically runs the unit tests on the completed build
  5. An improvement to the automation to building and testing the solution by automating deployment of the artifacts of compilation.
  6. An improvement to the automated deployment process by deploying to a simulated production environment for testing.

(Note: in my opinion, if you don’t have at least 1-4 implemented, you’ll have to argue pretty hard that you have implemented continuous integration at all.)

The second category of answers is simply the phrase, “We haven’t found a need for continuous integration yet.” My response to this is to quietly stare at them, wide eyed, hoping that they will follow up with, “but we have full intentions to implement some sort of continuous integration by X date.” This unfortunately never happens and, as the uncomfortable silence continues, I awkwardly back away into the shadows in an attempt to avoid association with these fools.

The interesting part of this equation is that most everyone understands that numbers 1-3 in the list above are necessary. Not only that, but those who haven’t implemented numbers 1-3 are looked down upon and most developers run far away from any job with an organization that doesn’t track issues, use revision control, or participate in peer code reviews. I wonder at times why some still think that the step up to 4 is so difficult. Perhaps it is similar to the aversion to process that Kate Heddleston describes in her article “The Null Process.” She says, “When people say they don’t want process, what they’re really saying is they don’t want formalized process. There really is no such thing as ‘no process.’ A process is simply the steps it takes to complete a task, so if a task is completed then by definition a process was used.” Maybe continuous integration is too much of a formalized process for some to handle, so they implement what Heddleston calls a “null process” instead of the highly formalized continuous integration process. In the end each and every development team performs the same functions before deployment. Code still needs to be merged, built, tested and deployed. The difference here is whether it is automatic and on every commit, or once every time the team deploys to production.

The step to get to number 4 from number 3 in the list is to set up a continuous integration server. My category two friends would probably retort, “That probably costs a pretty penny.” The only 2 continuous integration servers that I have heard being used in practice are Jenkins CI, which is open source, and Continuous Integration with Team Foundation Server, which you are probably already paying for if you develop on a Microsoft stack. The only investment that needs to be made to set up a continuous integration server is time. Even more impressive is that the investment is front-loaded. The time cost of a continuous integration server is mostly in the initial setup. Maintenance is minimal and for the most part you can forget that the server is there until a unit test fails or you want to adjust the process.

I cannot excuse foregoing a continuous integration server for many reasons. If the steps for integration are being executed manually, the integration cycles are most likely spread far apart and, because of the time between each cycle, are excruciatingly painful. If the code is compiled and tested at every commit, minor coding errors and bugs introduced by the commit can be handled quickly, right when they become part of the source, instead of at the list minute when the code should have been in production an hour ago. I have experienced this and too many concessions are made under these types of time constraints. Some of the worst development sins I have committed arose from exactly this situation. My other two reasons for running far away from those who have no plans to implement continuous integration are my biggest arguments for implementing this wondrous process. They are number 5 and 6 in my list above.

There is nothing more satisfying that having the ability to click one button and have a product that has been tested and is available to ship within an hour. Consider this scenario. Your project manager says that you need to ship by the end of the week. You click a button and within an hour you have deployed operational software to QA and they are testing it. 24-48 hours later QA blesses the current build. You click another button and an hour after that you have the production copy of the software ready for the client. This means that you have the rest of the week to focus on the next release. If you don’t believe me, check out what Reid Evans did over here. He set up his Jenkins CI server to do all the steps above with one button click.

If you are having trouble attracting the best candidates to you organization or even decent candidates to your organization, consider continuous integration as a practice that you should adopt. The best candidates will help you implement it, because to them continuous integration is not an option.

TL;DR – I will run far away from any job where, for whatever reason, Continuous Integration is not embraced as a key to the software development practices at that organization. The headaches avoided and the time saved by automating building, testing, and deploying the code are happily avoided by doing so.

Advertisements

Translating Unit Test Names Into Requirements With .NET Attributes

A good stance and posture reflect a proper state of mind.”
– Morehei Ueshiba

The application that I work on for my current employer is, for all intents and purposes, a legacy application with very little unit testing done on it. When I came onto the project, the majority of the functionality had been completed and it was my job, along with my colleagues, to shore it up and bring it to market. For that version of the software we relied heavily on the functional test plans defined by the project manager and QA. The software worked remarkably well given that our predecessors had only high level requirements to work with and did absolutely no unit testing.

Since that release, we have finished 3 maintenance releases and are now working on the first minor release. Over the interim we have added quite a few unit tests. Many of these were written as safety nets in order to ensure that functionality did not change as we fixed bugs, re-factored, and added new features. The practice of adding unit tests to cover current functionality and ensure we don’t break things as we move forward has had the side effect of revealing many of the lower level business requirements of the software. It became apparent that it would be useful to capture these requirements in the documentation of the software before the next release, so I was tasked with making a tool that would accomplish this task.

The unit test naming convention we use for all of our tests is a flavor of the Given-When-Then naming convention. This made it trivial to construct a small console application that would reflect on the test classes in the test libraries for our application and output a list of requirements. It did present 2 difficulties however:

  1. Many of the unit tests cover very technical requirements that shouldn’t be represented in the list of business requirements.
    (i.e. When_an_arg_is_null_then_an_argument_null_exception_is_thrown)
  2. Some of the test names were intentionally left ambiguous in order to avoid having to rename the test methods every time a requirement on some label changed.
    (i.e. When_some_string_label_is_used_then_it_meets_requirements)

Because I was already planning on using reflection to produce my list of requirements, .NET attributes were the prime candidate for resolving both the issues. Figuring out which tests define business requirements versus technical requirements is as easy as decorating each with a [TestCategory("Business Requirement")] or a [TestCategory("Technical Requirement")] attribute, respectively. Then the application can reflect on the [TestCategory()] attribute an behave appropriately based on the values in the TestCategories list.

In order to specify the value of the property that the unit tests are referring to when they are titled “[…] then_it_meets_requirements”, I created a custom method attribute like so:

    [AttributeUsage(AttributeTargets.Method)]
    public class RequirementValueAttribute : Attribute
    {
        private readonly object _requirementValue;

        public RequirementValueAttribute(object requirementValue)
        {
            _requirementValue = requirementValue;
        }

        public string GetRequirementValueAsString()
        {
            return _requirementValue as string;
        }

        public int GetRequirementValueAsInteger()
        {
            return (int)_requirementValue;
        }

        /.../
    }

This attribute can be used to decorate any test method that states there is a requirement and the backing field in the attribute can carry the specified value. For example, if the label for name in my application was required to be “Nombre”, then the attribute decorating the test for the name label would be [RequirementValue("Nombre")]. Likewise, if the requirement was that the value be integer 3, then the attribute decorating the test for the integer value would be [RequirementValue(3)].

Using this method to tell what the required value is has a nifty side effect. Reflection can be used inside the test method to retrieve the requirement from a common location which makes updating requirements in the unit tests super easy. The result would look something like this:

     [TestMethod]
     [RequirementValue("Nombre")]
     public void Then_the_name_label_meets_requirements()
     {
       var method = MethodBase.GetCurrentMethod();
       var attribute = (RequirementValueAttribute)method.GetCustomAttributes(typeof(RequirementValueAttribute), true)[0];
 
       var expectedNameLabel = attribute.GetRequirementValue();
       var actualNameLabel = MyClass.MyNameLabel.ToString();
 
       Assert.AreEqual(expectedNameLabel, actualNameLabel);
     }

Or, some other type of reflection could be used so that all the logic needed to extract the requirement value could be encapsulated; like my colleague suggested when he did this:

      public static class RequirementHelper
      {
        public static string GetRequirementValue()
        {
          var stackTrace = new StackTrace();
          var caller = stackTrace.GetFrame(1).GetMethod();

          var attribute =(RequirementValueAttribute)caller.GetCustomAttributes(typeof(RequirementValueAttribute), true)[0];

          return attribute.GetRequirementValueAsString();
        }
      }

This makes the previous example look like this:

     [TestMethod]
     [RequirementValue("Nombre")]
     public void Then_the_name_label_meets_requirements()
     {
       var actualNameLabel = MyClass.MyNameLabel.ToString();
 
       Assert.AreEqual(RequirementHelper.GetRequirementValue(), actualNameLabel);
     }

Updating Telerik Reports from Q1 2011 to Q2 2014

Instructors can impart only a fraction of the teaching. It is through your own devoted practice that the mysteries of the Art of Peace are brought to life.”
– Morihei Ueshiba

The company I work for uses Telerik reporting for report generation and Telerik WPF user controls for charting and other neat stuff as part of our development tools. This past week I had the great opportunity to upgrade the Telerik tool libraries from the Q1 2011 version to the tools to the Q2 2014 version.

The product manager had decided to forgo this update until it was absolutely necessary. It became vitally necessary when a new report was requested by a client and it was discovered that in order to use Telerik’s report designer in Visual Studio 2013 we would have to update the libraries for the tools. The good news was that we were on a support contract and Telerik provides an update wizard to do most of the work in updating assemblies.

If you need to update your Telerik libraries, then there are two ways this can work out for you. I’ll start with the best case scenario first.

Scenario 1: You are using Telerik’s tools straight out of the box.

If the project you are working on uses the Telerik tools right out of the box, or with minimal style changes by creating new styles based on the Telerik styles right out of the box, then your life has been made really simple by Telerik. In my case the project I am working on uses the Telerik WPF Windows Controls and Telerik Reporting. To update these all you need to do is follow these steps.

  1. Download and install the new version of the WPF controls.
  2. Download and install the new version of Telerik Reporting.
  3. Open Visual Studio and load the solution that you want to upgrade.
  4. Run the upgrade wizard for the WPF controls by following these steps or manually update the references and binding redirects for the WPF controls.
  5. Run the upgrade wizard for the Telerik Reporting libraries using these steps or manually update the references and binding redirects for the WPF controls.
  6. Since Telerik is moving toward implicit styling for their WPF controls add the following XAML files found in [INSTALLDIR]\Telerik\Reporting Q2 2014\Wpf\Themes to your solution.
    • System.Windows.xaml
    • Telerik.Windows.Controls.xaml
    • Telerik.Windows.Controls.Input.xaml
    • Telerik.Windows.Controls.Navigation.xaml
    • Telerik.ReportViewer.Wpf.xaml
  7. Merge these resource dictionaries at the APP level by adding the following to the Application.Resources section of your App.xaml file
   <Application.Resources>
    <ResourceDictionary>
      <ResourceDictionary.MergedDictionaries>
        <ResourceDictionary Source="/Themes/System.Windows.xaml"/>
        <ResourceDictionary Source="/Themes/Telerik.Windows.Controls.xaml"/>
        <ResourceDictionary Source="/Themes/Telerik.Windows.Controls.Input.xaml"/>
        <ResourceDictionary Source="/Themes/Telerik.Windows.Controls.Navigation.xaml"/>
        <ResourceDictionary Source="/Themes/Telerik.ReportViewer.Wpf.xaml"/>
      </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
  </Application.Resources>

Since everything else is out of the box you application should compile and run, albeit with a few other possible minor code changes.

Note: The method fro steps 6 and 7 were extracted from the article How to: Add report viewer to a WPF application.

Scenario 2: You have made significant style changes directly to one of the Telerik Templates

If you have made significant style changes directly to one of the Telerik templates, say for example the Report Viewer template, then may God have mercy on your soul. I cannot speak for any other templates you may have changed, but if you have changed the Report Viewer template in a version of Telerik reporting prior to Q1 2014, then the following bit may be useful to you. Before I go through the steps for upgrading your customized styles there are 5 bits of information that you should take away from this discussion.

  1. The style template for the report viewer is embedded in the Telerik.ReportViewer.Wpf.xaml file.
  2. The ReportViewerModel constructor was changed to an internal constructor between Q1 2011 and Q1 2013, so you can’t use it anymore if you were in the past.
  3. If you need access to the ReportViewerModel for any reason, you will have to wait until the ReportViewer Loaded event has occurred and then walk the visual tree down to the first child of the ReportViewer and cast its DataContext as a ReportViewerModel to retrieve it.
  4. If you bind any commands to the ReportViewer’s tool-bar, the PageScriollView will need to have focus.
  5. The newest ReportViewer implements a new ViewMode attribute that you can read more about here.

To upgrade in this scenario, use the following steps:

  1. Follow all the steps in scenario 1.
  2. Extract the style template for the ReportViewer from the Telerik.ReportViewer.Wpf.xaml file.
  3. Edit the extracted template to create the style you need for your application.
  4. If you need access to the ReportViewerModel for any reason, add a Loaded event handler to the ReportViewer and use the following code to get access to it:
    var layoutRoot = (FrameworkElement)VisualTreeHelper.GetChild(this.ReportViewer1, 0);
    var rvm = (ReportViewerModel)(layoutRoot.DataContext);
    
  5. If you have added command bindings to any of the ReportViewer button styles, add a Loaded event handler to the ReportViewer, or use the one created in the previous step if you did so, and add the following code:
    var scrollViewer = VisualHelperEx.FindVisualChildByName<ScrollViewer>(ReportViewer, "PageScrollViewer");
    scrollViewer.Focus();
    

With a few other possible minor code changes you should now be able to compile and run your code.

If you till are having issues, first, I am sorry, and second, stay calm and patient. Telerik’s documentation is not what it could be and it took me a week to get my styles to work. I hope my experience with this might help someone out there someday.

Let’s Talk About TDD

One should be prepared to receive ninety-nine percent of an enemy’s attack and stare death right in the face in order to illumine the Path.” – Morihei Ueshiba

The first white-board question from the horrible interview that I had recently was a question that a great number of computer science students are familiar with. The question was stated as follows:

Devise an algorithm for detecting whether a given string is a palindrome (spelled the same way forwards and backwards). For example, “kayak”

After the interview I decided that I wanted to explore the idea in more depth using TDD as a development tool to ensure that as new code was added none of the previous editions were broken without my knowledge. I decided that since I was using C# and the methods would only affect strings that the IsPalindrome() methods should be extension methods. The entire solution, including the unit tests, can be found in my PalindromeExtension repository on BitBucket.

To begin with, I decided that I would implement IsPalindrome() the classical way. I started with a single static class set up as follows:

namespace PalindromeExtension
{
    public static class PalindromeExtensionMethod
    {
    }
}

The easiest place to start, in my opinion, is the most common case; therefore, my first unit test tested the case where the given string is not a palindrome, and was written as follows:

public class When_using_the_palindrome_extension_method
     {
         [TestMethod]
        public void And_the_given_string_is_not_a_palindrome_then_the_extension_returns_false()
         {
            //arrange
            
            const string notApalindrome = "This is not a palindrome";

            //act

            var observedResult = notApalindrome.IsPalindrome();

            //assert

            Assert.IsFalse(observedResult);
         }
     }

This test is easy enough to get passing and will pass with the following implementation of IsPalindrome():

public static class PalindromeExtensionMethod
     {
        public static bool IsPalindrome(this string value)
        {
            return false;
        }
     }

That implementation may seem like a “cop-out” to those of you not familiar with test driven development, but writing the minimum amount of code to make the test pass is a key concept in test driven development. This does two very important things to the development process. First, and most importantly, it keeps the development cycle on any piece of code short and keeps iterations fast. Second it keeps things that are extra and unnecessary out of the code base, because YAGNI. When it all comes down to it, the method should return false if the given string is not a palindrome. Don’t worry about when the string is a palindrome yet. That is not what this test is testing.

The next unit test should test the minimal positive case. That is to say, my next test case was, “if the string was a palindrome with a length of 2 then the extension should return true”. My test was written like this:

        const string twoLetterPalindrome = "oo";

        [TestMethod]
        public void And_the_given_string_is_a_palindrome_with_2_letters_then_the_extension_returns_true()
        {
            //act

            var observedResult = twoLetterPalindrome.IsPalindrome();

            //assert

            Assert.IsTrue(observedResult);
        }

The next step was to get this test to pass. This iteration is where most of the functionality in all three implementations came about. That can be expected in fairly simple problems like this one. Larger problems, however, grow slower with each unit test, but there is always exponentially more and more implementation per iteration until a certain point is reached in the implementation. The classical solution uses a pair of stacks. The string is pushed onto one stack and, character by character, popped of the first stack and then pushed onto the second stack. The stacks are then check to see if their elements are equivalent and if they are, then the string is a palindrome, otherwise loop until the first stack is empty. Here is the code to get the most recent test passing:

public static class PalindromeExtensionMethod
     {
         public static bool IsPalindrome(this string value)
         {
            var startingStack = StringToStack(value);
            var stackToCompareTo = new Stack<char>();

            while (startingStack.Count > 0)
            {
                stackToCompareTo.Push(startingStack.Pop());

                if (startingStack.ToString() == stackToCompareTo.ToString()) return true;
            }

             return false;
         }

        private static Stack<char>; StringToStack(string theStringToConvert)
        {
            var backwardStringAsArray = theStringToConvert.Reverse().ToArray();
            var stackToReturn = new Stack<char>();

            foreach (var charater in backwardStringAsArray)
            {
                stackToReturn.Push(charater);   
            }

            return stackToReturn;
        }

This gets the code to pass, but surprisingly for the wrong reason. Using the ToString() method on a stack in C# does not change the stack’s elements back into a string, it gives a little bit of information on what type of data structure it is and how many elements it contains. I didn’t think of this and didn’t realize that there was a problem until I wrote the next test, but that is how test driven development works at times. On to the next test which tests the case where the beginning of the palindrome is upper-case and the end is lower-case. Here is the test:

        [TestMethod]
        public void And_the_given_string_is_a_palindrome_with_2_letters_with_one_capital_then_the_extension_returns_true()
        {
            var testString = twoLetterPalindrome.First().ToString(CultureInfo.InvariantCulture).ToUpper() +
                             String.Join("", twoLetterPalindrome.Skip(1));
            //act

            var observedResult = testString.IsPalindrome();

            //assert

            Assert.IsTrue(observedResult);
        }

The LINQ expression is some magic so that I could change my two letter palindrome into a palindrome with the beginning upper-case and the ending lower-case. This unit test passed out of the gate. This befuddled me and after realizing the mistake that I had made earlier, I changed the previous implementation to read as follows:

         public static bool IsPalindrome(this string value)
         {
            var startingStack = StringToStack(value);
            var stackToCompareTo = new Stack<char>();

            while (startingStack.Count > 0)
            {
                stackToCompareTo.Push(startingStack.Pop());
                
                var first = new String(startingStack.ToArray());
                var second = new String(stackToCompareTo.ToArray());
                
                if (first == second) return true;
            }

             return false;
         }

With these changes, my most recent test is now failing for the reason I expected it to fail. Getting this test to pass is as easy as making sure that the input is all lower-case before doing any operations on it:

         public static bool IsPalindrome(this string value)
         {
            var startingStack = StringToStack(value.ToLower());
            var stackToCompareTo = new Stack<char>();

            while (startingStack.Count > 0)
            {
                stackToCompareTo.Push(startingStack.Pop());
                
                var first = new String(startingStack.ToArray());
                var second = new String(stackToCompareTo.ToArray());
                
                if (first == second) return true;
            }

             return false;
         }

The next case to test is when the string is 3 letters long an is a palindrome. Here is the test for that case:

        private const string threeLetterPalindrome = "mom";
        [TestMethod]
        public void And_the_given_string_is_a_palindrome_with_3_letters_then_the_extension_returns_true()
        {
            //act

            var observedResult = threeLetterPalindrome.IsPalindrome();

            //assert

            Assert.IsTrue(observedResult);
        }

To get this test to pass, it is sufficient to pop an extra character off the stack so that the the middle character is not being compared when the comparison is being done. However, doing this breaks all the unit tests for the 2 character palindromes. In order to test for the even cases and still return true when the palindrome is even. here are the changes that I made:

         public static bool IsPalindrome(this string value)
         {
            var startingStack = StringToStack(value.ToLower());
            var stackToCompareTo = new Stack<char>();

            while (startingStack.Count > 0)
            {
                stackToCompareTo.Push(startingStack.Pop());

                var middleCharacter = startingStack.Pop();                

                var first = new String(startingStack.ToArray());
                var second = new String(stackToCompareTo.ToArray());
                
                if (first == second || (middleCharacter + first == second)) return true;
            }

             return false;
         }

All the unit tests are green again and we can move on to the next test. This tests for an even length palindrome of size 4. I thought that this test was going to pass out the gate, but strictly following the principle of only writing enough code to get the tests passing has yielded an anomaly. Here is the test:

        private const string fourLetterPalindrome = "noon";
        [TestMethod]
        public void And_the_given_string_is_a_palindrome_with_4_letters_then_the_extension_returns_true()
        {
            //act

            var observedResult = fourLetterPalindrome.IsPalindrome();

            //assert

            Assert.IsTrue(observedResult);
        }

After a bit of searching, I realized that the reason that this case wasn’t passing, even though the other cases with palindromes of even length were passing, is because I had forgotten to put the middle character back on the beginning stack before proceeding to the next step. To fix this I added the following code right before the closing bracket for the loop:

     startingStack.Push(middleCharacter);

Expecting this to work, I ran all the tests, but the last test was still failing because an InvalidOperationException was being thrown. This was because there was a point at which I was trying to pop the starting stack and there was nothing to pop. To fix this I changed the test in the loop to read as follows:

     while (startingStack.Count > 1)

This completed the functionality of the classical approach to deciding if a string is a palindrome and all the unit tests passed. Before I go on to talk about the other two implementations I got out of this exercise, I want to talk a little about my testing setup. I use the Visual Studio Unit Testing Framework for my testing framework. This is mainly because I get it for free with Visual Studio and it is what I am familiar with. For my mocking framework I use RhinoMocks using Arange-Act-Assert style test writing instead of Record-Replay. In my opinion, Record-Replay unit testing is better suited for larger more complex objects and it is also a more difficult concept to teach in a text based forum.

With the more classical general solution completed, I began to think of ways to implement IsPalindrome() using some of the nice libraries that are provided by the .NET framework. LINQ came to mind and after writing a few unit tests that looked similar to the ones written above, I came up with this implementation:

public static bool LinqOnlyIsPalindrome(this string value)
        {
            return value.IsEvenLength() ? value.ToLower().Substring(0, (value.Count()/2)) == new string(value.ToLower().Substring((value.Count()/2)).Reverse().ToArray())
                : value.ToLower().Substring(0, (value.Count()/2)) == new string(value.ToLower().Substring((value.Count()/2) + 1).Reverse().ToArray());
        }

private static bool IsEvenLength(this string value)
        {
            return ((value.Count() & 1)==0);
        }

This is an impressively ugly solution to the problem, but it works and all unit tests pass. After some time it dawned on me that this is ugly because I had become hampered by the notion that the string needed to be split in half and the two halves to be check for equality. Splitting the word in half is not necessary per the definition of a palindrome “A palindrome is a word, phrase, number, or other sequence of symbols or elements that reads the same forward or reversed …” LINQ helps with this implementation as well and reduces the code to an elegant on line of code:

public static bool RidiculouslyEasyLinqOnlyIsPalindrome(this string value)
        {
           return value.ToLower().Equals(new string(value.ToLower().Reverse().ToArray()));
        }

That is all for palindromes and TDD for now.

The Tipping Point

Be grateful even for hardship, setbacks, and bad people. Dealing with such obstacles is an essential part of training in the Art of Peace.” – Morihei Ueshiba

When the venture down this road into the public world of blogging began, I am afraid I boxed myself in by saying, “The purpose of this blog is to take known coding interview questions, analyze them, formulate requirements, find a complete solution, and present one or more solutions for the question. The question will be the kata; the nameless interviewer will be the tori; and I will be the uke.” I have grown quite a bit in the past several months of silence. Reading, studying, learning and practicing have helped me to understand that my subject is restrictive and misleading. I don’t know if anyone should ever apologize for naivety, but it will help me by way of taking a first step forward into a new way of thinking. I am sorry for my restricted view that technical interview questions, whiteboard questions, and the ability to code on the fly in front of interviewers was the key to the golden opportunity in software development and also about the implication that this blog made that these were the most important things to consider. There is so much more to this software development thing than I could imagine. I vow to break free of this restricted mindset and state a new purpose, but let me tell you about my journey first.

I work for a small company. A company still struggling to find its foothold in the world. A company in its adolescence. A company kind enough to take a chance on a budding software developer, sans any training in actual software development. The leaders of this company, while extremely knowledgeable in their fields of expertise, are not business men, and are still learning how to be business men. Earlier this year, after months of subtle suggestion and coaxing from my product manager, my team members, and most notably myself, the Chief Executive Officer announced that it had come to his realization that the company website must be updated, and that, being the most vocal of the proponents, I would be the lead of this project. I was energized by this validation and poured my soul into the project, admittedly unbeknownst the the CEO.

In 3 weeks I had learned enough about .NET MVC3 to become extremely dangerous. In 3 months I had the current static website translated into MVC3 so that it worked exactly as the current static pages did; however, notably faster, and without the cruft that built up after many years of various developers adjusting and tweaking the site, without source control and the other tools common to the trade today. The goal was to learn MVC in the real world, and get the site into source control where it would be safe for posterity. Both goals were achieved.

In addition to the translation of the website, I helped build the front end UX for a web application that was going to be part of the updated site. It had been announced with great fanfare by the board of directors in a press release in which a deadline of 120 days was given to complete the web application. Despite the development team’s opinion that the cart had been put before the horse, this news had already been reported through all the news outlets that would listen to the story. And so we completed it in less than 120 days, knowing that it would go live before the updated website. Since our shop develops desktop applications, it was the most beautiful thing that I could create with the internet being the only mentor I could find to help me learn web development. Aside from my loving pets, I consider it my most cherished child, and I keep it safe in my BitBucket account to show to anyone who delights in these things.

As the go live date for the web application neared, without definitive plans on the future of the website project as a whole, my product manager and I secretively made plans to point the domain alias at the MVC version of the website with the web application placed neatly where it should be and made plans to move forward with the redesign of the company website on our own. The day before our secret plans were to come to fruition, the members of the board called and announced that they had contracted to have a WordPress site built to replace the antiquated company site. My product manager was relieved. I died inside. For the next 2 months I clutched at everything for motivation, and then one of my co-workers, one third of our development team, announced he was moving on to greener pastures. I was lost. The ship was sinking and I had forgotten how to swim. I realized that if I was going to survive and stay sane I had to learn what I didn’t know how to do. I had to learn how to search for a job, even though the one I had was still OK.

Little did I know that searching for a new job was going to be as difficult now as it was when I was green with no experience at all. After updating my LinkedIn page, polishing my resume, and making it public on Monster, the calls from recruiters poured in like an unstoppable deluge. Offers for this and that came in, sometimes as many as 6 a day. It was exciting and fatiguing at the same time.

Nothing incredibly interesting came for several weeks, and then, it came. A large, well known company wanted to vet me for a web development position. This was exciting because I had just found I was passionate about web development and was excited to see where that career could take me. I decided to move forward with the interview process although I was ambivalent about the company culture and working in a large corporate environment.

The interview process moved forward as follows:

  1. 4 technical assessments were administered in order to gauge my aptitude for items in the web development arena.
  2. A technical phone interview was conducted in which we discussed the points on my resume and went through several technical scenarios which were formulated as, “what would you do if …” questions.
  3. 6 personality assessments were administered.
  4. And finally a personal onsite interview with a panel of interviewers was conducted which included 3 white-board questions.

It took 3 weeks and was exhausting. The most exhausting part about it was that, by the time I had reached the personal interview, my research on the company had convinced me that the company culture fit was not right for me and that I was most likely going to decline any offers for employment from this company. I went to the personal interview anyhow hoping that they may change my mind about what I had read from others about the company culture on Glassdoor. Unfortunately, I realized that the reports of horrible culture were factual when, during the white board questions, the interviewers decided to multitask by having a business meeting while I answered the first question. During the second question, half the interviewers left the room to do something with no excuse or apology.

Unfortunately, I did not get the great pleasure of declining their offer, because there was no offer. The reason given to the recruiter for not proceeding with an offer was that they were considering me for a desktop application development position and I wouldn’t talk about anything except how much I wanted to do web development. If you recall, the job requisition was for a web developer. Emotionally drained, completely demoralized, and utterly exhausted, I realized that all the pomp and ceremony of a traditional technical interview for a development position could have been summed up in 2 questions:

  1. “I see from your resume that you have been doing desktop application development for 2 years, is this true?”
  2. “We are in need of someone who would like to do desktop application development, if given the opportunity, would you enjoy being the one to fill that position?”

All the important questions about culture and team fit would have been answered during the 6 month contract period that is standard with all positions in their software development division. In fact, Eric Dietrich outlines just this proposed process at the end of his blog post entitled, “What’s Your Greatest Weakness: The Employer-Candidate Impedance Mismatch”. So why did this company insist on making me dance like a monkey and perform under ridiculous amounts of stress just to answer two simple questions? I’d like to think that it was to see how well I can execute daily duties under high levels of stress, but the more realistic answer is that they don’t know what is really important to demonstrate success in a position, which is team fit.

Two benefits have come out of this experience for me. The first is that I am extremely satisfied with my current position. My current employer treats me like what I am, a human being. The other is the realization that my former purpose behind this blog was narrow and that the subject matter of this blog needs to be about practicing in all arenas of the software development field, of which coding is only one. To paraphrase myself in order to restate my purpose, “The purpose of this blog is to talk about items pertaining to the field of software engineering. The blog will be the kata; the subject matter will be the tori; and I will be the uke.”