The Highlander Rule

So I thought I wrote about this a really long time ago. But that must have been in another blog. So here is a new take on The Highlander Rule.

There Can Be Only One

If you have seen the movie, Highlander, you already know this rule. If you have not seen the movie I suggest you watch it; it's a classic. 

In the movie, our hero Connor MacLeod repeatedly points out that "There can be only one'. This is all part of the plot that I won't spoil here except to say the statement drives the elimination of Connors completion. 

Only One of What?

Well, YMMV but, a Tech Lead is a good example. Product Owner is another. I'll talk about them as a sort of similar role. Generally, you can only take direction from one person. You cannot have two people directing a team and expect consistency. Subtle discrepancies in guidance can too easily lead to chaos and confusion in a team. 

For example, if you have two Tech Leads and one of them says 'We do TDD, and we do it all the time." and another Tech Lead who says "We do TDD when problems are hard enough". What do the engineers on the team do? It could vary. 

I'll submit that "when problems are hard enough" is just vague enough to get you an uneven result that will probably not work out for you.

Similarly, if you hav a Product Owner who says "The number one feature is SSO" and another who says its the "Chat Bot interface", what does the team direct their attention toward?

But, Collaboration?

While you might overcome the conflicts of multiple leaders with divergent agendas through negotiation, you are probably wasting energy. You'll be better served by having one person with one vision or set of rules providing one consistent set of directions. 

Keep in mind, your goal is to deliver value, quickly. Spending time in debate may not serve you well. Your better off delivering a set of value then creating another (highest value first please) than trying to do both or worse, both at the same time. It goes back to your focus; a topic for another time.

Strawberry Perl and Git on Windows, why doesn't Prove Work?

If you are having all kinds of Perl @INC problems and other strange behaviors with Perl on a Windows box and you have both Strawberry Perl and Git installed, check your class path order.

Turns out Git includes Perl 5.8.8 and it may be messing with your head. If you make sure Strawberry Perl is first in your path you will likely succeed more.

Thanks to Schmonz for helping me figure this out!

You Obtained management permission to test-drive!?

You Obtained management permission to test-drive!?

Inspired by Yareev's post
This is not an assault on Yareev directly, only inspired by his content.

This is not the first time I've heard about developers seeking permission from management to do their jobs and it's not just TDD, it is any aspect of your job. A Craftsperson doesn't ask for permission to do their job correctly or professionally. If you are in a situation where you need to ask for permission to your job correctly, take action now. You are doing the job you are doing ostensibly because you are an expert in your field and you know how to do the job correctly.

I'm not saying you cannot or should not inform your boss of what you are doing. More importantly you should share what your are doing with your team. If it makes you better, it might make them better too.

The need to ask or even inform management about the details of how you deliver outcomes is part of what I call Institutional Friction(tm). Software Craftsmanship is about doing the best possible job at delivering value to the business through software. Its not an art project, it's an engineering project that might look like art.

An engineer's purpose is to implement the simplest and most cost effective solution to a problem. Some sort of director person's job should be to point engineers at targets. The creamy filling is in some sense irrelvant to the business opportunity.

Related to the health and well-being of the engineer, and the sustainabiliy of the organization is one of the many aspects of how craftsmanship applies to the business proposition of developing software. Poorly crafted code can have negative impacts on both.

Engineers who have to maintain the poorly constucted, overly complicated, byzantine labrith of enterprise solutions grow weary, disenfranchised, and unproductive.

Businesses that have to maintain the same lose effectiveness in the market, suffer from increased operational cost, and limit their ability to pivot and chase new market demands.

Software Craftsmanship is about balancing between all of these forces. It is engineering proper. Therefore, as engineers we should not allow anyone to tell us how to create that balance by method, practice, or approach. We should accept input on where the right balance is.

Questions like What is the longevity of this platform or system? can shape how much effort we put into the pliability of its design. How integral is this applicaiton to daily operations? can effect how we consider durability and availability of the system. What are the consequence of data loss? can change the underlying economics of operations. These and many many more questions can lead engineers to draw proper conclusions about how to craft software.

The catch is two fold, first we need forthright answers to those questions. Secondly, we must insist upon being given the lattiude to choose the methods of execution to devliver a solution. We have become an integral part of business process and as thought workers and engineers; we need to become more engaged in meeting the goals of the organization.

Stability?

So in the past two years I have seen several friends and associates leave their jobs as consultants. These are great consultants and good people. I've called each one of them and asked what their motivations for leaving were. I find two reoccurring themes in these conversations.

First I hear the common refrain that they want to be home with their families more often. I get that. I don't have it, but I get it. To be honest, the day that traveling for work becomes a problem for me or my family I will make a hasty exit. So no harm, no foul on wanting to be home with family.

The other common reason I hear is that they wanted more stability. This one I don't get. I keep hearing that changing clients, projects, and work locations is somehow unstable. I don't get that; that is the part that thrills me. Granted, I spend more time at most client locations than many people I know, but changing locations, projects, and clients every two years is what keeps things fresh in my world. I love that aspect of my role as a consultant.

That said, I recognize that there is a lot of anxiety inducing activity in changing engagements frequently. Meeting new people, learning new processes, and finding a good lunch buddy are all problems we face when we start a new engagement. 

So I wonder if the issue is that consulting firms don't do a good enough job of preparing a landing spot for us. There is something to be said for creating camaraderie through shared suffering. But is it that we aren't doing enough to help our consultants settle in, or is it that our consultants aren't prepared for the difficulties they will face with each new engagement?

Conway's Game of Life

I Love this Exercise. Here is a video of me doing the exercise in Java. There are other ways to solve this but this one is simple enough for demonstrating straight forward TDD using Java, JUnit, and Hamcrest.

I have not had time to do a voice over for this yet. What you will see though is me progressively building up the the Rules for Conway's Game of Life through TDD.

If you'd like to learn more about Conway's Game of Life, check this out.

Enjoy.



Thanks to Magnus Stahre (@magnusstahre) for git-crawl and making this video easier.

What Is a Good Tech Lead?

What Is a Good Tech Lead?

Tech Lead is a role frequently seen on development teams filled by a wide variety of people. Many times the Tech Lead is the most senior person of a technical nature on the team. By senior I mean the person who has the longest tenure. This is frequently a good choice, but not always the right one.

Most often, with age comes wisdom, but this isn't always the case.A long term employee of the same company with limited exposure to external environments is operating in an echo chamber. They lack a diverse experience to use as a sounding board for their ideas or the ideas of the people around them.

So to begin with I think a key characteristic of a Tech Lead is a breadth of experience. The more projects, situations, languages, products and managers a Tech Lead has had, the more likely they are to be good at what they do.

Tech Leads need to be calm and rational people. For any number of reasons projects can get crazy; people shout and threaten and cajole when things aren't going as planned. A good Tech Lead knows that nothing goes as planned and can calmly address issues knowing that most problems are solvable as long as you don't lose your head.

Tech Leads make lots of choices throughout the course of a project. Some have little or no consequences, some have major repercussions. A good Tech Lead knows the difference between these kinds of choices and therefore how much effort to invest in making them. In all cases, a Tech Lead should make those choices with confidence. Where they cannot make those choices confidently a good Tech Lead is open to suggestion and experimentation. In any case the Tech Lead understands the risks and costs associated with making a choice and can weigh the decision appropriately.

Tech Leads need to remain focused. It is important to have good technical depth and breadth, but it is also important to understand when you are out of your depth and have the humility to ask others for help. A Tech Lead should always be willing to delegate to others in order to remain focused on the primary goal of the project: delivering value to the business.

In order to remain focused it is important for a Tech Lead to be passionate. Not just about the objective of a project, but about the technology itself. A Tech Lead should strive for technical excellence in the solution. It isn't just about doing the Right Thing(tm) but also about doing it well.

In order to make this work a Tech Lead needs to have the right disposition. A Tech Lead needs to be simultaneously likable and aloof. Take a hard line on issues that are critical to success while remaining pliable on everything else. Logical and rational without becoming cold and unapproachable. A good Tech Lead should push a team to exceed its own expectations in the quality of their work without breaking their spirit at the same time.

A good Tech Lead should be the team's staunchest defender and biggest cheerleader; A mentor, guide, and leader who approaches every situation with calm rationality and a minimum of ego.

Guice, Guice Servlet, Jersey, and the Request Scoped Dependancy

On my current project I've been working with Matt Foy to improve the tests around a rather large application. The original developers chose to use Guice with Guice Servlet and Jersey services to create their application. One of the things that we ran into this week was that we had no tests around the Guice configuration. So while everything seemed OK on the CI server, as soon as we actually deployed the application we discovered that the Jersey servlets would not function because various Request Scoped dependancies had not actually been injected. Basically our Module configurations were a mess and we didn't know it.

So, we created a simple sandbox representation of this problem and then discovered a way to effectively test that the Guice configuration was correct. We must give credit to the authors of Guice for making their test available, this is how we figured it out.

First let us show you the classes that I want to test, note this is highly contrived for the purpose of clarity;

The following servlet is simply in place to allow us to have a servlet with a Request Scoped dependency in a Jersey service.

The Dependancy is simply an implementation of an interface, neither of which contain any methods;

And we have a custom module for creating the Dependency. Note that the Dependancy.class is scoped as @RequestScoped;

And finally, the GuiceServletContextListener that would be used by the Servlet container to do the actual injections at runtime;

Now that you have the context, here's how we solved the problem. The GuiceFilter used by Guice Servlet support conducts the injection activity for the servlet when a request is executed. If you attempt to get, from the injector, any injected instance that is RequestScoped you will get an exception from the Injector indicating that you've requested a resource outside the scope of a Request. It's your own fault really :-).

So, by contriving a filter chain of assertions you can determine if Guice has actually injected the dependencies correctly. Here's how;

First we created this Assertion class;

The assertProvisioningType method allows you to assert that an instance is provided for any type request and that the provided instance is of the appropriate type.

The assertInstantiablity method allows you to assert that an instance is provided for a requested type.

The applyFilterChainAssertion method executes the given FilterChain using the GuiceFilter as the head of the chain. JMock is used in this case to support our current project configuration (Note: We'll be rewriting this with Mockito soon enough.) When you call this method with a FilterChain full of assertions they will have access to the Injector and will be within the Request scope, so you can easily make assertions about them without getting the nasty exception pictured here;

The expose method allows you to directly fetch a Request Scoped instance from the injector for additional testing.

Here is the test suite from our contrived example;

Hope this helps someone.