Farm to fork software development

During a recent attic expedition, I happened upon a box filled with my old university ‘stuff’. Amidst the photos of bad haircuts I found a handful of job application rejection letters.

The school I attended is not well known for its computer science department. That said, when I graduated, I decided to swing for the fences — I applied to some pretty big and well known companies (e.g. Microsoft, IBM, Corel). Those companies kind enough to interview me were also kind enough to send rejection letters, bless their hearts.

At the time, I was sure that the relative obscurity of my alma mater was one of the reasons I wasn’t getting interviewed (or hired). But I’d had a great learning experience at university; I would certainly put my degree up against one from down the road (in my particular case, the University of Waterloo is down the road and benefits from a well deserved global reputation of excellence). I had kept those rejection letters as a personal challenge to prove that my skills were up to the task, able to help me land a top tier job writing great software.

In the twenty years since graduating, I’ve come to the conclusion that while the school I attended didn’t do me any favours in the name recognition game, the exposure I had to full cycle software development was exceptional — just out of school, I knew more about how (and, more importantly, why) to design and build software properly than most established software developers in the field.

We had been taught to interview users, to define and refine requirements, to establish test plans, to develop an architecture, to implement features, and demonstrate the software to others. We spent time on project teams in various roles, not just all writing code. This may all seem commonplace now but, 20 years ago, I had friends at other universities learning nothing of the sort.

That early exposure to a variety of roles, to different team dynamics, and the freedom to see how the product reacted to those variables (yes, products react!) helped form my opinion that the highest quality software development can only occur when the team is aware of and respects the process, artifacts, and — perhaps most importantly — the people involved at each stage.

Farm to Fork

There is a term used in the food industry that is becoming increasingly popular: farm to fork (or farm to plate, but who doesn’t like a bit of alliteration). This term refers to the accountability and traceability of food goods from the producer to the consumer — each participant in the chain is aware of more than just their immediate neighbours, and invests in learning about the chain and its links. But does this chain of accountability have an analogue in software development? Can the same benefits extolled by proponents of farm to fork be achieved in a software context? And what are the benefits of knowing about more than just your link in the chain?

While smaller companies often embrace and expect a degree of jack/jill-of-all-trades in their employees, larger companies often place more value in specialists. These specialists work on larger teams, each contributing according to their expertise — interaction designers guide application behavior, developers implement that vision, testers ensure that functional and quality requirements are met, and so on. In this way, even with the adoption of Agile development methodologies, there is often a progression of work product from one discipline (and specialist) to the next, along the chain.

The extent to which each discipline and their representatives talk to each other depends upon the company, team, and project. The waterfall model of software development promotes less intermixing of disciplines, instead relying on well defined stages of the project where the work from one team or stage cascades to the next. This leads to the practice of work product (specifications, code, etc.) being ‘thrown over the wall’. This is equivalent to a restaurant getting an unmarked bag of ‘meat’ dropped off once a month at the back door — in general, don’t get too excited about the results.

Agile methodologies aim to diminish those walls by creating cohesive, multidisciplinary teams working towards a common goal. But does Scrum, a popular Agile framework, give software development teams everything a farm to fork philosophy fosters? It certainly helps. But multidisciplinary teams may still be made up of specialists, unfamiliar with how other team members do their work, and larger organizations may still impose processes which curtail cross pollination or tight development (e.g. not allowing co-location, or splitting team members across several projects).

So can the creation of software benefit from people within the chain knowing more about the raw materials being handed to them? Absolutely. In the same way that farm to fork practitioners have a greater respect for the materials being entrusted to them, those involved in the creation of software products will better understand, respect, and appreciate the person upstream in the chain. Knowing more about the process by which that material is created or manipulated can lead to (in no particular order):

• process optimization;
• innovation;
• improved quality;
• distribution of skills and knowledge sharing through overlap;
• deeper understanding of the domain, workflow, user, and product…and of the team itself (improved estimates anyone?);
• increased empathy for teammates and users;
• increased confidence in the product, the process, and the team;
• appreciation for the impact of handing low quality material along the chain;
• self-enforced accountability.

Learn your Chain

So how can you learn more about other parts of the software development chain? As a software developer, I strive to write quality software that meets the needs of the user. But I also have a strong interest in those users and how conversations with them forms the basis for user stories, which drive out the software requirements and ultimately shape the application I create with code. I wanted to learn about some of the upstream links in the chain — user research, interaction design, and visual design. The techniques described below are ones I used or considered during that exploration but should be generally applicable.

Be patient and honest

Appreciate what can be gained from learning about other parts of the pipeline, but also appreciate that people working in different areas of the pipeline are skilled, trained professionals with potentially years of experience — don’t expect to learn everything in a week; don’t trivialize the skills of your team mates.

You should understand that, depending upon the organization, it may be unreasonable to have everyone change their day to day behaviour. This may be a slow process and it might be a bit bumpy at times. Be patient.

Don’t show up empty handed

Show some initiative! Attend a conference. Join a peer to peer group or meetup group. Visit a few relevant web sites (StackOverflow is great for this — there are specialized sites for user experience, development, quality assurance, etc.). Watch some videos on YouTube, Pluralsight, or Skillshare. Join a professional organization like ACM (and try out a relevant SIG for a year). Become generally aware of the tools, techniques, terms, and what practitioners are struggling with right now (these are often the most interesting bits). Start thinking about how all of this new information may relate to the process and work product of others on the team.

Job shadow/stage/job swap

These activities are all variations on a theme. The theme? Inject yourself into the daily life of the team member you’re hoping to learn from!

In the case of job shadowing, you’ll hang out with the team member, watch what they’re doing, ask questions, make notes, and generally observe and learn from them. The rules of engagement are up to you, of course, but this technique is less doing and more watching.

A riff on the job shadowing technique is to put on your ethnographer hat: bring a camera, take notes, and gather information through observation with the intent of summarizing it in a way which can be used by others (an infographic, a slide deck or pecha kucha presentation, series of top ten lists — top ten surprises, pain points, or workflow elements, etc.). It helps to have a plan for how to use the notes you take, but be flexible.

A stage (from the French word stagiere) is a tradition in the restaurant world wherein a chef will visit another restaurant (by invitation or mutual agreement) for a short period of time, work in the kitchen for free, and hopefully learn something (new techniques, an unfamiliar cuisine, or just an appreciation for how another kitchen is run). Depending upon your skill level relative to the part of the chain you’re hoping to learn about, the amount of hands-on work will vary — but this technique differs from a job shadow in that you’ll be rolling up your sleeves and doing some work, perhaps with guidance from the specialist.

The most involved (and perhaps scariest) of these three techniques is the job swap. By taking on the full responsibility of another role on the team (For a day? A sprint? You choose.), you force yourself to adapt and learn quickly. You’ll be forced to see what works and doesn’t work, and to feel the pain of inefficiencies. It may also be the most rewarding technique as it can result in rapid knowledge gains (in both directions: hopefully you’ll have some suggestions for improvements at the end of the swap).

Co-location

If there was ever a non-technical idea so polarizing for software development organizations (teams and companies alike) as co-location, I’ve yet to encounter it. A lot of that ‘love it or hate it’ attitude comes from preconceived notions of what co-location actually means. And, ultimately, what co-location means is up to your team to decide (hotelling, creating a war room, pair programming, etc.). But sitting next to someone — overhearing conversations, seeing what frustrates them, reading their whiteboard, etc. — is an efficient and unobtrusive way to learn how they do their job.

One on ones

Mentoring can take many forms, but one on ones are a favourite of mine. By spending as little as half an hour every week or two with someone, you can learn a lot about the product, the company, and the industry through their eyes. Don’t put too much pressure on an agenda at first, but rather spend time talking about commonalities and differences in your respective approaches to product development. What is the toughest part of their job? What is the most enjoyable? Where do they wish they had more time to invest?

The Wilhelm Litany

In 2013, Kate Wilhelm spoke at Fluxible about evaluating and managing a UX career in a workshop entitled UX Circuit Training. One thought she shared has stuck with me — it has become a weekly litany for me — because it seems to work for so many things:

In my experience, if you’re working for a reasonable organization, being proactive and asking to tackle a problem is looked upon favourably. Identifying problems requiring attention (see a need), proactively wanting to fix them (ask for a mandate), fixing them (do the work), and demonstrating a pattern of making things better (build credibility) are all useful skills.

If you want to learn about other pieces of the software development chain, consider the four steps in the Wilhelm Litany as a solid, stepwise guideline.

Adopt an Agile development process

If you aren’t already using Scrum or another Agile methodology, perhaps it is time to consider it. Working closely, consistently, and often with a like-minded and focused team will only increase your knowledge of how other people think about and attack challenges they encounter. You’ll be exposed to different perspectives and start considering other points of view — you’ll be better at your job by changing how your team develops software.

Let’s know what we’re eating

My career in software development has been a fairly linear one — I was lucky to know early on what sort of software I was passionate about, and jumped in. The knowledge, first learned at university, that each member of a software development team is not just a link in a chain but some blobby mess of overlapping skills and artifacts has been reinforced by two decades at a variety of companies. Exploring those other disciplines has been the adventure!

We can develop better products, more relevant and true to our users, if we appreciate and understand the process and artifacts employed by other members of the development team.

We need to know what we’re eating and we need to know what we’re feeding to our users.