I started with a simple Git clone of the trunk branch. This was where I
was doing most of my work and since I was just starting out seemed like
a simple option.

The

git svn clone http://repostiory/path/trunk

operation took quite
a while. The project had been active for about 6 months and a lot of
developer effort had gone into refining the code. Git checks out every
revision from the repository for the branches that have been requested
(trunk in this case). The initial checkout turned out to be unreliable
but I don’t this that this was git. Fortunately it is simple case of
either

git pull

or

git rebase

to restart the
initial clone.

Once I had all the code and revisions on my laptop it took a while to
get used to the huge number of commands available with git. For a lot of
the time my development cycle was fairly simple

git rebase
...write a test...
...make it pass...
git commit -a -m "comment"
git svn dcommit

Which was one more command than my usual subversion development
cycle. The key advantange for me was being able to do most things
offline without access to the repository. Then when I had access to the
repository I could rebase and merge my changes with those of my
colleagues.

Recently we have been working off two branches: a release branch for
production changes and the main development trunk branch.

For simplicity I initially created a new clean git clone of the release
branch and this worked fine for a while as long as most of my work was
on one branch or the other (at this stage mostly keeping up with the
code changes made by the team).

The need to keep merging changes from one branch to the other lead me to
believe that I had outgrown this simple cloneing model. After a little
research I realised I could create a single close with all the branches
I needed with:

git svn clone http://repository/project -T trunk -b branches -t tags

This took just a little longer than the original process but left me
with a complete set of branches and tags in my local repository.

git branch -a

lists the available branches.

It is worth noting that although these are listed as branches and tags
they refer to the remote repository and it is not possible to switch to
a branch with a native git command.

Switching between these remote branches requires a checkout:

git checkout branch-name

Next: Voyages in local git branches…

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp

At first glance this priciple this seems straightforward but it is
amazing how much code – including libraries which find it difficult to
be true to this principle.

Lets consider simple iteration over a collection. In java and C# the
convention is to implement and iteration class for a collection that
maintains the state of where the calling is in iterating the items in
the collection.

Using this iterater either explicity or implicity requires access to the
internal state of the iterator typically through getters.

while (iterater.hasNext())
      item = iterator.next();

This knowledge of the internal state within the calling code couples
both the calling and called code together.

This is one of the reasons I like Ruby as a programming language. It
makes writing this style of code straighforward

collection.each do |item|
       puts item
end

The iteration state is nicely encapsulated in the each method and the
ony thing the calling code knows is that the each method calls the
supplied block for each item in the collection.

It is possible to write this in Java and C# but these implementations
are more complex and verbose than the Ruby implementation.

If you have not tried ruby yet its worth checking out.

[SHARP]Sharp, A. “Smalltalk By Example”McGraw-Hill, 1997.

It was a good intention but I have the most annoying habit of becomming
completely absorbed in the ‘current project’. For the project this is no
bad thing. I am typically asked to take on a technical leadership role
and there is always more that needs doing to improve things. So the
‘current project’ takes over my life.

I have struggled with this over the years but not found an effective
remedy to create a more work life balance. I am still struggling to
create that balance. I am beginning to think that perhaps it is just the
way that I am but that does not mean I should not continue to find that
balance.

I guess one of the problems is that I love what I do
for a living.

During those 20 years I sometimes wondered what life was like outside my
safe environment but then the next project would come along and I would
forget about the possible alternative futures and become engrossed in the
latest challenge. The cycle happened a few times but there were not
strong motivators for change. In 2004 economic pressures took their tole
and I was forced to make a change. Interestingly it was probably the
best thing that could have happened. After 20 years honing my skills I
was let loose on the consulting world – and somehow everything just
clicked.

If you are in a similar situation – I understand how scary it feels but
sometimes it really does work out for the best.

One of the sayings I hear quite often is ‘don’t prematurely optimise’. Whilst I agree with this in general like everything taken to an extreme it can lead to some unwanted effects.

Taking the prematurely optimise but measure and and then optimise can mean that people stop writing efficient code and worse almost deliberately write inefficient code – it is easier to do several string manipulations one at a time than scan a string once. Sometimes this is fine but within the context of a text heavy high request rate web site these things can be a real bottleneck.

So during your next refactoring cycle – think about the performance of the code you are changing as well as how well it reads and fits in with the architecture. Not a lot of time but just stop and say is this code reasonably efficient.

A lot of people including myself tend to ignore the hard disk performance and look for processes eating up CPU or applications that are too hungry for memory when we feel that our computers are not running as quickly as we remember. These are valuable checks but once you have failed to find that memory eating clock cycle hungry application we tend to stop and think that all is well; but just about every application running on the computer requires the disk and performs disk operations. The faster your disk the faster your computer can do the work you want it to do.

So after 3 years of daily use a colleague recommeded I try iDefrag from Coriolis systems. Running the online defrag (online being that the disk is is use) did not yield a noticable difference.

Fortunately the software also comes with a tool to burn a bootable disk to enable offline disk defragmentation. Once the DVD was burnt I rebooted to the DVD and first ran a consolidation to maximise the amount of contiguous free disk space.

I left the machine to its own devices and returned in the morning to see what a difference it had made. The responsiveness to loading application – even simple ones was immediate and obvious. My whole machine felt more responsive and any operations involving disk IO felt nice and fast.

Last night I ran an ‘Optimise’ defrag which resulted in nice solid blocks of non-fragmeted files at the start of the disk and a nice clean block of free space ready for me to use. I have not noticed a further improvement in performance – but the first improvement was well worth it.

Test driven development (leaving out the source control bits) has three steps:

• Write a failing test
• Make it pass
• Refactor

That final ‘Refactoring’ step is where the craft is applied and is often the first thing to come under pressure when the deadline of delivery looms

This reaction to pressure is completely understandable and I know I tend to empathise with the client/customer and push that little bit harder and longer to deliver the asked for functionality.

The temptation to move on to the next feature when the test passes can be very strong. After all the software now behaves correctly and could be made available to the end user where it can be making money.

The fact that the developed code may not fit with the overall architecture, project coding styles etc. or may not perform well enough is not a functional consideration.

Refactoring is also difficult to quantify. Software developers have this need to ‘tinker’ with the code. This tinkering can be see to be very similar to refactoring. After all the code still behaves the same way to the outside observer.

A key ingredient in all of this is spending time gaining trust in the team that the work is required. Not focusing in on the refactoring task during development has and I am sure continue to be a significant factor in why projects do not perform as effectively as people had hoped.

There are no hard and fast rules around how much time to spend refactoring the codebase. Is it 10% of the time taken to implement a new feature? 20%? 30%? We all try to come up with formulaes to help guide our decision making but I have not managed to come up with a good one for refactoring

For me there is an internal barometer for technical debt. When the pressure gets too high I start to feel very uncomfortable and the need to sit down and ‘sort it out’ plays on my mind. This inner barometer is something born of experience, from tough projects and late night working. Keep an eye on your own internal barometer – quite often it is telling you something very important.

And then I came across the Software Craftsmanship Manifesto. A well thought out set of principles in the Agile Manifesto style. If like me you care about your craft why not add your name to the list?