Wednesday, February 18, 2009

Can Distributed Agile Work?

Andy Singleton says yes!

Andy says that if you accept that development will be distributed and get on with making it efficient it leads you to question a bunch of common practices.

Don't do interviews.. and Don't do estimation.. were my favorites.

Andy's company Assembla pull together a bunch of open-source and internal tools to set up a tool chain that lets lots of people work on the same project at once, gives visibility to your customers and tracks progress.

Andy also suggests that when a project is just starting up you can pile on loads of people and let it settle into a good team. This goes against my current experiences with development teams. In my experience you need to get 2-4 really smart people to do some vertical stripes through your application to flesh out an architecture. Once that is done.. then you are ready to start scaling the team up. Bringing too many people on early leads to too much code before the architecture is set. This leads to lots of code to refactor as develop and understanding of the domain.

Having said that... the initial architecture decisions you are making tend to be... How should we separate the domain logic from the presentation logic? How should we use Technology X to implement the GUI?

These things seem like such solved problems to me at the moment. I can't understand why they take so long to get in place. For each technology stack there should be something like Rails where you just fill in the bits that are specific to your domain.

Back to Andy... I'd love to hear more about how the first few weeks of his projects go. He claims to be having good success, so I would love to know more :)

I guess I'll start reading his blog.

The OO light bulb goes on

I had a light bulb moment a few months ago that I want to share. Bare with me.

OO programs when running are a network of in memory 'object's each with specific behavior and state.

Traditional OO programming languages like C# 1.1 and Java allow you to specify classes of objects, defining generalizations about how certain types of object behave.

In C# an object is an instance of a class.

In True OO this is only one of many ways to get your running object in memory. Why limit yourself to this factory technique... Why not create a bare object and add methods to it at runtime? Why not mix together sub-class modules of functionality?

As long as at the end you have a network of objects in memory that behave the way you need them to, to model your domain, why limit yourself to this one technique of object creation?

Type safety?

I recently heard a podcast (can't recall which...) where the speaker said "type checking in the compiler is just a form of unit testing". Personally I am still letting that sink in.

I guess, if I were you, and I had read this far, I would get to this point and have one question "So What?"

Thinking of classes as only one way to get objects into memory is liberating:-

I had a class I wrote the other day that was part of a UAT framework based on White...

 public class CaseHelper : ScreenHelper
public CaseHelper(Window window)
: base(window)

public string PatientId
get { return PatientIdBox.Text; }
set { PatientIdBox.SetValue(value); }

public string GivenName
get { return GivenNameBox.Text; }
set { GivenNameBox.SetValue(value); }

public string FamilyName
get { return FamilyNameBox.Text; }
set { FamilyNameBox.SetValue(value); }

public string DateOfBirth
get { return DateOfBirthBox.Text; }
set { DateOfBirthBox.SetValue(value); }

public string Gender
get { return GenderBox.SelectedItemChildName(); }
set { GenderBox.SelectItemByChildName(value); }

public void ClickSave()

public string BarcodeNo
{get { return BarcodeNoBox.Text; }}

private TextBox PatientIdBox
{get { return Get<TextBox>("patientId"); }}

private TextBox GivenNameBox
{get { return Get<TextBox>("givenName"); }}

private TextBox FamilyNameBox
{get { return Get<TextBox>("familyName"); }}

private TextBox DateOfBirthBox
{get { return Get<TextBox>("dateOfBirth"); }}

private ComboBox GenderBox
{get { return Get<ComboBox>("gender"); }}

private TextBox BarcodeNoBox
{get { return Get<TextBox>("barcodeNo"); }}

private Button SaveButton
{get { return Get<Button>("saveButton"); }}


As you can see lots of duplication that is hard to factor out further. I could turn to code generation., but what frustrates me is in Ruby I would be able to write helpers for each type of control and the code would become...

class CaseHelper < ScreenHelper
has_text "patientId"
has_text "barcodeNo"
has_button "saveButton"
has_combo "gender"
has_text "giveName"
has_text "familyName"
has_text "dataOfBirth"

That I can handle. This is possible because defining a class is ruby is done at execution time. All you are doing is executing code that is creating objects. (a class in an object that has a new method that makes other objects). has_text is just a method that defines methods. Easy.

Friday, February 13, 2009

NetObjectives (a focus on lean development)

NetObjectives are creating some great content. I listen to the podcast. Take some time to browse their resources.

Visual Studio... can look like TextMate

At home I'm a mac user. I love my mac (although it could stand to run faster)..

Rob Conery did an ace job of styling Visual Studio to look like TextMate.

Now less electrons need to die each second with your new black background. :)

Joking aside.. looking at a screen all day is like looking at a lightbulb. It is best if you can keep things dark but clear.

Palm Pre

Wow.. what a phone!

And.. it's based on Linux.

Coverage doesn't mean anything...

... is like saying "Wii-Fit doesn't make you fit, because you can just step on and off and the game thinks you are exercising".

If you do this, you are just fooling yourself.

Coverage means nothing unless you assume you are working in an environment where developers are writing good unit test. With this assumption, suddenly it becomes a great measure of how much of the code is untested! [or in BDD lingo.. how much of your code is not required to satisfy the current set of automated requirements indicating either a requirements gap or too much code!]

100% Coverage

To my mind 100% coverage should mean all the code we as a team have chosen to test is tested.

If you decide 'generated code doesn't need tests.. as long as the generator is tested and an example is tested' .. then I say you are still 100%

If you decide 'getters and setters don't need testing' that's fine... exclude them from your coverage.

If you explicitly exclude something from your coverage statistics, then tell your tool. In NCover.. you can put attributes on the things you want to exclude.

Do that and you can get to 100%.

I'll leave the decision as to what things should be tested to the reader... for now.

GitHub Projects