LinkedIn recently reminded me about my 2-year anniversary at Biarri. It feels like longer (a colleague has called it “Biarri time-dilation”), and I think that is a good thing.

In my previous job with an multinational corporate, I had a comfortable position running a great development and support team essentially for a single, well-earning COTS product. The product has an international client base, and that meant I scored a few business class trips each year to meet with generally happy customers. Needless to say, it was pretty sweet for a number of years, and again, comfortable.

But as the years passed, the software was ageing along with its core technologies. I had worked on the large code base for so long, I can still recall its structure. I wasn’t learning anything new – it was time to move on.

I’d worked with a few guys that had left the company for various reasons, and increasingly frequently I would hear of “Biarri” – a startup company that was based on accessible mathematics delivered in SaaS fashion. Biarri was gaining momentum, and the more I heard about the kind of projects and people involved, the more keen I was to look into a possible move away from my comfortable office.

I met with one of the Biarri founders, Joe Forbes, over coffee at his favourite cafe (in what we started calling his “coffice”). I liked what I heard – it seemed the Biarri guys had learned from the development mistakes we often see in software development in a corporate culture (“remember the Alamo”, Joe often says). Software was stripped back to the essentials, with the aim to have interaction design done first rather than as an afterthought (or worse still, by developers!). Interfacing with other systems was somewhat bypassed – using simple formats (e.g. CSV) to move data between systems. A mathematical approach was taken to solving each problem, by formulating each engine in a formal way to exploit the “power of maths”. The company was keeping its IT footprint as light as possible through the use of remotely hosted / cloud based computing resources, and had a strong focus on keeping costs low (I had always found the waste, and lack of care about it, frustrating within a corporate). They were using new web-app based technologies, and finally, they were growing! I jumped ship.

My probation period was hard work. Myself and another newbie – our COO George – were placed on a project aiming to model a redesign of a national parcel network, and some of the major Biarri players were on a well earned spate of leave. George took the reigns, and I was back in the developers chair, trying to cover ground as quickly as possible. My learning of “new stuff” started from that first week, and pretty much hasn’t abated since. As the project wore on, I got to team-lead a few of the more “junior” developers – however Joe and Ash are exceptionally good at hiring very clever people – not much leading was required. By the end of the project I had been reasonably well deprogrammed from my old corporate culture (it isn’t your job title that makes you in Biarri – its how you perform), I’d worked on the tech. stack from back to front, and was ready for the next challenge.

Since then, I’ve worked on a number of quite different scheduling optimisation software projects. Along the way I’ve learned about linear and mixed integer programming in the “real world” (not just on toy problems), and how the real difficulty can lie in the customised algorithms which feed just enough of a problem into commercial solvers without killing solve time. I’ve seen classic statistical, AI and dynamic programming techniques applied to problems as diverse as hub selection, vehicle routing, fibre network design, demand forecasting and resource allocation. I’ve learned how agent-based approaches can be used in the field of optimisation as well as simulation, and I’ve seen the company mature its software development processes to keep the machine working at the top speed it requires (where “agile” can also mean “predictable”).

As Biarri has rapidly grown over the last few years, so has the code base. It’s great to know refactoring isn’t a dirty word at Biarri. I think the key to keeping Biarri agile will be to avoid falling into the trap of developing large “in house” libraries, and not being afraid to throw away code – that should set us up to be able to refresh the “tech. stack” regularly (keeping us ready to use leading edge technology, not locking us into past decisions).

Just like any workplace, the people make or break the culture. Joe has a “hire slow, fire fast” policy, and this has made for a great place to work. It’s a pretty flat structure, and I hope it stays that way – sometimes someone has to be the boss, but everyone needs to be able and willing to get their hands dirty when required.

I can’t say I’m always “comfortable” at Biarri, but I wouldn’t have it any other way. Looking forward to the next 2 years.