Sharktank Labshttp://sharktank.co.uk/articles2014-03-21T14:46:00ZThe most frequently asked questionhttp://sharktank.co.uk/articles/pair-programming/2014-03-21T14:46:00Z2014-03-21T14:46:00Z<p>We have been on a bit of a hiring spree recently. As part of the hiring
process I try to make sure the candidates know what they are getting into if
they join our group.</p>
<p>“We do virtually all of our work using TDD and spend 80-90% of our time doing...</p><p>We have been on a bit of a hiring spree recently. As part of the hiring
process I try to make sure the candidates know what they are getting into if
they join our group.</p>
<p>“We do virtually all of our work using TDD and spend 80-90% of our time doing pair
programming. How do you feel about that?”</p>
<p>On hearing this, many candidates shuffle uncomfortably and glance furtively
around the room. “You don’t actually do that, do you? The pair programming
thing, I mean.”</p>
<p>This is probably the question we field the most from candidates in our
interviews. Indeed, we do use pair programming almost all of the time. What’s
more, even though there is a lot of peer pressure to pair, nobody is forced to
do so on our team.</p>
<p>While pair programming has gained some acceptance in the industry lately, it
still isn’t pervasive. Many people have experimented with pair
programming to help solve tricky problems, or to get introduced to a new area
of code, but relatively few people have tried pair programming over a number of
contiguous days. “Isn’t it slow and wasteful?”, they often argue.</p>
<p>Pair programming on a regular basis is a very difficult discipline. It requires
a set of skills that many programmers have not had much experience with. It
also requires a significant amount of practice before one can do it well. Once
proficient at it, though, a good pair can perform both better and faster than
two people working alone.</p>
<p>I think one of the biggest problems that beginning pair programmers have is
that they view the discipline as merely a continuous code review. They refer
to the non-typing party as the “observer” whose role is chiefly to catch
mistakes. If one does pair programming in this fashion, I think it
is understandable to see the observer as being something akin to a
very expensive spell checker. Are they actually doing anything that can’t
be done more cheaply with code reviews?</p>
<p>At the risk of being controversial, I will say that catching errors is not one
of the benefits that I am looking for when pair programming. Don’t get me
wrong, I value the extra set of eyes when pairing, but for me this is the
smallest benefit you get. In fact I see pair programming as a way of
significantly improving the speed that a team can generate code. There are
several areas where this improvement can happen: communication,
separation between coding and planning, and a programmer’s ability to concentrate.</p>
<p>First and foremost, pair programming fosters improved communication. A team
will always have disagreements about design and coding style. When pair
programming, you always have immediate feedback for your ideas. Conflicts are
brought out early rather than left to fester. Importantly, controversial code
doesn’t get a chance to become entrenched in the code base. Because feedback
is immediate, you avoid the situation where you are forced to accept something
simply because it is finished and rewriting it will take too much time.</p>
<p>Our team actually does code reviews <em>and</em> pair programming. A pair has a much
better chance of getting controversial code through a review than a single
person does. Having at least one other person listen to and understand the
reasons for doing something makes it easier to explain to others. This saves a
huge amount of time and enables the team to bring on new techniques that might
otherwise be too controversial to accept otherwise.</p>
<p>One of the things that people ask me once I have asserted that we really,
actually pair program is how to do it effectively. Probably the best way to
learn pair programming is to do <a href="http://c2.com/cgi/wiki?PairProgrammingPingPongPattern">Ping Pong
Programming</a>. It is a
simple technique where one person writes a failing test and the next person
makes the test pass. After making the test pass, the second person writes
another failing test and hands the keyboard over. Just keep doing this over
and over again.</p>
<p>As this technique is best suited for development of new features, it works
extremely well when doing katas for practice or fun. In fact, if each person
tries to do the least possible work while simultaneously trying to force the
other to do the most possible work, it makes excellent TDD practice. There are
many places on the internet where you can find good katas. We had a lot of fun
doing the katas on <a href="http://www.cyber-dojo.com/">cyber-dojo</a>, though it appears
to be down as of this writing.</p>
<p>Ping pong is an excellent exercise for ensuring that both parties get equal
access to the keyboard and are engaged in the process. It is not the best
technique for all situations, though. Many times it is better to use a
driver/navigator approach.</p>
<p>I often think about this style of pair programming as being similar to the
driver and navigator in rally car racing. A rally car race is a stage race
where participants drive a long course, usually on normal roads. It is
impossible for the driver to memorize the entire course, so a navigator
accompanies him. The driver’s job is to drive as fast as humanly possible
without crashing. The navigator’s job is to plan ahead and warn the driver of
upcoming corners or difficult areas. Usually the navigator uses some kind of
code to tell the driver which gear he must use, or how fast he can take the
corner. The advantage of having a navigator is that the driver can drive
<em>much</em> faster than they could if they were driving alone. The driver is freed
from thinking about what is coming up and can devote their entire attention to
driving quickly.</p>
<p>In driver/navigator style pair programming, one person, the driver, is in
control of the keyboard. The driver’s job is to write code, while
concentrating on the task at hand. The other person is the navigator and their
job is to plan further ahead, keeping notes for possible upcoming work. Often
the navigator will keep the big picture in their head and plan what needs to be
done. When the driver finishes a section of work the navigator can take over,
having already come up with an idea of how to tackle the problem. This
separation between coding and planning allows the driver to code much faster,
as they can rely on their partner to plan for upcoming potential problems.</p>
<p>Whichever way one does it, one of the main benefits of pair programming is
improved concentration. I imagine that every programmer has experienced “white page
syndrome”. When you have a problem that you must solve, but don’t know where
to start, sometimes it seems too daunting and you just stare at the blank page
wondering what to do. Other times, programming can simply be lonely and
boring. Having someone beside you who can cheer you on is an amazing aid.
When one person is feeling down, or listless, the other person can help them
over the hump.</p>
<p>Many people have heard of the <a href="http://c2.com/cgi/wiki?MentalStateCalledFlow">mental state called
flow</a>. Getting into a flow state
and maintaining it is essential for a high pace of development. Lately, however,
there have been a few blog posts about the <a href="http://blogs.msdn.com/b/eric_brechner/archive/2013/12/01/the-flow-fallacy.aspx">potential downsides of encouraging
flow.</a>
One of the great strengths of pair programming is that the navigator is often
not in the state of flow. In fact, the navigator is often interruptible and
can respond to outside demands while the driver carries on with the current
task uninterrupted.</p>
<p>I often tell people that good pair programming is incredibly taxing. It’s
actually important to remember to take breaks. Often I find that I will go an
entire morning without looking at my email or doing anything other than
concentrating on programming. Several of us use the <a href="http://en.wikipedia.org/wiki/Pomodoro_Technique">Pomodoro
Technique</a> to ensure that we
take a break at regular times. Even so, I am grateful for XP’s <a href="http://www.sustainablepace.net/what-is-sustainable-pace">Sustainable
Pace</a>, because by the
end of the day, I’m finished and not fit for programming any more.</p>
<p>As I said earlier, good pair programming is very difficult. I find that it can
take up to 6 months for a team to learn to do it well. Even then, it is quite
easy to find ways to improve your skills dramatically after that. If you would
like to learn pair programming, the most important thing is to stick with it
and practice. <a href="../what-is-a-coding-dojo/">Coding Dojos</a> are a great way to
meet experienced people who can show you pair programming. There are coding
dojos in many countries and it is worth seeking them out. Even if you can’t do
pair programming on a regular basis in your day job, setting up a coding dojo
for practice can help you develop your pair programming skills.</p>
Trust me, I'm Agilehttp://sharktank.co.uk/articles/trust-me-im-agile/2014-03-13T18:09:00Z2014-03-13T18:09:00Z<p>It was one of those discussions that start as something else. We were not more
than a couple of weeks into our initial rollout of a new web app to the
company’s sales team. “They’re sales people”, said our Customer Proxy, “if they
don’t trust the numbers...</p><p>It was one of those discussions that start as something else. We were not more
than a couple of weeks into our initial rollout of a new web app to the
company’s sales team. “They’re sales people”, said our Customer Proxy, “if they
don’t trust the numbers from the system, they won’t use it”. This was a
problem for us, because rapid adoption is essential to our process: without it
we can’t get the feedback we need to develop the right thing.</p>
<p>So the discussion turned to what we could do to get the users to trust the
software, and from there drifted into the question of what it means to trust a
computer system. This piqued my interest, as I was aware of the importance
of trust within a team, and between a team and its customer, but had never
thought about the idea of <em>trust</em> in the product itself.</p>
<p>Thinking that the collective wisdom of the Agile community might be able to shed
some light on this idea, I started with a quick web search, and found
<a href="http://twitter.com/rachelcdavies">Rachel Davies</a>’s excellent post on
<a href="http://agilecoach.typepad.com/agile-coaching/2010/08/building-trust.html">Building Trust on Agile Teams</a>. </p>
<p>Rachel’s post reminded me of something I hadn’t thought about since Uni,
<em>The Trust Equation</em>, as described by David Maister, Charles Green and Robert
Galford, in their famous book
<a href="http://www.amazon.co.uk/exec/obidos/ASIN/0743212347">The Trusted Advisor</a>.</p>
<h3>The Trust Equation</h3>
<blockquote>
<p><img alt="T = ( C + R + I ) / S" src="http://mathurl.com/obvxku8.png" /></p>
</blockquote>
<p>The Trust Equation tells us that the factors involved in <strong>T</strong>rustworthiness
are <strong>C</strong>redibility, <strong>R</strong>eliability, <strong>I</strong>ntimacy and <strong>S</strong>elf-orientation.</p>
<p>Now this certainly seemed <a href="http://knowyourmeme.com/memes/this-is-relevant-to-my-interests">relevant to my interests</a>.
It’s easy to think of the <em>credibility</em> of a software system, and we talk all
the time about how <em>reliable</em> a system is, but then we dip into less clear-cut
territory. While there might be occasions when people feel <em>intimacy</em> for a
computer system, it didn’t seem tremendously work-related. And I’m quite happy
that our product doesn’t have a sense of <em>self-orientation</em> yet, because I’m
not quite ready for that level of responsibility (Just ask my husband, there’s
a reason that <a href="http://www.amazon.co.uk/What-Expect-When-Youre-Adopting/dp/009192412X">this book</a>
has sat unopened on our coffee table for over a year).</p>
<p>So, if the trust equation doesn’t help me to understand how our users will come
to trust our system, is it any use to me? Well, here’s where it gets
interesting. We’re a full <a href="http://en.wikipedia.org/wiki/Extreme_Programming">Extreme Programming (XP)</a>
team, with on-site customers, and XP tells us that if our customers trust our
process, and engage in it, this will allow us to produce higher-quality software.
So perhaps in XP, we have to see trust in the process, and trust in the product
as being tightly coupled.</p>
<p>How do we get our users to trust the process? I got to thinking that maybe the
trust equation could help me here, and decided to look at each of the components
in turn.</p>
<h3>Credibility</h3>
<p>Credibility means the quality of being believable: worthy of trust. For our
salespeople to trust the numbers coming from our system, the numbers had to be
credible. For our customers to trust our process, and us as a development team,
they have to be able to believe that we are a team capable of delivering what
they need.</p>
<p>The surest way that we’ve found to help our customers believe that we are
capable has been to open up our process to them. By enabling them to see the
ways that we work, they can better understand the logic behind the things that
we do. Involving the customer in the process is of course a key tenet of XP.</p>
<p>In XP, we make a real effort to break work down into manageable, achievable
chunks, and define clear success criteria for each. When we let the customer
see this process, they come to associate our team with an ongoing chain of
successful deliveries, rather than seeing us as working on huge project with
a delivery date far in the future. </p>
<p>How did we tackle the problem of getting salespeople to trust the numbers from
the system? Well, we showed our work! The system does a number of calculations,
and we decided to display more of the values from intermediate steps, so that
salespeople could check our working.</p>
<p>The common element here is openness: both openness in the process by showing
the customer how we work, as well as openness in the software by exposing
information to help build trust. I also think that it shows us that the
value in stories may not always be pure monetary value, but that some stories
may be valuable because they help to build trust in the process, or trust in the
product.</p>
<h3>Reliability</h3>
<p>Reliability in a software system is easy to define - a reliable system produces
consistent results, and is not prone to failure. It doesn’t crash all the time!</p>
<p>The safety-first approach of XP makes this much easier to achieve. By focusing
on eliminating all known defects before proceeding with new functionality, we
have found that we’ve dramatically improved the reliability of our software.</p>
<p>The perception of reliability is significantly helped by close
communication with the customers, and keeping the feedback cycle short. This
gives them the confidence that when they do find a problem, it will be fixed
quickly. </p>
<p>For the team, reliability means the customers need to trust that we will
consistently deliver what we promise to. This means that it is extremely
important to be seen to be delivering in a timely fashion, in line with our
estimates. XP helps us again here, as using velocity means we can be very
confident that our estimates will be accurate in the short term. Customers come
to realise that when we tell them a feature will be delivered in the next
sprint, they can rely on it being delivered.</p>
<p>As a side note, one of the important things I’ve noticed is that this effect
will be maximised if the Agile process is seen as the way to get things done.
This means that there have to be no ways to “cheat” and win by going around the
process. One of the ways we helped to stop people going around the process
was to remove the phones from the developers' desks. If I had to pick the
single change that has made the biggest impact on my daily life, that would be
it!</p>
<h3>Intimacy</h3>
<p>Intimacy might seem like a strange concept to be talking about in this context,
but it means the degree to which the customer feels secure in sharing with us.
An important factor in this is the customer’s belief that we understand and
care about their needs and requirements.</p>
<p>Our planning process helps us a great deal to build this intimacy. Customers
take an active role in building the stories, defining the goals and acceptance
criteria, and prioritising the work. This allows them to feel, correctly, that
they are an important part of what guides the project.</p>
<p>Another way that we’ve attempted to build common understanding is by
developers shadowing salespeople on an ordinary working day. The developer
sits next to salesperson, observes their work, interacts, and asks questions.
This is in addition to the regular cycle of demos and planning, and it has
proved to be well worth the time spent. By doing this, we have not only
gained the confidence of the customers, but we’ve also had several valuable
“Aha!” moments, which wouldn’t otherwise have happened.</p>
<p>I think this shows us how important it is to involve developers closely in
customer communication, rather than delegating this task solely to a product
owner or customer proxy.</p>
<h3>Self-Orientation</h3>
<p>Self-Orientation is the only one of the components of the equation that we
aim to minimise, rather than maximise. If customers perceive us as seeking our
own goals, rather than having common goals with them, this will diminish trust.</p>
<p>A very useful tool in our Agile toolkit is the prioritised backlog. In this,
we attempt to prioritise higher the work which will deliver the most value.
When we involve our customers in the prioritisation process, we help to build
trust that we share common goals. Of course, when we have many stakeholders,
managing the conflicting priorities can be a challenge, which is why it’s vital
that the process be transparent. It’s much better that a customer understands
why their requirement isn’t a high priority, rather than thinking “The
developers never give me what I want”.</p>
<p>Something that has hindered us in the past is that some of our customers were
disengaged from the development process because they felt that their needs were
always a low priority. To tackle this, one thing we’ve tried is for developers
to have informal chats with various customers, outside of the regular
prioritisation process. This is something that our CTO likes to do quite often.
He finds that having an overview of the ideas that our customers have can often
give us an opportunity to find the “quick wins” that will enable us to deliver
value without a lot of development work. </p>
<p>The thing to remember here, is that it’s not always clear to users what is easy
to implement, and what is hard. They often won’t suggest features that would be
useful because they think they will be too difficult. By regularly talking to
them and trying to spot these hidden ideas, we gain a lot of insight for very
little effort. </p>
<p>When these ideas are identified, it can be worth doing some development work to
explore them. We try to set aside some time in each sprint for these <em>spikes</em>.
Development work on a spike is time-boxed, and doesn’t have to be done by
Test-driven or Behaviour-driven development (TDD or BDD). The output of a spike
might be nothing, or might be new stories which can be better prioritised given
our better understanding of the problem. Sometimes a spike will be done using
TDD, and the output will be a new feature in trunk or a standalone piece of
software.</p>
<h3>Trust Me, I’m Agile</h3>
<p>What did I discover in my little foray into the world of trust? I discovered
that trust between customers and the development team is critical for XP to
work. I also found that XP gives us many tools that help us to increase this
level of trust.</p>
<p>We can build our <em>Credibility</em> by making our process as open and transparent as
possible, and helping our customers to understand what we do. The <em>Reliability</em>
of both our software, and our team, is improved by XP’s safety-first approach.
By building a common understanding with our customers, via techniques like work
shadowing by developers, we can improve <em>Intimacy</em>. Lastly, we can reduce the
trust-diminishing effects of <em>Self-Orientation</em> by communicating well with our
customers to help them understand the common goals that we share.</p>
How I got into programminghttp://sharktank.co.uk/articles/how-i-got-into-programming/2014-02-25T15:00:00Z2014-02-25T15:00:00Z<p>I have been working as a software engineer at Sharktank for 2 years. I write
Ruby and JavaScript, Python and Go. I’m an Agilist, a pair-programmer, and a
test-driven-developer!</p>
<p>I also didn’t buy a computer until I was in my late twenties. I still...</p><p>I have been working as a software engineer at Sharktank for 2 years. I write
Ruby and JavaScript, Python and Go. I’m an Agilist, a pair-programmer, and a
test-driven-developer!</p>
<p>I also didn’t buy a computer until I was in my late twenties. I still can’t
tell a motherboard from a microprocessor, and I’ve never played Call Of Duty.
Or Halo. Or any other computer games for that matter :)</p>
<p>Most of my colleagues studied computer science at university and have
had their heads buried inside a computer since they were teenagers. My degree was
in Politics, and I spent the first 7 years of my career working in a marketing
department.</p>
<p>People are usually surprised when I tell them that I’m a computer programmer (I
think they’re expecting me to say “accountant”, or “something to do with
insurance”), and I perhaps don’t fit the stereotype, but having been in the
industry for a few of years I can hardly imagine ever having considered anything
else.</p>
<p>It’s certainly the thing I’m best at and was most suited for, and I often wonder
how many other people there are who would love programming if they
had the opportunity to find out.</p>
<h2>Why didn’t I think of it before?</h2>
<p>It was just never a consideration for me. I was not interested in computers
when I was younger, and I dropped IT at school as soon as I could. I stand by
that decision, if I had to do the kind of assignments we did in school today, I’d
drop it all over again!</p>
<p>By the time you leave school the choices you’ve made have already funnelled you
in a particular direction. I had no idea that a job in IT was ever an option for
me. You need a degree to do that right?</p>
<p>Like many of my peers I didn’t have a good idea of what I wanted to do when I
left university. It must be a strange thing to hear for someone who has been
playing around with computers since a young age, but it’s not always easy to
answer the question “what are you good at?”, or “what do you enjoy?”.</p>
<p>It seems obvious to say that you enjoy doing things that you have a
natural aptitude for, but it’s also true that not everyone realises what they
have a natural aptitude for until they try it!</p>
<p>I didn’t realise that I’d enjoy writing software until circumstances conspired
to give me that opportunity.</p>
<h2>Programming of the Excel kind</h2>
<p>I used to be a bit of a whizz on Microsoft Excel. I worked in a marketing
department for a web business, and my day job comprised compiling sales
performance reports and exporting data from Google Analytics to analyse how
customers were using our website.</p>
<p>I took an unnatural pleasure in compiling extraordinarily complicated
spreadsheets, and I know I’m not alone in that regard! I have a number of
friends who work in accounting who measure their success on their proficiency
with a “spreado”, and with good reason. I’ve seen macros of impressive complexity
written by people in finance departments.</p>
<p>Excel is basically a friendly interface over the top of the VBA (Visual Basic for
Applications) programming language, but once you need to go beyond the
capabilities of the basic worksheet, you get into recording macros to automate
repetitive tasks.</p>
<p>Anyone who has stepped in a macro and changed any of the references has done some
basic programming.</p>
<p>I was pretty good at that stuff, and at one stage even wrote a primitive booking
system for use by the sales agents at the company consisting of a network of
shared spreadsheets that stored data in a Access database, way before the company
had any proper systems.</p>
<p><img alt="I Love Spreadsheets mug" src="/img/article-images/i-love-spreadsheets-mug-b05c1797.jpg" /></p>
<p>My sister even bought me an “I love spreadsheets” mug as a birthday present :)</p>
<p>I enjoyed being the go-to guy who knew most of the Excel commands by heart, and
could pluck a function out of the air, and looking back I can see it was obvious
that my strengths lay elsewhere, but at the time didn’t really occur to me that
this was only the very tip of the iceberg.</p>
<p>If I could see the nested IF statements I used to write back in those days I
would cry!</p>
<h2>Starting out in web development</h2>
<p>I kind of got into web development by accident. I didn’t set out to be a
programmer, I just started doing things that interested me, and it grew from
there.</p>
<p>As part of the Marketing team at our web business, we were generally responsible
for what the website looked like, how people got to it and what they did when
they were on it. The nature of the role meant that I worked pretty closely with
the IT team.</p>
<p>I always felt pretty thick when it came to talking to them because they could
tell me whatever they liked and I wouldn’t know any better. Even working in
online marketing there are concepts that require a bit of technical knowledge
that never really sink in unless you use them yourself.</p>
<p>I realised that my career was likely to be in online marketing, and I wanted to
understand it all better, so I decided to learn how to write a website.</p>
<p>I went through the tutorials on W3Schools; they’re good, and easy to follow,
but enthusiasm dies quickly without an actual problem to solve. Nothing compares
to actually building something that you want to build.</p>
<p><img alt="W3Schools" src="/img/article-images/w3schools-4cfe27a0.gif" /></p>
<p>I needed a real world challenge, and luckily one was on hand! My friends and I
had started a football team, and we took it pretty seriously, so I decided to
create a website for our team.</p>
<p>Inevitably I made every beginner’s mistake in the book - using fonts that were
only installed on my computer, rendering a page of 2mb jpegs and scaling them
down to 60x60px thumbnails, checking the site on a decent browser and assuming
it would look the same in Internet Explorer (still IE6 at that point!) - but I
managed to deploy a site to the web, got my friends to write stupid profiles
about each other for the site, and by the time it was finished I’d caught the
bug!</p>
<h2>Sticking at it</h2>
<p>It was still a number of years before I’d make the switch to being a full-time
developer, and on numerous occasions I came close to jacking the whole thing in
disillusionment at the sheer amount of information I’d have to learn to become
really good at it.</p>
<p>I always managed to find little motivations to keep me going though, and more
importantly focussing on the next small improvement I could make, rather than
fretting about how much I still had to learn.</p>
<p>My motivation has been different at different times.</p>
<p>Firstly, as I’ve mentioned, I wanted to give myself a bit more real world
knowledge to aid my day job. I had a bit of spare time on my hands, and
considered pursuing a qualification, but (rightly with hindsight and IMHO) decided
to get my hands dirty rather than adding another line to my CV.</p>
<p>Once I’d started telling a few people about what I was doing I felt a commitment
to follow through with it and actually get something on the web. It’s enormously
satisfying to see something that you’ve produced go up on the web and to be able
to send around a link to your friends.</p>
<p>Next I wanted to make some money. I knew a bit about affiliate marketing, and had
some experience with SEO, and thought I’d join an affiliate program and try and
write a simple price comparison site. This required me to learn how to store my
data in a database, and to render dynamically generated pages.</p>
<p>I used PHP on the server-side, though if I’m honest I didn’t really understand it
then, and got by by finding little snippets of code online that I could copy and
paste to get over my next hurdle. My site barely earned me a penny, but getting
something working gave me the confidence to keep at it.</p>
<p>Then I started taking on jobs for other people. My mum wanted a website for the
church that she belonged to, and a friend of mine wanted a site for the charity
that he was just starting up. They wanted to be able to update the pages
themselves without having to write any code, which gave me the opportunity to
research content management systems.</p>
<p>I’d had a bit of experience using Wordpress, and could write some basic PHP, and
while I wouldn’t put my name to either site these days, both ended up serving a
couple of hundred visitors a month and were in existence for a few years.</p>
<p>Having played around with various technologies for a few years I got chatting to
a developer at my company who recommended trying Ruby on Rails. This was my first
taste of real programming and I started to learn the basics of application
design.</p>
<p>This was where my interest in programming took off to the extent that I would
spend most of my spare time studying different aspects of the Rails framework,
and I started to consider switching to become a full time programmer.</p>
<h2>Making the switch</h2>
<p>I was lucky to the extent that I had the flexibility to switch jobs within my
company, and I realised that not everyone would have had that opportunity. Had
that option not been available to me, I would have started applying for
junior jobs in the industry.</p>
<p>I knew that the knowledge I’d gained through my own personal study had got me at
least on par with a recent computer science graduate. Whereas I didn’t have
the qualifications to support an application, I felt that I could withstand a
technical interview if given the chance, and that my self-starter attitude and
obvious passion for the work would stand me in good stead.</p>
<p>Now that I’ve been working as a full-time developer for 2 years I know that there
isn’t really a substitute for working day-in day-out alongside like-minded
people, and I know I’ve learned more in these past 2 years than in all my years
of experimenting in my spare time.</p>
<p>That being said, I would urge anyone who has the slightest inclination that they
might be interested in computer programming to take matters into their own hands!</p>
<h2>If I could give any advice…</h2>
<h3>Pick something you want to build and build it</h3>
<p>Even the simplest of websites will present you with challenges that you didn’t
anticipate, and will teach you things about the web that you can’t learn by
reading a tutorial. You will at times be surprised how easy to can be, at other
times frustrated at how the tiniest details can stand in your way, but ultimately
satisfied at seeing something that you’ve created on the web. And above all, pick
something that you care about, because that keeps you motivated when things aren’t
working out.</p>
<h3>Don’t let the stereotype put you off!</h3>
<p>There’s undoubtedly a stereotype of an “IT geek” that must dissuade some people
from pursuing a career in IT, and I’m sure I used to have a bit of prejudice too,
but looking back I can see how silly that was. I’ve made some great friends, and
met some great people, and above all I’ve barely met a single person who didn’t
love their job.</p>
<h3>You don’t need expensive software to get into it</h3>
<p>Pretty much all of the applications we write are based on open source software
that is freely available for anyone to download. You can get a seriously long way
without spending a penny, and the only hardware you’ll need is a low spec’d
laptop. A colleague of mine did all of his programming on a 11” netbook with less
than a GB of RAM, because he liked to carry it around with him in his man bag!</p>
<h3>Don’t give up when it seems hard.</h3>
<p>Reading code can be like reading a new language. I’ve often had that sinking
feeling when faced with what looks like a page of gibberish and I’ve got
to make sense of it, but usually after going slowly and taking the time to look
up the words or constructs that I don’t recognise, I realise it’s not as
complicated as it first seemed.</p>
<p><img alt="Wha??" src="/img/article-images/wha-7ba09a93.gif" /></p>
<p>Often when code is hard to read it is an indication that it has been poorly
written. Good programmers however strive to make their code easy for others to
read. Barely a code review here at Sharktank goes by without someone making a
suggestion as to how to make code simpler to read.</p>
<p>There’s a lot to learn, but not much that’s beyond the comprehension of anyone
who’s prepared to take the time to understand it.</p>
<p>There’s good reason that <a href="http://martinfowler.com/bliki/TwoHardThings.html">this phrase</a>
is quoted so often!</p>
<h3>Remember that someone else will have run into the same problem before!</h3>
<p>I often wonder how anyone managed to learn anything using textbooks alone. The
web community is enormous, and the free resources out there are truly staggering.
Particularly if you’re starting out someone will have written a tutorial for
every conceivable thing that you’d want to do. In years of developing websites I
can barely remember a time when I wasn’t able to find the answer to a question
via a few targeted web searches.</p>
<h2>Wrapping up</h2>
<p>I never set out to become a computer programmer, but that’s what I’ve ended up as
and I couldn’t be happier. If I could have my time again I’d have chosen
different options in secondary school, and would have applied to do a different course
in university, but I try not to dwell on it too much, because I know I enjoy my
job now because I’m doing what I did as a hobby for many years.</p>
<p>I’d encourage anyone who’s even a little bit curious to give it a try, it could
be the best decision you ever make!</p>
Peer Code Reviewhttp://sharktank.co.uk/articles/peer_code_review/2014-01-30T09:46:00Z2014-01-30T09:46:00Z<p>Code reviews - many a new programmer will shudder at the thought of being given
the task of reviewing a peer’s pull request (PR). Others will leap at the
chance to improve their understanding of a problem. Some just enjoy the
challenge of being able...</p><p>Code reviews - many a new programmer will shudder at the thought of being given
the task of reviewing a peer’s pull request (PR). Others will leap at the
chance to improve their understanding of a problem. Some just enjoy the
challenge of being able to find bugs or improvements, i.e. sort of another tool
for learning, really…</p>
<p>At first, my thoughts, as well as the thoughts of other colleagues I had spoken
to about this, were that everyone did their own thing when reviewing code. In
actual fact, there is a distinct method (which I’ll share with you later) in all
the madness that rings true for about 95% of the people I have worked with.
Hence illuminating the fact that most of the preconceived ideas held by myself
and my fellow engineers as to how others review code were totally wrong!</p>
<p>Luckily here at SharkTank we promote pair programming quite extensively and
it’s definitely become part of the development culture. Two people, one
mindset, switched on, working on a common problem or customer need. Think of it
as a first class access pass into the inner workings of your pair’s analytical
mind and the processes/paths they choose to use/follow when solving a problem
or completing a task.</p>
<p>In effect, this gave me the opportunity to implicitly ask questions about how my
“pair” reviews code when looking at pull requests. With each person having
varying levels of skill as well as a different attitude towards reviewing code - this
was going to be interesting! The idea was not to arouse suspicion. I
wanted the truth, nothing but the truth. Whatever I heard or saw no matter
how ugly - I wanted it all!</p>
<h2>The (wo)man with a plan</h2>
<p>After literally months of taking notes while ‘undercover’, I organised it all
into a sort of structured list, ready for analysis. I have found that there
is clearly a common set of steps taken by the majority - an existing “method in
all this madness” if you will. I’ve extracted this ‘foundation’ of steps
into a “start to finish” guide on how to effectively and confidently take on
the challenge of reviewing your peer’s code. This is what it looks like:</p>
<h3>1. Examine all notes and documentation for the PR.</h3>
<ul>
<li>Read PR description and notes.</li>
<li>Run through the commit messages. These should describe the path
the original programmer took at a high level.</li>
</ul>
<h3>2. Spin up the app and use it.</h3>
<ul>
<li>Simply put, you’re looking for obvious bugs, typos and an unsensible work flow.</li>
<li>This also gives you an idea of what exactly the code is trying to achieve.</li>
</ul>
<h3>3. Quickly scan through the code looking for stylistic issues.</h3>
<p>These are usually trivial things. Basically, these are the things missed
because you’re working with the same code for long periods of time.
Some examples are:</p>
<ul>
<li>Extra/pointless white space, including empty lines.</li>
<li>Typos in comments, method names, classes, etc.</li>
<li>Any sort of syntax or format use that breaks our coding guidelines.</li>
</ul>
<p>Shark Tank’s Coding Guidelines consist of a set of rules that are mostly
language and format specific. For example:</p>
<ul>
<li>Multi-line loops in Ruby should be expanded with a <code>do</code> and <code>end</code> rather than
using braces. This improves readability and makes life easier for your
fellow programmer.</li>
</ul>
<h3>4. Look at the tests</h3>
<p>Tests form the living specification for a software project.
Tests in our code base are usually broken up into behavioural sections and
then grouped together in a general order of: <code>context < method < class</code>.</p>
<p>This gives the test suite an easy to read structure. Hence this is usually a great
place to get a sense of what the solution is and what the new objects and
methods are expected to accomplish.</p>
<ul>
<li>Read through the tests and get a basic understanding of what is trying to be achieved.</li>
<li>Take a look at the level of stubbing and/or mocking.</li>
<li>Ask whether the test is robust. Is it essentially a
specification or is it just testing the inner workings of something?
Testing inner workings(implementation) can sometimes make the test fragile
when refactoring.</li>
<li>Gauge the simplicity of the tests. Usually, but not always, complicated
tests indicate that the solution may not be the optimal route and that there
could be improvements to be made.</li>
<li>Tests are worse than useless if they take too long to run. Checking the
performance and approach to testing a particular method could also be
something to look at.</li>
</ul>
<h3>5. Read through the code slowly in a detailed way.</h3>
<p>At this point most programmers will start to ‘connect the dots’ so to speak
on a high level. It would be relatively expensive to try and comprehend
and guess why every line of code was written the way it was. Your job as a
reviewer is to simply observe, understand and then critique the current piece
of code you are reviewing based on your understanding of the solution at hand.</p>
<ul>
<li>Look out for performance issues.</li>
<li>Minimum amount of DB queries that could possibly be made.</li>
<li>If applicable - is the functionality thread safe.</li>
<li>Look out for possible memory/resource leaks.</li>
<li>Can the functionality be replaced with a standard library method?</li>
</ul>
<p>While these steps seem to be pretty saturated with information and
detail on what you should be looking at or for, remember that a lot of these
points go hand in hand. For example: Looking for places in the code
where fewer queries to the DB could be made. This can help with
performance issues as well. You should also concentrate, in detail, on the tests,
i.e. would stubbing be as effective as creating the full stack object
to run a particular test?</p>
<h3>6. Final usability look over.</h3>
<ul>
<li>A quick check to see that all acceptance criteria has been met.</li>
</ul>
<h2>In short, what exactly are we looking for?</h2>
<p>There are a lot of activities during a code review, but here is
a list of the main things you are looking for:</p>
<ul>
<li>Code smells</li>
<li>Code breaking the guideline specs</li>
<li>Improvements - both performance and readability of code</li>
<li>Unnecessary calls to the DB</li>
<li>Missing or fragile tests</li>
<li>Possible memory leaks</li>
<li>Does the code impress upon the structure of the business rules (directly map to
the business domain as much as possible)</li>
<li>re-inventing the wheel syndrome</li>
</ul>
<p>On a final note: I would caution against paying attention to who
worked on the PR. It is better to go at it with an unbiased mind. Your review
is about the code and nothing but the code, so help you Git (or whatever other
version control system you so choose).</p>
<p>The above peer code review “guide” is what I would term as the basis for the
majority of most review approaches. Although obviously I had a relatively small
sample group for this “experiment”. Simply having more than 4 or 5 engineers
with slightly different approaches, that have all the above steps in common, is
more than just a coincidence. This is clearly a tried and tested core part of
the review process that delivers results in the form eradicating bugs and
merging the best quality code or as close as for many an engineer.</p>
<p>I focused this article on giving you a broader and more structured approach to
achieving the best possible results when reviewing code. Of course we all have
our style and preference in the way we explore problems and possible
solutions. So tweaking the above approach to your own style and preference is
only natural. Even if this article has only just got you thinking about how to
be more effective in the peer code review process, then it has at least served
a worthy purpose.</p>
Inheritance? Why Not?http://sharktank.co.uk/articles/inheritance-why-not/2013-10-11T10:08:00Z2013-10-11T10:08:00Z<p>As it often does, my day started with a quick peek at the open pull requests.
We had two similar classes, one which had a parent class and one which
didn’t. The discussion centered around whether or not the second class should
also inherit from the...</p><p>As it often does, my day started with a quick peek at the open pull requests.
We had two similar classes, one which had a parent class and one which
didn’t. The discussion centered around whether or not the second class should
also inherit from the parent class since it had very similar functionality.
In the end we decided that there should be no parent class. After all, these
days the mantra is, “Avoid inheritance and embrace composition”.</p>
<p>“But why?”</p>
<p>You have to understand that this was a Monday morning and the object model
was obviously improved by our actions. One more code smell gone. On
to bigger and better problems!</p>
<p>“Why should we avoid inheritance?”</p>
<p>Sometimes I think my hearing needs checking. Often I find that when I am
particularly chuffed with my efforts and trying to remember where I hid
the good coffee beans I get this annoying voice in my head. Best just
to ignore it.</p>
<p>“What makes composition better?”</p>
<p>This time it was my IM pinging at me. Dawid was kindly reminding me that
I should really think about this problem. I guess there is no getting around it.
“Just say that <a href="http://en.wikipedia.org/wiki/Erich_Gamma">Erich Gamma</a> says
<a href="http://www.artima.com/lejava/articles/designprinciples4.html">composition is better than inheritance</a>
and get back to looking for the coffee”, I thought. Erich Gamma knows way more
about OOD than I do, so it must be right.</p>
<p>“So exactly how do you use <a href="http://en.wikipedia.org/wiki/Strategy_pattern">Strategy Pattern</a>
in place of inheritance?”</p>
<p>This inner voice was seriously disrupting my carefully cultivated Winnie-the-Pooh,
Zen-like state of mind. Oh well, it’s not like I would ever remember where I hid
the coffee. Everyone knows that it’s twice as hard to find coffee than it is to
hide it. I was quite clever in hiding it, so there is no chance I will ever find it
again.</p>
<p>Of course I know the answer to this question. How could I not? I’ve spent decades
writing object models, both good and bad. I’ve made every mistake and then made
them again just to be sure they were actually mistakes. I know from all this
experience that it always works out better if you avoid inheritance unless you
need it. And this is how you have to think:</p>
<p>… Maybe I should just go back to looking for the coffee.</p>
<p>Knowing something to be true and being able to say why it is true are different things.
As humbling as it may be, sometimes knowing something to be true and it actually
being true are different things. Is it really true in this case? Erich Gamma said so.
So did a lot of other people. But to be honest, I have seen precious few good
descriptions of this issue. Pretty much all I see on the internet are a list
of good natured assertions. Isn’t that good enough? After all, Erich Gamma and
everybody on the internet can’t be wrong!</p>
<p>Well, I finally spotted
<a href="http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/">this brilliant explanation</a>
by <a href="http://berniesumption.com/">Bernie Sumption</a>.
For those of you who tend to skim past the links, let me tantalize you with the
fact this article includes examples with both Star Wars and hippos.</p>
<h2>TL;DR</h2>
<p>It is often much more difficult to understand when to use inheritance than it
might first appear. When I first replied to Dawid’s innocent question, I
spouted the normal nonsense of:</p>
<p>“Use inheritance when you have a clear IS-A relationship and where you do not
invalidate the <a href="http://en.wikipedia.org/wiki/Liskov_substitution_principle">Liskov Substitution Principle</a>.”
The problem is that even when you think you have a clear cut IS-A relationship,
it might still be better to implement it using something like the strategy
pattern.</p>
<p>The classic example of an IS-A relationship is the decomposition of employees.
One could argue that an employee is a person and workers and managers are
employees. But you could also look at it another way. A person has a job.
The job has a role. What makes someone a manager is the kind of
role they have. Should we use inheritance for the role, with worker and
manager roles? Or should the role have worker and management responsibilities?</p>
<p>At some point you start to think that you can replace all inheritance in
a system with composition. Since you have more flexibility with composition
it seems to make sense to always use composition. Are there times when you
should use inheritance?</p>
<p>I think the answer is “yes” and to see why it is instructive to look at the
<a href="http://en.wikipedia.org/wiki/Composite_pattern">Composite Pattern</a>.
In this pattern, everything is a component. There are two kinds of components:
a leaf component, and a composite. The composite is made up of components.
Component is the base class, while leaf and composite are the child classes.</p>
<p>The important thing to consider is that the composite pattern does not
use the base class in order to share code. Instead it is there to share
the interface. Presumably, we have a tree structure and we want to
iterate over it using the interface on component. Other design patterns
such as the <a href="http://en.wikipedia.org/wiki/Bridge_pattern">Bridge Pattern</a>
use inheritance in the same way.</p>
<p>When you have a clear IS-A relationship <em>and</em> you want to use all
the objects through the base class’s interface, then inheritance can
be a good way to go. It is certainly not a tool that I would throw out
of the tool chest lightly. However, if you want to deal with the derived
classes through their own interfaces, it often makes much more sense to
use composition.</p>
Shipping Enables Perfectionhttp://sharktank.co.uk/articles/shipping-enables-perfection/2013-09-25T14:46:00Z2013-09-25T14:46:00Z<p>The other day, <a href="https://plus.google.com/116224203946769418059/posts">Stephen</a> sent me a link to an interesting
article by Ben Kamens of the Kahn Academy entitled
<a href="http://bjk5.com/post/60760280107/shipping-beats-perfection-explained">“Shipping Beats Perfection” Explained</a>.
Owing to a critically low level of caffeine in my system
I initially struggled to understand why I should...</p><p>The other day, <a href="https://plus.google.com/116224203946769418059/posts">Stephen</a> sent me a link to an interesting
article by Ben Kamens of the Kahn Academy entitled
<a href="http://bjk5.com/post/60760280107/shipping-beats-perfection-explained">“Shipping Beats Perfection” Explained</a>.
Owing to a critically low level of caffeine in my system
I initially struggled to understand why I should be interested
in the delivery of the “Perfection” version of a software
package called “Beats”.</p>
<p>When my English parsing ability rebooted, I dutifully scanned the article,
admired the pictures of the dog, and blindly jumped to the hardwired conclusion
built into any decent craftsperson of software.</p>
<p>Stop telling me that I’m gold-plating, polishing the
round ball, sorting beach sand by size, running for political
office, or doing any other pointless activity meant to diminish
the nature of my efforts. I can tell you for a fact
that we need to cleanup the object model in order to make
it easy to modify in the future. If we don’t, all sorts
of terrible things will happen like… like…</p>
<p>Normally at this point in my rant I find myself staring
into the vacant eyes of a middle manager of some huge
anonymous corporate structure. Said middle manager’s
sole programming skill consists of realizing that nobody
tests the code before it is shipped and if he marks all
his tasks as “Done” he will get promoted before anyone
realizes he hasn’t actually written any code. His idea of
an “embarrassment test” is that the product ships on time,
because if it does he will get promoted again. From his
perspective in management, any problems in the code
are an embarrassment to me, not to him. His carefully
crafted “not my problem” attitude is not threatened
in any way, so he is happy to maintain the status quo.</p>
<p>Of course my life isn’t like that any more. Long ago I moved
away from such positions and my situation at Sharktank is
relatively idyllic. On a second, coffee-fuelled review of
the article, I didn’t get the impression that the
Kahn Academy software team is run by such cluelessness
either. And to be fair, I don’t think that their mantra
is meant at all to refer to the tendency of programmers
to add features that aren’t strictly necessary.</p>
<p>To me, “Shipping Beats Perfection” means that I prefer
to give you a partial solution early rather than make
you wait for a full solution. In fact, I prefer to give
you many happiness-inducing incremental releases even
if it results in a delay of the full release. By doing
so I will release what you actually need, not what you
thought you needed when we first started. I will constantly
adjust what I’m doing as a result of the feedback I get
from the release.</p>
<p>It is tempting to think that one should wait until a product
is finished before one ships. After all, it is an embarrassment
to ship with something that appears half finished. But when
is a product finished? I think that software should borrow
a saying from the growing of bonsai trees: it is only finished
when it is dead. The rest of the time it is growing and
changing. It needs shaping and forming during that time, but
it would be foolish to say that we can’t display it until it
is finished. Who wants to look at a dead bonsai tree?</p>
<p>The decision to ship is largely unrelated to the quality
of source code that makes up the system. What we are interested
in is the behaviour that is apparent to the user. In the majority
of cases, if the software is providing benefit to the user and meets their
expectations for a release, then it should be released. The more
often you release, the better off you are.</p>
<p>There is a major caveat in this statement, though. We don’t want to
get into a situation where releases get farther and farther
apart. What we ideally want is a steady throughput of releases
that incrementally add the behaviour that the customer wants.
Creating a single release very quickly is a pointless exercise
if it comes at the expense of all of the subsequent releases.</p>
<p>As software craftspeople, we must take care to spend an appropriate
amount of time refining and perfecting our code so that we may
generate the fastest possible long term throughput. We must be
sensitive in our approach and create simple, yet elegant
code so that we can modify it at will in response to
unpredictable future requests.</p>
<p>Releasing early and releasing often is the reason that we
must pay great attention to detail in our code. Shipping doesn’t beat
perfection. Shipping <em>enables</em> perfection. It provides the
heartbeat for any quality-minded team.</p>