Where do we go from here?

I will soon be made redundant from a job I’ve held for 6 years.  Thats the longest I’ve ever been anywhere.

The last time I found myself without a job, I was terrified.  How will I keep a roof over my family’s head?  What if I couldn’t ever find another job?  The fear of the unknown was enormous, mostly because the financial pressure felt crushing and imposter syndrome loomed large.  No-one will hire me because I have no idea what I’m doing.  Perhaps I should go talk to McDonalds.

This time round however, I find myself in the enviable position of having enough of a redundancy package to keep me afloat for 6-8 months.  If I find a job right away, thats a nice lump sum that I could do something useful with, either personally or socially, but if not, 6 months should be plenty of time to find something.  Anything.  So thats the financial fear taken care of.

And so we come, as we inevitably do, to imposter syndrome.  What am I worth?  The last time I did anything other than iOS development was about 10 years ago.  My Ruby/Rails skills are out of date, my Java is ancient history and my work consulting and training with XP/Agile process is almost certainly too old school.  I have, in 10 years buried in Apple tools and technologies, failed to keep up with pretty much anything else. The changes in web technologies, in process, in buzzwords and frameworks seem all too massive.

When I did C++ for money, I did Java for fun.  When I did Java for money, I did Ruby for fun.  When I did Ruby for money I did iOS for fun, and then I kind of stopped.  Family life meant there was little time for programming outside of work, so I stopped having an eye on the new things, and which of them might be interesting as a future direction.  Back then, each transition seemed obvious.  I knew what I was interested in before I had to look for a job doing it, and each time, because I was interested and made friends in that space, I didn’t have to look hard to find a place to do it for money.

This time though I find myself a little lost.

How can I find a job with skills so out of date and irrelevant ?  I don’t know any of this stuff?  I need to buy books on Elixir and Go and a 10 volume set of Javascript frameworks.

But wait, I know how to build good software.

I know how to build good software and I’ve done it in FORTRAN and C and C++ and Java and Ruby and Lotus Notes for goodness sake and C# and ObjectiveC and Swift.

I know how to build good software and I’ve done it with UML and XP and DDD and Scrum and using Jira and Pivotal Tracker and Rational Rose and index cards.

I know how to build good software and I’ve done it for banks and startups and research labs and electrical retailers and power stations and Coca Cola and telecoms.

I know how to build good software in anything.

So.  The imposter syndrome is kicked into touch this time too.

I feel strong.  I feel ready.  I have no idea where I’m going or what I’m going to do next, but thats a blessing, not a curse.

It might, as I’ve said, be lovely to spend the next 6 months as a junior Mac developer or Project Manager or devops engineer and be the worst guy in the band.  To focus on the small and the specific.  It might also be lovely to finally take a step up into technical leadership across a small organisation.  To think bigger and work harder out of my comfort zone.

Its a magical world, Hobbes ol’ buddy.  Let’s go exploring.



The Worst Guy in the Band

In Chad Fowler’s wonderful Passionate Programmer book (which you should buy), theres a chapter called “Be the Worst”.

Legendary jazz guitarist Pat Metheny has a stock piece of advice for young musicians, which is “Always be the worst guy in every band you’re in”

Chad spins this musical advice into advice for programmers.

Being the worst person on the team has the same effect as being the worst person  in the band.  You find that you’re unexplainably smarter.  You even speak and write more intelligently.  Your code and designs get more elegant, and you find that you’re able to solve hard problems with increasingly creative solutions.

I’ve tried to make a habit of this, and so far I think I’ve succeeded.  You’d need to speak to my co-workers to confirm.  I’m looking for a change in work right now, and its got me thinking.

The advice above is essentially saying be around people who are better than you, so you’re always learning.  But there are a couple of issues with this.

Firstly, you’re good enough to be in the band at all.  Chad talks a little about this in context.  You want to be the worst guy in the first division, rather than the best guy in the second, but that assumes you have the requisite skills to be in the first division.  Secondly, it assumes some relevance or connection between you and the others.

You can become a better saxophonist by playing regular jazz with a really good pianist, drummer and bassist, assuming they let you in to their band, but what if you really want to play drums.  You can’t be the worst drummer in that band.  They already have a drummer who’s good.

Maybe you go join a drumming group.

You’re surrounded by drummers who are better than you.  You are the worst drummer and every day you work with better drummers and get better at drumming.  But now you’re a junior drummer, and you’re getting paid as a junior drummer, and you’re playing basic stuff all the time, which is improving you as s drummer, but not really stretching you as a musician.  Your expert saxophone status does not buy you recognition in that drumming group. You’re a beginner.

What you want is a bigger band.  A band that already has a great drummer, but can hire you for your saxophone skills 6 days a week and indulge your desire to be a junior drummer 1 day a week.

A couple of times in my career I’ve wanted to change direction, and both times I’ve been lucky.  My first proper Ruby job, my Java experience and Agile consulting work was enough to pay my way while I was a junior Ruby engineer working with a team of experts.  My first proper iOS job, that Ruby (and the Agile work again) was enough to justify a senior engineers position and salary while allowing me to essentially be a junior iOS guy and learn the ropes.

I’m feeling like its time again.  I’d like to be a junior something.  Maybe Mac development, maybe project management, maybe something else entirely, but I have to find the right band.  Someone that’ll happily hire my saxophone while I learn my crash from my splash.

My pencils are sharp enough

Its time I started blogging again.

I’ve had several over the years and usually end up deleting them after a while.  I used MovableType, and Ghost and Blosxom and Jekyll and all sorts of other tools.  Twitter really killed it for me.  It made it easier to throw out a thought than to sit down a craft a post. This is a wordpress site because it was quick to get working and typing.

I pulled across 3 or 4 older things I still liked, though they’re ten years old and maybe not relevant any more, it meant I wasn’t starting with the pressure of a blank slate.  Back then I was doing Java and Ruby.  These days its ObjectiveC and Swift.

So I guess I’ll see where this goes.

Smalltalk Best Practice Patterns

unknown-1In the 1990s the “patterns” movement in software was in full flight. The poster child, and many peoples introduction to patterns was the so-called Gang of Four book Design Patterns, published in 1994. Design Patterns catalogued a series of blueprints, strategies for combining classes to solve a problem, and the idea spread through the industry quickly, to point where Design Patterns become a buzzword and to some extent lost a lot of its original meaning.

But software patterns come in all different shapes and sizes and one of the people instrumental in the movement towards utilising the notion of describing software with patterns was Kent Beck. Kent is involved with many of the most important (IMO) ideas in software over the last 20 years, including object-orientation through Smalltalk, Test-Driven Development, Refactoring and our subject here – Patterns,.

unknownSmalltalk Best Practice Patterns is a collection of tiny, very specific patterns describing how Kent wrote Smalltalk. I’ve heard Kent describe how the book was written once, and I’ve tried and failed to find a reference.

In essence, when he start to write a line of code, he looked to see if he had a pattern describing what he was about to do. If yes, he used it, if no, he amended an existing one or wrote a new one. The result is a reasonably complete specification describing the choices available to him in writing each and every line of code in a program, from variable naming to inheritance hierarchies.

The power of this method was obvious to me, despite never having really seen Smalltalk before, so in order to properly read the book, I wrote to Wilf LaLonde’s JOOP column asking him for a beginners guide to Smalltalk.  He wrote one for me, and doubtless other Java programmers keen to understand how a “pure” Object-Oriented language worked

Smalltalk Best Practice Patterns is, without doubt, the best programming book I’ve ever read. Despite never having written a line of production Smalltalk in my career, it fundamentally altered how I write code in any language, forever.

Acceptance Testing Classes

I have seen a lot of unit tests in my 10 years as an XP practitioner and coach. I have also had a lot of debates about styles of unit testing. The longest running of these debates is about the role of “mock objects” in TDD.

Martin Fowler has characterised the use of mocks as “interaction testing” in that you are verifying that certain methods get called as a result of stimulating the object under test, rather than that the state of the object changed.

I don’t like this style of testing for a couple of reasons.

The first reason, which will really have to be an article on it’s own, is that it tends to make refactoring a lot harder than it might otherwise be. This is due to a lot of tests that verify specific methods are called in a specific order. The names and order of these methods can change often early in development, as well as later if a large refactoring is performed.

The second is what I wanted to talk about here.

When every collaborator of a class is mocked, it becomes divorced from reality. It is truly being tested in isolation. We verify that when this fake object pokes it in a certain way it responds by poking these other fake objects in a different way. We have no evidence (at this point) to suggest that the object will be poked in the same ways in production.

What we end up with, I think, is a set of acceptance tests for an individual class.

When I mind map this I end up with “waterfall”. We are designing and building and acceptance testing a class in isolation, and increasing the cost of change of that class. We lose a holistic view of the system and are discouraged from refactoring, especially across classes. The software becomes less soft.

Dials to Eleven

Movements arise in context. For people to gather around a shared social, artistic or aesthetic ideal, they usually need some other social ‘norm’ to distinguish themselves from. Movements are as much about what they’re against as what they’re for.

Now, that context may not be responsible for the birth of the idea, but I think it is responsible for turning someone’s idea into a movement, shared by a number of people.

In the case of Extreme Programming, the process was not ‘created’ by Kent Beck as a reaction to RUP. RUP wasn’t the problem at C3. As far as process is concerned, XP primarily addressed shops with no process. But by defining XP as the anti-RUP, the community turned XP from an idea into a Movement. Giving the idea a concrete enemy, enables people to get behind it and take it to the next level.

Ruby on Rails, another example of a movement in software, was born (so the story goes) from David Hansson’s frustration with PHP. Yet again, however, it’s J2EE that defines Rails as a movement. So, in both cases, a transforming idea comes along to bring more discipline to a chaotic environment – no process, or PHP development. In each case, however, what came to define the technology was the larger, more complex (theoretically more disciplined) approaches to process and software architecture. – RUP and J2EE.

In both cases, I see a lever. RUP has it set full on ceremony and documentation. We know we need to ease back on that, but why pull the lever all the way over the way XP does ? In the case of Rails, surely we can get lighterweight than a full J2EE stack without ditching all of the configuration and flexibility ? Why do we need to go for such a constrained solution as Rails ? Why not Spring ?

What’s interesting about that lever is that it’s spring loaded. If we pull it 90 degrees, it snaps back to 45. When we try and reduce the documentation in our process, if we try and drop 10% we’ll end up with only a 1% reduction, or maybe none at all.

XP understood this and set out to pull the lever all the way over (knowing that it would slip back eventually). By saying ‘all code must be pair-programmed’, it sets an ideal that we’re pretty sure can’t be adhered to all the time, but we set the dials to 11 knowing we might hit 9.

The same hold for Rails. When we take the J2EE stack and try and slim it down, maybe using Spring or something, we still end up with thousands of lines of XML. The only way to really change things is to pull the lever all the way over, set the dials to 11, no configuration, no XML, no flexibility.

The Extreme approach can really change things in a way that the softly-softly approach never will.

Redefining Simple

One of the main tenets of Extreme Programming is that we should strive to produce ‘simple code’. Sometimes code is written simply from the outset, other times code needs to be refactored until it is simple. In either case, it’s necessary to have a working definition of simple to code or refactor to.

Luckily, XP provides us with a definition.

‘Simple Code’ meets the following criteria (this is an ordered list).

  1. Passes all the tests
  2. Communicates it’s intent
  3. Contains no duplication
  4. Has the fewest possible number of classes and methods

It’s probably worth discussing each of these in turn.

First off, we’re not done if the code doesn’t pass our tests. Since we’re Extreme Programmers, we code test-first, and have a suite of unit tests for any particular piece of code we’re about to check in. If we can’t get here, we shouldn’t even bother looking at numbers 2-4.

Secondly, communication. This is somewhat subjective, but in essence we’re looking for good names for methods and variables. Descriptive, and in keeping with any system of named we have in place. Perhaps all our controllers are called XXXController, perhaps the return variable from any method is always called result. The other thing I think is important here is reasonably short methods.

Number 3, like our first item seems pretty black and white. Either there’s duplication or there isn’t, right ? But discussing the different kinds of duplication is a whole other article. We’re looking for both straight textual duplication, but also duplication of intent. Duplication is a bad smell in our code and it’s important that we stamp it out whenever we can.

The last item in the list is almost an tiebreaker. Given two different approaches that meet the first 3 criteria, choose the one with the least amount of code. It’s an ordered list, so communication trumps size here.

Now, this (I think) is a pretty decent working definition. It has some fairly concrete guidelines (not rules) to code against and I do like the results I get when I work consciously with them.

But it’s only one definition. Over time I’ve run a few experiments, trying out different ‘rules’. Seeing what happens to code if they’re followed religiously. One that I want to talk about here is named for it’s Java implementation : No braces.

What would happen if the only braces we allowed in our Java source was to scope classes and methods. What would the code look like ?

Here’s a simple little example, somewhat adapted from Martin Fowlers canonical Refactoring example.

public void statement( RentalList rentals, User user,
PrintWriter output, boolean headerRequired )
if( headerRequired )
output.println( "========== STATEMENT ===============" );
output.println( " Username: " + user.getName() );
output.println( " Date: " + new Date().toString() );
output.println( "====================================" );
while( Iterator i = rentals.iterator(); i.hasNext() )
Rental r = (Rental)i.next();
output.println( "Title:  " + r.getTitle() );
output.println( "On:     " + r.getRentDate() );
output.println( "Cost:   " + r.getPrice() );
if( r.earnsPoints() )
output.println( "Points: " + r.getPoints() );
totalPoints += r.getPoints();
output.println( "====================================" );
output.println( "Total Points: " + totaPoints );
output.println( "====================================" );

Here’s what I ended up with following my rule.

public void writeStatement(PrintWriter output, RentalList rentals,
User user, boolean headerRequired)
writeHeaderIfNecessary( output, user, headerRequired );
writeRentals( output, rentals );
writeFooter( output, rentals );

private void writeStatementHeaderIfNecessary(  PrintWriter output, User user  )
if( headerRequired )
writeHeader( output, user )

private void writeHeader( PrintWriter output, User user )
output.println( "========== STATEMENT ===============" );
output.println( " Username: " + user.getName() );
output.println( " Date: " + new Date().toString() );
output.println( "====================================" );

private void writeRentals( PrintWriter output, RentalList rentals )
while( Iterator i = rentals.iterator(); i.hasNext() )
writeRental( (Rental)i.next() );

private void writeRental( PrintWriter output, RentalList rental )
writeRentalDetails( output, rental );
writePointsIfNecessary( output, rental );

private void writeFooter( PrintWriter output, RentalList rentals )
output.println( "====================================" );
output.println( "Total Points: " + rentals.getTotalPoints() );
output.println( "====================================" );

private void writePointsIfNecessary( PrintWriter output, Rental rental )
if( rental.earnsPoints() )
output.println( "Points: " + rental.getPoints() );

There are, overall more lines of code, but what we end up with is interesting in a few ways.

The first interesting thing, I think, is the method length. A lot of very small methods, none really over 2 or 3 lines long. Each method does exactly one thing. It’s a decision, a loop or a small set of sequential steps bundled into a ‘job’.

The second interesting thing is that those ‘job’ methods are written at the same level of abstraction. We don’t see writeHeader() followed by all the guts of writing the body. Instead we see header, body, footer.

The third interesting thing is that we’ve eliminated all temporary variables. A useful side effect is that it becomes much more apparent when methods can or should be moved between objects. The total points in the above example seems like it needed moved to the RentalList. One more temporary variable eliminated.

Now, there’s obviously a few criticisms to be levelled at code like this. Where’s the work done? Why do I have click all over the place to figure out the flow of the application? I’ve heard it described as ‘ravioli code’ (as opposed to spaghetti). Interestingly, large chunks of Smalltalk are written like this. It’s quite a common coding style in dynamic languages, although the loop method calling a singular method would most likely be done with a block.

The advantages, however all depend on good names for the methods in question. With good names, someone reading the code shouldn’t have descend the method hierarchy very far to get the answers they seek.

If we’re interested in something in the statement footer, we can click into writeStatementTo() and into writeFooterTo() we don’t need to be bothered with all the implementation detail of the header and body. It’s not relevant except to understand that they are printed before the footer. Or inside the writeHeaderIfNecessaryTo() we can see a decision is made on whether to print the header. If all we care about right now is how that decision is made, and not the actual printing we can see that clearly.

One of the design techniques I was taught in college was Jackson Structured Programming. This was focussed mostly on COBOL, and it’s strategy was to turn a Data Definition into a Program Definition. The diagrams for these definitions were box-and-arrow style, with boxes representing SEQUENCE, SELECTION and ITERATION. Sound familiar?

I like this code style. I know it’s a bit extreme, but I’m an extreme programmer so that doesn’t frighten me. It makes my code really, really simple and obvious. Each piece laid out in terms of others. Iteration or Selection logic separate from what happens based on that logic.

Extreme Programming is based on turning the dials up to 10 on a lot of practices and then dialling down only where appropriate, so I like the idea of challenging myself by trying a coding style all the way. I’m almost certainly not going to write all my production code that way, as sometimes code gets seriously contorted to meet the ‘rule’, but it’s a useful exercise.

Perhaps you have your own ideas of what simple might mean? What would happen if you tried to put those ideas into practice ? What would happen if you tried to completely eliminate all temporary variables? Or set a hard limit on method length of, say, 5 lines? Try it. You may not want to code like that all the time, but I guarantee you’ll learn something about your code and maybe even yourself.

Thinking Tools

Extreme Programming is pretty silent on how features (which we call UserStories) are gathered. It only speaks to how those features are scheduled and planned.

This is often considered a hole in the process.

When sitting with a client, figuring out what XP will mean to them and how it maps to their current process, this question often arises.

It could be a prototype, it could be user flowcharts, it could even be an existing system. Whatever it is, it’s essentially outside the scope of ‘XP’ and so people assume that means they won’t be allowed to use them any more.

I beg to differ. The fact that XP doesn’t address these things is because they’re going to be different for each and every organisation, even projects within that organisation. This is good news for you, because it means you can just keep doing what you’re doing if it works for you.

What might change, however, is how much reverence you attach to the artefacts produced by these tools.

Each of the things above, and no doubt may more besides, are “thinking tools” for an XP Customer, just as CRC cards, or BAML and a whiteboard are to the development team, or MS Project is to a Project Manager.

The tools themselves help you organise your thoughts. They help you think about the problem at hand. Who could argue with using a tool that helps you?

There is a problem, however. An MS Project plan or a prototype, unlike a scribble on a whiteboard, carries with it an air of permanence. All the artefacts produced from your thinking tools reflect the your view of the world and your understanding of the problem at the specific point of use.

However, the map is not the territory. The territory can change, and suddenly the map is out of date.

The boxes and arrows are not the design, that’s in the code.

Plans are worthless, Planning is essential.

And the prototype/flowcharts are not the requested feature set… that’s in the code we’ve got now and the User Stories we have written but not yet implemented.

The map only reflects the territory at the time the map was drawn. The design diagram details what the code looked like, or you plans for what it will eventually look like at the time when it was created.

Every iteration, the structure of the code will change and invalidate the diagrams. The customers understanding of what they want and what’s possible will change and invalidate the prototype or the flowcharts.

This is a Good Thing, as it make it much more likely that well end up where we want to, rather than where we thought we’d want to.

So go ahead, make your prototype. Plan your Customer Journeys and Interaction Designs. But don’t spend too much time on them, they’re just a transient tool to help you figure out what the stories are. And don’t be afraid to throw them away, they’re probably worthless after a couple of iterations anyway. You’ll have figured out new cool stuff to build, and new ways to do things.