Agile Adverts

These YouTube adverts are a hoot. Targeted at attracting software developers to agile companies.

This one is my favorite: My Favorite Things ... go ThoughtWorks!

Others here: AgileAdvert

Have fun.

Snippet - Sizing Text Controls Without OnPaint

We so often avoid considering font, screen resolution, etc when sizing a text control we often set a minimum size that looks good on our screen. For example, you need to display a value that may vary from say 1.1 to say 8,888,888.88 and need to set a width that will allow the value to be visible for all values.

Not hard, I just keep reinventing the wheel finding the how to. So having done this yet again today here is the tell all code snippet:

Graphics graphics = control.CreateGraphics();
SizeF size = graphics.MeasureString(text, font);

Proudly simple (Nigel - I did originally type 'embarrassingly simple', but you are having such an effect on me!).

Pair Programming - Old Style Stations Still Sold

I've found a company that is selling pair programming work stations in the old, pre-XP, style here. I do not know the price. They even sell team clothing here. Maybe XP would be more effective with team clothing, the safety offered by this clothing seems to have been overlooked.

They even have an office suite available for a customer team that in true XP style speak with one voice here.

Just goes to show what is old is new.

When To Use .Net Events

I've been a long fan of .Net events and have had great success with them. I like an event driven model. But recently I've been wrestling with code in which events seem to cause more complications than they solve. Today in discussion with colleagues about implementation of undo/redo in an application the penny dropped. Using events within presentation layers is good but not in domain (model) objects as they greatly complicate object persistence.

The undo/redo is a great example, if an object that is being deleted has subscriptions to events on other objects and the subscriptions are deleted how do you restore the object? If you do not delete them then your inactive object is now being modified by events from the still active objects. Besides, is it a code smell if domain objects are notifying each other of changes? Does that imply poor encapsulation?

It seems to be lifetime issue. UI components typically sit in a child-parent relationship were all are created and discarded together so the need to manage event removal is not as critical.

Should Unit Tests Share A Bed With Production Code?

I'm wrestling with the question of why not place unit tests in the production code assembly? Perhaps even in the same file as the class under test. When I first started doing unit tests this is how I started as it allowed testing protected and even private methods. But now I feel this is a code smell but I'm unable to quantify as to why (which is a smell in itself).

I'll probably end up editing this post as this is really a thinking exercise. I do feel that tests ought to be in a separate assembly and ought to only test public behaviour.

In support of in assembly/file unit tests:

• Easier to find the tests
• Enables testing of internal and protected methods.
• As the tests reside in the production assemblies it means that a deployed application can be unit tested.
  

In the other corner:

• TDD makes us use our code before writing it and as a result makes us think about its design. The public behaviour of a class is all that is important.
• Testing protected or internal members means we are testing aspects not visible to users of the class. Therefore it allows poor encapsulation (my opinion).
• Unit testing is about code development not end user functionality which are covered by user acceptance tests (UATs). So unit tests are useless on a deployed application as they inherently will behave the same (pass). If not, they are not unit tests.

I'm still thinking about this one.

Private Methods Can Be A Smell

When using TDD we write tests that give us a reason to write the production code we believe we need. The end result is that we end up with executable code specifications and an inherent 100% code coverage. But, if we find ourselves refactoring the code into private members for reuse then doesn't that mean that we have some duplicate test? That is, the same functionality is required by more than one public method.

This is not always the case, we could be calling the private method multiple times from the one public method. But if there are multiple public methods calling it then doesn't that mean that the tests on each of those public methods must each test all aspects of the private member? Duplication which is a smell.

The smell is that probably the tests for the following public methods are assuming that the first method's test test the private functionality. But this assumes that the code is not going to change (he he). So, I'm thinking that private methods that are invoked by calls to multiple public methods are a stench and ought not be allowed. In such cases refactor the code to extract the private method as a separate class or find a way to use one public method only.

Is this also a good example of why unit tests ought only test public behaviour. I'm wondering if the UT code was in the same assembly the private methods would be implemented as 'internal' or 'protected' methods and tested directly. I can see the attraction but it means that embedded classes remain hidden. The advantage of TDD in highlighting such cases is diminished.

I wonder if somebody has written a tool to detect such a code smell?

Links:

• Don't test your privates
• No private methods
  

A Pattern To Help Introduce Unit Testing?

Today I heard that our CEO saw some of our automated user acceptance tests (UATs). These are tests written from the user's perspective. You can see the screens flashing by. The impressive thing is that the CEO immediately saw the business value and commented on how they would lead to cost and time savings at the end of the project and beyond.

While this did puff up our pride it also made me realize that the value of UATs is self evident to our managers while unit tests are, rightfully, seen as 'secret developers business'. After all unit tests are about writing code and our users are not interested in code, they are only interested in working features.

So, I wonder if UATs can be used as a first step in introducing automated developer testing into an organization. That is, UATs first and then unit tests. If management needs to be convinced of the value this may be a good approach.

EWSS Wikipedia

Today I found that the Wikipedia did not have any entry for External Water Spray Systems (EWSS) so I added one. The entry can be found here.

Achieving 'Flow'

In a conversation today it came up how high performance teams thrive on challenges. Well that was the opinion (which I do tend to agree with) and this reminded me of the concept of 'flow' that I once read about but could never find the reference to. But as Google would have it today I did find the magic words to find an article about flow.

As defined by Mihaly Csikszentmihalyi:

"... a state of deep focus that occurs when people engage in challenging tasks that demand intense concentration and commitment. Flow occurs when a person’s skill level is perfectly balanced to the challenge level of a task that has clear goals and provides immediate feedback."

The conversation lead me to wonder if there is a relationship between high performance teams and flow. I wonder if the collaboration within the team with the various skill sets facilitates flow. Is collaboration a flow enabler?

To put it in other way, in a team members help each other and function as a unit. So does this enable each member to achieve their best ... that is, achieve flow?

Whatever the case I love flow. :-)

Other links:

• Wikipeadia
  
• Amazon.com: Beyond Boredom and Anxiety: Experiencing Flow in Work and Play

Team vs Group Profitability

"Team" is most often used to describe any group that works as a group with a common project. But if the group is managed, or choses to work, as a group of individuals its effective output must become less than the sum of the individual capabilities. If a team implies a collaborative group that achieves an output greater than the summation of the individual capabilities then overuse of "team" hides what is possible.

"A group is a team, but a team is more than a group."
- My assertion.

The chart top right is a fabrication to illustrate my opinion (that is hopefully the result of my experiences). The assumption here is to compare two groups with members of the same expertise and expertise mix. The group either chooses to or is managed as individuals. The classic smell of this approach is assignment of areas of functionality to individual developers, or silence in the team's pit. A team is characterized by team ownership of tasks, integrity, frequent discussion, healthy conflict, and collaboration.

While interesting the chart is not surprising. The important thing is the ratio of effective output of the two groups charted. That is just how much more, in comparison, a team is more profitable than just a group. A kind of opportunity cost approach. The difference is large. My observation is that for a group of about 5 members, a team is typically twice as effective. If we factor into this the concept of a high performance team and member skills, much larger profitability can be achieved.

The definition of a high performance team that fits for me is:

"A high performance team is a team which achieves an output that far exceeds the summation of the capabilities of its members."
- I forget the author's name.

It seems to me to stay in business there is no choice but to employ the best and insist on teamwork. The critical success factor is management. As a team can only foster if management makes the environment and mix of developers happen.

Home Bushfire EWSS & Fire Hoses

Living in a high bushfire (wildfire) risk area we decided to install a bushfire pump / EWSS / fire hose system when we bought the house. Thing is we both work so we are most likely to be at work on a high fire risk day. Having much loved dogs this meant that we wanted a system that made us feel safe and that we could remotely start to protect our dogs from a surface fire resulting from an ember attack. An ember attack is most likely. The house being almost 100 years old has survived a few ember attacks so that is our focus.

So, I've finally started to document our system. The trouble with bushfire EWSS (External Water Spray Systems) is that there is very little hard research so there are many 'opinions'. I've only found one paper on EWSS but I will blog on that another time.

Given the nature of an ember attack, if we are not home the only proper home defense would be a full deluge system that would need to run for hours as detecting spot fires is not practical as the amount of water required would be huge (town water may not be available). Also, the CFA tells us that fires start from inside a house. How can we detect a broken window and deluge a room?

So the objectives of the initial system are:

• Protect the dogs from a surface fire during an ember attack. We can keep this area wet for about 6 hours with available water so this is 'possible'.
• Run fire hoses to make home defense easier.
• Independent water supply (25,000L) as town water may not be available.
• Run without mains electricity as history shows that the power goes early in a bushfire.
• Remote start from work.
  

The attached diagram is my first attempt at documenting our system. We chose a Davey Firefighter 5 pump as the Honda engine is very reliable and this version provides a flat pressure curve over a wide flow rate (up to about 500L/m) which means that we can use it drive hoses and sprinklers at the same time. We got the electric start model as we want to remote start it and in any case we do not want to fighting a recoil start when stressed out.

The remote start system is bases around a low power 12VDC computer system and our home internet connection is also powered off the battery backed 12V supply which is real convenient as we often loose power in this are. More about that later.

More photos of the system here.