It feels like I’m starting from the top of the software stack and working down from broad specifications, creating code as I go, rather than up from fine grained models based on specific unit tests. Is this a reductionist approach?

When writing my features and scenarios I’ve noticed a tendency to follow the CRUD acronym common in data access layers: Create Read Update and Delete. The order of these processes is significant and my reasoning goes something like this……

I can’t really expect to read the contents of an entity before I’ve generated the code to create it. Now I’ve created it, I’m not going to try to edit this same entity unless I can actually read it. I can read what I’ve got, but I might want to edit those contents, and delete comes last…… because it just does, I guess the order of “UD” is negotiable, but this way it’s easier to pronounce.

You get the general picture, but this is just the approach I’ve adopted through trial and lots of error. It’s far from perfect, so how do you use behaviour to lead the code?

The Git work environment.

Working with Git is quite different to using Subversion. The actual contents of the project directory change to reflect the currently active branch: the directory contains a whole repository, not a checked out copy. Don’t get alarmed when files start disappearing only to reappear again when you switch branch.

I also noticed that I interacted with the version control less frequently when editing, delete, and create files. The interaction is saved until you’re ready to commit, making the process feel more seamless. I occasionally used to get into trouble by deleting files via the OS, rather that using the Subversion command.

For the majority of the time, I’ll use the Git commands, as I’m working in a Git repository. The git svn functionality is only needed as a Git interface with Subversion.

Getting ready to work.

I like the master branch to always reflects the current trunk until I choose to update it, so all my commits are made from other working branches.

I start by checking out a branch based on master to use as a base from which to work. I’ve imaginatively called it basework in this example, and as a branch of master it is linked to the same remote branch: trunk.

git branch -a

should display all your branches in the repository.

jkw@mac> git branch -a * basework master svn/trunk jkw@mac>

I work in increments based on stories, that’s another post, so I actually create a story branch from basework, that can be merge back into this parent upon completing the story. This helps cope with changes in the remote codebase.

Creating my working branches.

It’s a good idea to check that basework is up to date with the remote Subversion trunk before branching:

git svn rebase

This will either update the local repository with the remote changes, or tell you that the current branch is already up to date.

I’m now in a position to create my story branch:

git checkout -b inwork

The -b option is used to create a new branch and then switch to it. Without this option the same command is used to move between branches.

This same process was used to create basework.

I have my working repository structure, and I’m currently working on my story branch, see the asterisk.

jkw@mac> git branch -a basework * inwork master svn/trunk jkw@mac>

The local commit.

You can see details of the changes to the local working branch using the git status command:

jkw@mac> git status

On branch inwork

nothing to commit (working directory clean) james@cybermac1> git st

On branch inwork

Changed but not updated:

(use “git add/rm …” to update what will be committed)

(use “git checkout — …” to discard changes in working directory)

#

modified: footer.php

deleted: images/feed-icon-64.png

modified: style.css

#

Untracked files:

(use “git add …” to include in what will be committed)

#

includes/category-1.inc.php

no changes added to commit (use “git add” and/or “git commit -a”) jkw@mac>

To add the new file show in the example to those being tracked:

git add includes/category-1.inc.php

If I wanted to add all of the untracked files, I could use the -A option instead of individually naming them.

Now all the files are staged, the time comes to commit them to the local Git repository:

git commit -a -m "A message to describe the changes."

Leaving the -m option off will cause Git to request comments using whichever editor is defined in your configuration files.

I now the story is complete, and all the changes committed to the inwork branch, it’s time to commit them to Subversion.

The remote commit.

I start the remote commit process by switching to the basework branch:

git checkout basework

Next I check that the remote codebase hasn’t changed, or update the changes:

git svn rebase

I’ll merge inwork into basework:

git merge inwork

I use my text editor to manually fix conflicts that arise. Git tells you where to find them by marking up the code. This is followed by another local commit, at which point the merge is complete.

Now I can try a dry run of the remote commit:

git svn dcommit -n

It’s the -n option that makes this a dry run: nothing has been committed yet. It shows you the local versions to be bulk committed if you choose to go ahead. To actually perform the commit, remove the -n, and re-run the command, it may take a while if you’ve been busy.

Verifying the remote commit.

This is where leaving the master branch untouched pays off. basework has been committed to the remote trunk, whilst master still reflects the pre-commit trunk.

I switch to master, which should contain none of my new work, and update it from the remote trunk:

git svn rebase

It should have changed to match basework, and if so the previous commit worked.

Cleaning up.

I’ve verified the commit: I have master and basework branches that are identical, so inwork is no longer needed, I’ll delete it:

git branch -d inwork

Deleting a child branch of a different parent is a little dangerous, so if you’re not in basework you’ll get a warning. Either switch to basework and try again, or re-running the command with the -D option.

If I’ve finished work on this project, I’d delete the basework branch too, but if I’m going to continue, I’d use it to create another working branch, and I’ve gone full circle.

Personally, I’ve long been a fan of a hybrid system comprising a paper notebook; currently an A5 Red and Black, and a selection of applications on my MacBook.

My notebook goes most places with me, I could buy a smart-phone, but they are neither as rugged nor flexible as a paper notebook. Paper doesn’t impose a working structure upon me; I can sketch, write, draw up tables or whatever the occasion requires.

Combined with the camera on my phone; to rapidly capture complex information, I have everything I need to collect data for later processing. This usually takes place on my laptop where I can tag, search, and sync lists and calendars back to my phone.

A number of tips on how to customise your Moleskine notebook, remind me of features found in applications like Firefox.

• Divide sections with tabs could be interpreted as the now ubiquitous tabbed browsing feature.
• Number the pages reminds me of the practice of bookmarking.
• Mount photos – or a business card on the moleskine is one tip for customisation suggesting to me that maybe ‘bCard&trade’ is the new paper version of the common vCard format.

Lifehack is a great advocate of the Moleskine, and I too aspire to one for no obvious reason, but features like these tell me we’re on the verge of a revolution in paper technology… Paper2.0.

Define your business.

When developing business processes try to keep everything as simple as possible. Simple processes are likely to be followed: complex ones won’t. This is definitely true of written procedures, but human employees have the ability to sift through the junk and ignore it; you may not like that but it’s true.

Computers on the other hand don’t share this aptitude. Your software developers may try to ensure the software follows your monolithic procedures, but the conflicts ignored by human employees will have to be resolved; a long and expensive process.

A systematic approach to this analysis can help, especially with the inevitable documentation, take a look at business process modeling and the OMG notation.

Well implemented processes will be familiar to your staff and any software based on them equally so, saving a fortune on training.

What is success?

Now you’ve got a minimalist set of effective processes, you’re in a position to consider how the application of software and hardware systems might improve or expand your business, and bear in mind that it might not.

What will success would look like? It too needs to be defined as simply as possible if you’re going to recognise it. Frequently at the start of projects everyone is so excited that this step is lost. It is either overlooked or results in a requirements document so complex nobody can be bothered to read it.

Ask yourself how many other business purchases you would make without actually considering what you’re expecting to have delivered. Would you be happy if you were hoping for a photocopier and ended up with a filing cabinet?

Get involved.

Most organisations expect their involvement to end once they’ve specified their requirements. The developer will go away, build the software, and deliver it perfect and on schedule. OK, maybe that’s an exaggeration, but placing your staff in the development team is not an optional extra.

They’re likely to spend substantial time working closely with the developers, it’ll be worth it, you’re likely to get a better system. Most will be involved in user testing, but the customer representative is a key role representing the business interests within the team. Customers are not project managers, they are focused on the benefits to the business and its operational goals.

Primarily involve people that actually undertake the work this system is meant to enhance, and those that will continue to use it. There’s a huge temptation for senior management to attempt to fulfil this role, but they usually know next to nothing about the processes in question, so resist it. There is a vital role for senior sponsorship, but it’s not in the development team.

Resulting software will be intuitive, and the computer literate will be able to understand it based on their knowledge of their current job, and of course your procedures.

The pay back.

Get the basics right — develop good business processes, define success, and build an effective team — and your project has a much better chance of delivering satisfaction, on time, and to budget.