Chickens and Pigs

A Pig and a Chicken are walking down the road.
The Chicken says: "Hey Pig, I was thinking we should open a restaurant!"
Pig replies: "Hm, maybe, what would we call it?"
The Chicken responds: "How about 'ham-n-eggs'?"
The Pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved."

Most people who are involved in a project are not committed. They are chickens. And while they make decisions that affect the project, they are not committed in the same way as the development team are.

The development team are the ones who are responsible for what is delivered. They are pigs. Their actions directly affect the project.

A chicken making decisions on behalf of the pigs can adversely affect the team's ability to do their job. As the chicken has no skin in the game, their decisions are divorced from the consequences.

A pig who acts like a chicken is also problematic. If they are not committed to delivery, their involvement detracts from the team's collective ability to deliver.

Branching from a Branch

In Git, everything is a branch. We branch off master for features and bugfixes. And with this, a curious case came up in our team. A feature was dependent on another feature, so he branched from the feature branch.

This strategy had one drawback. He finished before the first feature branch was finished, so merging back into master brought a lot of unnecessary code with it.

Reviewing the situation, of course this had to happen. The dependency between the two user stories required that parts of feature A were needed for feature B. And there was no way to merge feature B in without merging those parts of feature A.

In other words, this shouldn't have been an issue. Except that he wasn't prepared to take ownership of someone else's user story. That would be fair, except he tried to merge his changes that inevitably depended on the other user story.

What should have happened was that feature B should have been put on hold until feature A had been merged back to master. Or, ideally, that feature B should not have begun until its dependency (feature A) had been completed. At the very least, those parts of feature A needed for feature B should have been committed and code reviewed before feature B was merged.

What ended up happening was parts of feature A were merged into master as part of feature B, though they were ignored from the code review perspective. This is far from the ideal, and caused plenty of confusion.

An IDE is a Tool, so Learn to Wield One

In my dabbling in my youth with Linux, I learnt a few of the basic command-line commands. It was enough to get by, but I wasn't anywhere near as effective with it as my mate who had converted me to Linux was. He could do all sorts of things with ease from the command-line, while I was constrained by what the GUI would allow me to do.

I learnt the lesson that I should be just as comfortable writing code in Notepad (or on paper) as I am in an IDE. The IDE was dismissed as a crutch that poor developers leaned on.

Over the years, I've come to see that it's both wrong and short-sighted to dismiss IDEs that way.

If for no other reason, being able to code in an IDE takes away some of the more tedious parts of programming. It's a waste of energy to do things like match up every parenthesis, or to scour the code for spelling mistakes. Having syntax highlighted makes reading code so much easier. Having linked code makes drilling down through classes effortless.

There are direct advantages too. Auto-generation of boilerplate code. Autocomplete. Real time code analysis. Instant accompanying documentation. Easy refactoring. Compilation, unit test, and debugging all at the ready.

Learning the shortcuts for an IDE can make it even more powerful. With Eclipse, I take full advantage of some of the text editing shortcuts to make code entry quicker. There's just no way I'd be able to be that effective on a text editor. For most common actions, I don't even have to leave my keyboard.

That's not to say I do everything in my IDE. I find having command line batch scripts more useful for compilation. I prefer TortoiseGit over EGit for source control. But coding-wise, learning how to use Eclipse effectively makes me far more productive.

When Algorithms Test

Code needs to be tested. Sometimes that testing is best done by an algorithm.

We recently had a user story that involved removing particular characters from the application number string. The purpose was to address a readability issues - at a glance certain characters and numbers are indistinguishable, so removing the offending characters from the string they were generated from. A simple enough coding exercise.

This card, however, sat in the testing column for a long while. It didn't need to, as we had built a unit test that did what a regular tester would do - throw lots of data at the generation and see whether those offending characters were present.

An automated test, in this case, could do what a human could not: quickly generate and accurately assess the functionality. It's checked 1000 times every time the code is compiled - overkill as far as what's needed to be tested, but that overkill is computationally negligible.

Writing the unit test first (TDD) gives the developer the target to aim for, as well as creating the before and after test artefacts. At the very least, the unit tests results could supplement the functional spot-checking that would constitute normal testing for such a story.

Writing code that verifies functionality is not simply for helping developers to write better code, but can be the best tool at the disposal of the testers for doing testing. It's leveraging technology at tasks it excels, which is what we ought to be using technology for.

Book Recommendation: The Nature of Software Development

Development has more than enough to keep anyone occupied on immediate concerns. But it's worth standing back in order to reflect on what it is we are doing.

The Nature of Software Development by Ron Jeffries can best be seen as an expansion on the agile manifesto. Like the manifesto, it's high level but gets right to the point. Like the manifesto, it's concise but profound. And like the manifesto, the aim is to identify what makes for successlooks like.

What we are doing when building software is trying to add value. The word can mean different things in different contexts, but in this case it is a strength rather than a weakness.

We build software because the software will serve a purpose. We should focus on delivering that which serves that purpose, and not waste time on features that are superfluous to that.

We should develop such that there will be value if the project winds up tomorrow. The code should always be ready to deploy. We should fix problems as we go along because that makes development quicker in the long run.

There's much more to the book than I'll cover here. It's a short book, and conversational in tone, and that fits with the message the cook conveys. Deliver what adds value, and don't waste time with filler that doesn't. This book is very valuable.

90% of Development is People

When I started out in software development, my biggest concern was my lack of technical ability. Each annual review I flagged technical proficiency as an area of improvement.

After about 5 years and a few projects, I was put on an assignment with absurd deadlines on a different technology stack. This forced me to talk to people more about what I was doing. This was a gestalt moment for me, as it forced me to see software development in a new light.

Raw technical proficiency has its place, and some jobs require it - 3D engine programmers, for example. But for the enterprise work I do, soft skills matter.

The ability to negotiate matters because ideas are seldom unambiguous. It also matters in navigating what can be achieved in the face of unrealistic expectations.

The ability to foster trust matters because it's essential for team cohesion and fostering working relations.

Being able to effectively communicate matters because if we can't express ourselves to others, then we can't get our ideas across.

Being able to listen matters because others need to be able to get their ideas across to us.

And being able to put all that together matters because effective collaboration requires all those skills. A developer who can collaborate is in a far better position than one where those skills are lacking.

Shuhari: first learn, then detach, and finally transcend

From Wikipedia:

• shu (守) "protect", "obey" — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs
• ha (破) "detach", "digress" — breaking with tradition — detachment from the illusions of self
• ri (離) "leave", "separate" — transcendence — there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical

When we learn something new, the accumulated wisdom of those who came before is the best place to start. We follow what they say because they know what they are talking about. This is shu.

As we progress, we are able to identify where the rules work for us and where they don't. We are in a position to know the difference between what works and what doesn't, so breaking the rules gives us valuable feedback. This is ha.

Finally we are in a position where the rules no longer matter. We have developed through experience practices that serve us well, as well as learnt many bad practices to avoid. This is ri.