Software Engineering

What developers can do when the work-in-progress limit is reached

Introducing work-in-progress limits

In January this year, we (the NET-A-PORTER GROUP Product Management team) introduced work-in-progress limits to our software development process. For example, we have at most five items “in development” (including in code review) and four “in test”. An item in this case is a user story, bug fix or investigation task.

We added the work-in-progress limits as part of a Kanban-inspired move away from a fixed-iteration process to a continuous flow of work.

Continue reading

Software Engineering

Are you failing enough?

When I started in the Labs team at Net-a-Porter, the job description contained the following desired trait:

Candidate is unafraid to fail, but fails fast

This phrase was new to me at the time and it certainly wasn’t something I could say I was actively doing, but three years later failing fast is not only something I strive to do as a software developer, but something I look to do in aspects of my day-to-day life.

So what does this phrase actually mean? The phrase has two parts; let’s look at each of them.

Continue reading

Perl

Information Representation for Storage and Communication

There are many different data representations of a single piece of information – and many ways of interpreting data as information. In this blog entry, we show that, when designing systems, we have to distinguish information from its data representation in order to ensure the system matches its requirements of being authoritative or redundant, and to communicate this information using a fault tolerant representation.

Continue reading

Perl

Programming is all about: Keeping track of the details

The ideas here are those that have I taken away from a presentation given at NET-A-PORTER by Johan Lindstrom

INTRODUCTION

In programming, details matter. The machine does exactly what you say. Whether given software designs from the design team to implement; whether prototyping, or just poking around the code in your Agile team; when programming, the details matter. To design and document a solution upfront so thoroughly that no decision was left to the programmer would be to create something so complex that it would be as difficult as programming, likely to contain more bugs, and likely to take more time. Designs may map out code structure, data structures and interactions, but they are fundamentally confined to the higher levels. The truth is that the people who churn out the software are making a lot of tiny decisions for the company, and all of those decisions add up.

Continue reading

Software Engineering

Agile Tetris

Tetris. Reading this should strike a nostalgic chord with most if not 100% of us born into the computer generation. If you’ve never heard of it then you’re either less than 3 years old or you’re asking what a computer is. Well for the benefit of those people I’ll try to summarise.

Its a puzzle game based around the idea of having different shapes made up of four blocks falling from the top to the bottom of the game area and settling at the bottom. The idea is to complete a row by filling in the gaps, at which point the row will disappear. The game space is a fixed number of rows so you need to be careful rows are removed regularly else the entire game area is filled up and the game is over. To the side of the game area usually it’ll show you the next piece – this is invaluable in planning where to drop your current block. As you remove more rows the speed of the falling blocks will increase and it becomes a challenge of how fast you can think and plan the blocks.

Continue reading