Archive for May, 2010

Tech Leading 101: Vision

May 15, 2010
Being a technical lead on a project is a complex position with a lot of demands. Recently I have been thinking about what separates
the good leads from the bad ones and one of the main things that keeps coming up is ‘vision’, having an understanding ahead of time of the project’s technical and non-technical aspects and having goals and ideas on how address them. When you have a great lead it seems like they have anticipated everything and things fit together. There is continuity to the code. A direct result I believe in many cases of a tech leads creating a vision for the project, communicating that to the team, and making sure everyone is working toward the vision. I want to discuss some areas of projects where tech leads commonly lack vision because tech leads get focused on the technicals they forget some important non-technical aspects which are unavoidable.

Areas Lacking Vision

  • Schedule – I know this should be the project manager right? Well yeah but a tech lead needs to anticipate what the best ordering of tasks is dependencies and what resources match best with specific tasks. Being a project where you are constantly realizing dependencies which previously weren’t thought to be there makes development painful in many cases. Yeah changing task order mid stream sometimes is unavoidable but put critical thinking into it at the being of the project and make sure tasks get started off with the possibility of the right order.
  • Task Delagation – Creating a pattern for how tasks are going to be handed off could be a tech lead’s best friend. Just saying start on the task isn’t sufficient. Envision ahead of time how your going to kick other developers off on tasks and what you don’t want to happen. This will allow you to avoid lost time on the calendar and getting pulled in too many directions at once.
  • Reviewing Code – This creeps up on far too many tech lead’s (myself included), assuming you practice having project code reviewed either internally or externally, preventing the ability to react to requested changes. Make sure to mentally anticipate tasks finishing and the who/when of code reviewing. The sooner you catch issues the better and reviews are assurance that team members are completing tasks correctly.
  • Documentation – What the right documentation that needs to come out of a project is what I’m talking about here. understanding not only what useful client documents are needed but also documents for people who will be maintaining the project in the future. More projects than not that I come on after the fact as a developer and I think “I wish I had documentation on this”.
  • Project Communication – Communication isn’t a problem for a lot of tech leads especially when everyone is base out of one office. The situation where creating a vision of how communication will play out is when you have team members in diffent locations. Relying on email just isn’t an option in most cases. Too many times communication becomes a problem because someone on your team isn’t available to communicate in real time. Work on a vision that mitigates those situations thinking about the obvious like meeting times but also the not so obvious like what tasks get assigned to who.
I’m a firm believer in working at the begining of a project to create a vision of every aspect of the project possible so you can work towards it and get the team to work toward it as well (so don’t keep it to yourself). Vision can change as things come up too so don’t chain yourself to the original vision, allow project members to challenge it and challenge it yourself. Afterwards if you feel like it needs to change then change it.

Remember the Abstract Factory Pattern

May 6, 2010

With all the emphasis these days on unit testing it amazes me that I see developers are still dropping bombs like…

  1 public void someMethodThatMyUnitTestHasToCall(){
  2        ... Method Logic ...
  3        SuperComplexObject object = new SuperComplexObject();
  4        object.doSomethingThatIDesperatelyWantToAvoidForMyTest();
  5        // or an alternatively horrific call
  6        DifferentClass.staticMethodCallWhichCallsSomethingElseIWantToAvoid();
  7 }

Nothing kills a unit test faster than near un-mockable behavior in the middle of a method call which you can’t avoid (at least in java).  Types of actions taken in these undesirable method calls and object creations are generally database activity or some type of HTTP access when cause you to write more code to setup a unit test than the code under test itself. Many cases can be refactored with simply making the object an instance variable, however when an object has a lot of state which shouldn’t be retained from call to call thats not an option. I want to remind folks in these cases of the Abstract Factory Pattern which is a very straight forward way to wrap these monsters up. Sometimes people may avoid the exact pattern because it involves creating an extra class and interface in its pure form which sometimes is undesirable especially if you have a lot of classes which need to be hidden,  so I’ll offer a variation on the pattern which hopefully will make it more palatable.

Modified Abstract Factory

The modified abstract factory I’ll suggest is simply a single class that encapsulates the unwanted call. For Object creation it will always be the actual “new Object()” statement because if you can’t get another instance type created your out of luck. In the case of static method calls its the method call itself.

  1 public class ComplexObjectFactory {
  2    public ComplexObject getComplexObject(){
  3        ComplexObject object = new ComplexObject();
  4        return object;
  5    }
  6 }

Injecting the Factory

Now we need to get the factory into the class somehow there are a couple of ways to do this…

  • Pass a factory instance in as new parameter
  • Create a settable field in the class for the new factory

Depending on the situation you could have a other options as well but the one option that isn’t there is just replacing “new Object()” with “new ObjectFactory()” that won’t get you any closer to solving the problem with the suggested solution I’m providing. Now you can see how the old method changes.

  1 ComplexObjectFactory factory = new ComplexObjectFactory();
  2
  3 public void methodCalledByUnitTest(){
  4    ComplexObject object = factory.getComplexObject();
  5    object.complexMethodCall();
  6 }
  7
  8 public void setComplexObjectFactory(ComplexObjectFactory factory) {
  9     this.factory = factory;
 10 }

Unit Test Mocking

Now there is a hook to where you can create an extension of the quasi abstract factory class which returns a mock instance of your class or returns mocked data for a static method call.

  1 ComplexObjectFactory factory = new ComplexObjectFactory() {
  2      public ComplexObject getComplexObject() {
  3           //Mock up the behavior in someway.
  4           return new MockComplextObject():
  5      }
  6 };

All you need to do is set the new factory implementation. This will allow your unit test to focus on the code under test not the code that was tangentially called by the code under test (assuming thats your testing methodology).