Category Archives: Agile

My Advice on How To Do Well At A Pair Programming Interview

I find that Pair Programming something that many developers still have little experience of, so when it comes to a “Pair Programming” session in an interview they are either unnecessarily nervous, or naively confident. Now don’t get me wrong, a little naive confidence can often be a good thing, but sometimes it does pay to be prepared.

Here some advice that I’ve collected over the years which seems to go down well – keen to hear anyone else’s thoughts in the comments! But in my experience if you follow these tips, you’ll have every reason to be confident an interview:

WHAT IS PAIR PROGRAMMING?

Whether have years of experience with pair programming OR you have never programmed before, its important to know that Pair Programming is basically just “social programming”. Something you do every day but sitting next to a fellow coder who is watching your screen and inputing ideas, and with a technical discussion involved.

AND A PAIR PROGRAMMING INTERVIEW?

Normally there is a “Pilot” who is doing the actual coding and the “Co-Pilot” who is sitting next to the Pilot and working with them on the logic and “two heads is better than one”. Typically in a Pair Programming interview you’ll be the Pilot and you’ll be given one or more exercises and asked to complete them.

TDD

As a general rule, it is a VERY good idea to follow Test Driven Development and to write your solution to the given exercises using Unit tests. This is not always “critical critical” but over the years I have discovered that this is a classic pitfall that many people forget to start with in the “heat of the moment”. Why is TDD important, basically because its another tenant of Agile and XP and if a company wants you to do a Pair Programming session as part of an interview, its a fair guess that they also follow the Agile methodology.

Be OO and follow Best Practice

Remember this is a technical round. So obviously make sure your programming is as best as it can be. So within the confines of the task at hand keep to best practice, follow OO programming principles and set out to impress without over-engineering a solution!

Try to Relax

This is what you do every day. The guy sitting next to you wants you to succeed (really they do, its awkward sitting next to someone who is having their own internalised car crash, so they’ll be keen to support you to get the best out of you as a candidate), so try to relax and be yourself.

Be Friendly

I’m sure you can agree that two people sitting in silence in front of a computer could be a bit weird. So, take the initiative and be friendly from the start. Chit chat with them as you walk over to the computer – think about inane stuff you can talk about that will help you two start to feel comfortable with each other. Stuff like football, the latest Java conference, the weather, cr@p that will break the ice before you sit down.

Keep Talking

The other part to making sure this paired programming session goes well is to keep talking. So try to describe your thought processes as you go, and explain what you are doing as you do it.

If you need time to code

A great little tip is that if you feel you need some time to get your head down and focus on some code is to ask the person sitting next to you something that will naturally need a long winded answer. Something like “Tell me about life at ABC Ltd” or “So what’s your background then?”, that way they’ll start talking and you can focus!

Don’t Be Afraid of Silences

BUT don’t be afraid of silences when they come. Some silences will be natural so don’t let that worry you.

 

Advertisements

Another post-Agile methodology

Following on from my previous blog about Programmer Anarchy, I was doing some more research into post-Agile concepts and came across a new methodology called “Programming, Motherfucker” by Zed A. Shaw. Here is a link to his site.

Zed’s methodology is a new way of programming which focuses on pure coding as the main form of development, and rejects the utility of most management roles in the same way that “Programmer Anarchy” does, but does include space in the team for Management, Asshole (which I had also concluded was the primary weakness of Programmer Anarchy).

The “Programming, Motherfucker” philosophy solves problems, tests its code and completes tasks on time and under budget all using the same methodology: “Programming, Motherfucker”. At the same time “Management, Asshole” takes responsibility for tasks like finding out what client wants by asking them, providing the programmers with the right tools to code and then feeding back to the development team when the client is happy or not with the product.

In the words of Zed:

It’s awesome because it does the one thing that actually gets software up and running.

Makes sense to me. If you think so too, or want to learn more about implementing this post-agile methodology in your office, visit Zed’s site (and maybe even buy a t-shirt).

What is Programmer Anarchy and does it have a future?

A developer I know recently told me that he wasn’t interested in any new opportunities in the short term because his team were about to adopt Fred George’s post-agile concept of  Programmer Anarchy. Having piqued my interest, I started to explore and thought I would share my findings.

From what I’ve found I think he’s a bit mad, but he thinks it’s a good idea and at least 2 major UK companies are using it, so there must be something to it.

* Frequent visitors to this blog will notice that I use the term “Programmer” here a lot, as opposed to the usual “Developer” – that’s simply because Fred George uses that term, and he probably uses it because he’s American.

WHAT IS this Programmer Anarchy?For those of you who don’t have their ear pinned to the techie ground, Programmer Anarchy is a concept that has been around for about the last year, is considered “post-Agile”, has so far been evangelised by Fred George and says that software development is more productive when programmers are “self organised”.

So Programmer Anarchy is…

  • At the start of the day the programmers choose their own work during daily stand-up meetings
  • There are no PMs, Iteration Managers, BAs, QAs / testers or “managers of programmers” – all the normal rules of managing software development in a professional environment are gone. This is on the basis that formality and rules are constraining to creativity and productivity
  • It runs on the concept that with no managers to give power to their programmers to go ahead and develop (managers “empowering” their teams), programmers go ahead and take total responsibility for the success of each project in a form of self-organised “anarchy”
  • Integral to this is the adoption of the mindset “what if you were guaranteed not to fail” and the idea that disagreement and failure is expected, and both are ultimately productive outcomes. They want programmers to lose the “fear of failure”
  • Programmers work directly with the customer, which builds more trust and understanding about how the SDLC is affecting delivery
  • And to top it off Programmer Anarchy is still Agile Manifesto compliant:
    o Individuals and interactions over processes and tools
    o Working software over comprehensive documentation
    o Customer collaboration over contract negotiation
    o Responding to change over following a plan

For more detail here is link to a presentation Fred George gave, and a link to the slides.

What has Fred George done with it?

Fred George’s experience of Programmer Anarchy has been at an internet advising company called “Forward” where they got “40 geeks together” and instituted the new methodology. They work for a number of high profile clients, including “Search” a big energy company. And they report not only happy programmers but also some impressive statistics:

So this “programmer’s Nirvana” is going to be the next big thing then?

I don’t think so. I think it’s a great idea, but ultimately I can’t see it being a game-changer.

Agile is a big tent concept that allows lots of different implementations under the same name and has been widely adopted for different reasons. On the one hand it’s a good PR tool that breaks down the wall between producer and user, and on the other hand it improves productivity when correctly implemented. I also don’t think it’s any co-incidence that the popularity of Agile really picked up at the same time that the big tech reliant companies started to make their offshoring models work successfully. Paired programming can produce higher quality code when people work collaboratively, but it takes up two developers’ time and that can be hard for some projects to justify.

Agile is implemented in a wide variety of ways, from a kind of religious dogma, to a model that is fairly close to waterfall but with stand-ups and scrum masters through to the “Thoughtworks approved” approach. One thing I have found as a recruiter is that it takes a team of very high quality developers to make a truly Agile methodology work successfully. I know a team at Credit Suisse that have successfully implemented something fairly close to this (a team of 20 developers, one BA and one PM) and they took a long time to recruit the team because their entry criteria was so high. You don’t just need a good programmer, you need one with good communication skills, one that understands the business enough to work with it productively and one that is savvy enough about why tactical and strategic decisions are made.

And so, I suspect, it is with Programmer Anarchy. Fred George’s experience of Programmer Anarchy was probably so positive because he was working in a team of high performance programmers, who, like him, could cope with the demands of self-organized development. The advantage of Waterfall and the less purist versions of Agile is that they can accommodate lower performance team members and still be productive. Take the example of a tester, or a 3rd line support analyst – in the main their ranks are filled with the below-par programmer. They help the process by reduce the programmers’ work load and don’t cost as much to the CFO’s bottom line. So if you get the division of labour right, you can produce the same result for less money and spend less time recruiting the team in the first place.

But I guess the real problem with Programmer Anarchy is that it takes away the central “leader” figure. Often in big projects not everyone contributing has dedicated their lives to the success or failure of this project. Programmer Anarchy presumes that everyone in the team is totally passionate about the project’s success, but in reality it’s often only a few members of a team who wholeheartedly take on the successful delivery of the project as a top priority in their lives. You find that many other members of the team prioritise their private lives more when it comes to spending time in the office, or that their minds are somewhere else when they are sitting at their desks. I wonder if Programmer Anarchy presumes everyone on the project is a natural pig and forgets about the chickens.

With a central leader figure you also get one person who has staked the next part of their career on the success of the project and they become the driving force behind it’s delivery. Programmer Anarchy presumes everyone is their own leader, but again not everyone is like that. Lots of people don’t want to take control or drive through the delivery, they just want to do a day job.

Finally I suspect that Programmer Anarchy has a tendency for “perfectionism-by-the-back-door”. On the face of it it has a kind of hacky feel, where programmers produce lots of work because they are all developing at their optimum rate. In practice I suspect there’s a bit of a bun fight for the best bits of work, with the least interesting bits going to the least outspoken members of the team and without a central “leader” figure no-one to enforce tight deadlines. And who organizes the stand-ups in the first place? In an environment where formal power has been removed, anyone with some measure of control over the process will start to exert their power. With a central leader there is someone who divides up work and ensure that deadlines are hit.

I also bet “Programmer Anarchy” is exhausting as 100% effort is expected all of the time, when in fact normal development isn’t like that. As with any job there is an ebb and a flow at busy times and slow times. I would like to see a comparison between the productivity statistics that Fred George gives for his “Programmer Anarchy” team, and the same criteria for an Agile team who are working flat out to hit a tight deadline

I suspect that Fred George’s experience of Programmer Anarchy was successful because it’s the right methodology for him, with his level of professional and commercial experience and with his independent mindset. And I think that some teams will take this up and it will work very well for them, but in general its not right for everyone.

So I don’t think we need to start learning the words to any Billy Bragg tunes just yet.

OK, so what would you do then?

I think the most powerful idea in Programmer Anarchy is the idea that programmers take personal responsibility for the success of each project, the rest of it feels to me like a mix of good intentions, some feel-good Californian vibes and a heavy dash of Marxism. I think that any kind of team will always need a division of labour, a leadership structure to organize and motivate the team and a support function to allow the core part of the team to focus on doing what they do best.

Evidence of Scrum methodology at work in agriculture!

Scrum

Scrum

I went back to the farm on Saturday and couldn’t resist taking this photo. Cheesy I know. I also managed to get a shot of proud mother pig’s brood:

Piglets

Piglets