Starting the internship and Embracing the Suck

I just wrote up the first salvo in the Battle of the Internship. I hope this one does better than the last one. I haven't sent it yet. I'm letting it sit for a spell after which I'll review it and send it along.

The Battle of the Internship is where I put to work the stuff I was supposed to learn in the college class I'm taking. I don't know if it will work. I tell myself I don't care but I'm lying and I know it. I'll go through the motions and honestly give it my best effort. That's because it's a learning experience and I want to learn this stuff. I want to use it too. That's what this is all about isn't it? It's about knowing I can change myself and believing that I can.

Can I accept that I can't change the way things are where I work if this fails? I hope so but I'm still going to try and make a difference.

This is whut I'm sending out.


Embracing the Suck...

But only as much as is absolutely necessary.

There's an internship as part of the leadership and management class I'm taking and The Boss has graciously allowed me to do that internship here. I have a simple goal, "Make us a better Team". 

There's nothing earth shattering about any of the exercises to I have planned. They are what the sages of all things Team and Leadership say are effective. I'm simply going to direct us through a series of steps that they taught us about in class and that I've gleaned from the assigned readings. My personal assignment is to do my best to ensure that it's neither intrusive nor just an exercise in going through the motions. It needs to be real or it's pointless.

Muffin top version of the Serenity Prayer

You all know the serenity prayer in one form or another:

    God, grant me the serenity to accept the things I cannot change,

    The courage to change the things I can,

    And wisdom to know the difference.

 http://en.wikipedia.org/wiki/Serenity_Prayer  (There's some neat information here)

As far as I can tell, the first line translates directly to, "Embrace the Suck".

Sometimes The Suck is external, and a part of our daily lives that isn't going away. We work for the (PLACE WHERE I WORK) and certain things come down the pike which we have to simply embrace. At other times it's closer, like certain aspects of PITA policy. Fighting that suck is part of who we are and what we do. The continued effort towards obtaining the aptly named Purgatory network is one of the ways we meet our foe and is but one example of how we battle every day.

When The Suck is internal is where the next two lines can have more effect. Do we/I continue believing and behaving the same day after day or do we/I try and make a change? (Cliché about insanity intentionally omitted. I'll digest this stuff down to what's the most applicable to us in our place of mutual Suck.

We're in this boat together. The ride will continue. The boat will always leak and we'll keep bailing. That's the Suck we endure. Let's just make that little bit of extra effort that lets us get better at patching the holes we can, bailing more efficiently and seeing through the fog towards wherever we're going. 

The very least you'll get out of this is the personal sense of satisfaction from knowing you, and "we" because it's a team, tried.

Subject: Further education

Alternate title: Exercises in cowboy style software development

I stole this art from: http://blog.siteground.com/siteground-staging/

Sometimes we're not happy with the way things are going on around us. Lately, I've been trying to make a difference in many different things. I'm coming up with a plan of action but decided to set off on the path before the plan is finalized. I think of it as a RAD (Rapid Application Development) form of self improvement. I have a reasonably well defined goal of where I want to go and know the steps I'm taking will get me closer. So I'm off...

I think that a lot of cowboy development happens where I work. That type of behavior skips a lot of what I consider to be good practices in software development. So, I'm trying to get the other members on the team to see the value of certain practices. In this case it's writing effective unit tests. Because of the way my mind works I approach things by seeing what's wrong with it. That helps to explain the structure of the message I sent.

* It's worth noting that the developer that created this unit test is no longer with the team. Though an exceptional developer in most every other way I think he fell a bit short here. Even if he was here he wouldn't be embarrassed by this being used as an example. He was, and I believe still is, always open for an intellectual discussion.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Subject: Further education

Below is a unit test from the OurGroup.OBP.EnrollmentPortal project. AKA: OurBigProject

Please review this unit test and indicate its shortcomings. I found at least two direct shortcomings and more than two indirect ones.

Note: This is the only unit test in the solution for ASourceii Labs.

    [TestMethod]

    public void ASourceii_GetLabs()

    {

      IOBPDataSource source = (IOPBDataSource)context.Lookup(@"DataSources\OurGroup.DataSource");

      List<LabTest> labs = source.GetLabTestsForPatient(TestPatient, DateTime.Parse("10/22/2002"), DateTime.Now, TestUser);

      foreach (LabTest lab in labs)

      {

        if (lab.LabTestName.Contains("CANCER")) throw new Exception("You dumbass");

      }

    }

Responses expected by COB today.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

My worst fears were realized. I got nothing back. 

Utilizing some skills I recently picked up in a management focused class I'm taking I responded like this. Basically, that means I didn't admit that no one responded. I praised them for the success they might have had in hopes that some guilt might develop for their lack of participation when they believe others have.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Subject: RE: Further education

Not bad for you simple cowboy developers.

Zone of Rant

One of, if not the most important, reasons for unit tests is to allow you to make modifications to code and be well assured that your changes did not break the code. Not only that the code fails to throw exceptions but that it still meets each and every expectation held for it. In the case of OurBigProject, like many of our applications, we can't replace the antiquated and difficult to use data layer without substantial risk. A solid suite of unit tests would significantly reduce that risk. You can pay some now or you can pay a whole bunch more later.

First things first:

- What is this test verifying? There are no comments or association to the requirement or test case specifying what is being verified. It's left up to whoever comes upon it to guess.

Other critical items:

- There are no Asserts. In MSTest the standard pattern is to use an Assert for the validation.

          All of the available Asserts: http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.aspx

- Near and dear to one of our team members's. heart is the unprofessionalism displayed in this code. I got read the riot act for using the word "poop" as a temp variable in some work I wasn't finished with and this contains the word "dumbass". This code, in this exact form, was sent to the Another Organization. Besides making us look, unprofessional the boss type people wouldn't be happy if they found out about this.

- This is the only test for Labs. It only verifies that none of the returned records contain the word "CANCER"**. If no records were returned then the test passes.

Other issues:

- **The method string.Contains is case sensitive. So the word "Cancer" would not be caught by this test.

- There is no explanation of what the input or output test data is. You don't know, without some digging, what the makeup of any of those is.

- This test throws an exception. In some testing frameworks if an exception is thrown then the system stops and none of the other tests are run. All tests in a suite should be able to be executed regardless of the pass or fail status of another test. IF you want to create a dependency between tests then do it in code using the available methods.

- The thrown exception doesn't tell you enough. (Not for some of use anyway) It should log the reason for the failure.

- There should be other tests. For example: One with a list of the expected results. By simply including a start and end date an exact list could be retrieved and compared to a benchmark.*

- It's hard to see here but this test is dependent on access to an external data source. In this case it's a test instance of a web service (That isn't working BTW) that pulls data out of a production system that we don't have full control of. One of the beauties of dependency injection is that you the developer could isolate the environment so that the external dependency is removed. Especially because it's dependency injection you could have it run both ways. Once against an environment you have total control over, making it a true "unit" test, and once against the full environment.

*Most every object in the OurBigProject project can be serialized. That means the input objects and expected benchmark values can be stored in files. That makes it easy to create and execute a wide variety of test scenarios. (I'll show how this is can be accomplished in my next installment.)

In conclusion:

Unit tests are more than a way for you to exercise your code outside of the application that will use it during development. It insures that the code does what is expected of it. The time saved by not writing an adequate set of unit tests will quickly be lost the next time anyone goes in and makes a modification. Relying on the test process at the end of the development cycle to catch mistakes you have made is failure from the onset.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

I don't think I'll be able to realize the effectiveness of this effort any time soon. Maybe if I open up a solution in the future and see more than one unit test per method.

Oh, and I know I need to get better at formatting my posts. I'll check into that.