So we came up with a lightweight locking framework that allows us to lock and unlock any object we are about to update, be it a database document or an entity in 3rd party API, it also ensures that a process requesting lock would get the most actual version of the object once it is unlocked.

The framework is based on Redis distributed locks and is very easy to use, and since we use mongoose for object modeling, we also crafted a plugin that adds locking functionality to the mongoose documents.

const kit = await Kit.findById(kitId).lock().exec();

// the kit is now locked and other processes
// that are also trying to acquire the lock
// on this particular kit
// are waiting for the lock to be released

kit.status = 'Sent';

await kit.save();
// kit is now unlocked,
// the next process that requires a lock on this kit
// will now get the latest version of the document
// and may update it further

The same technique can be applied to other types of documents, including entities, obtained via 3rd party API.

const order = await TradeGecko.getOrder(orderId).lock();
// TradeGecko sales order is now locked to this process
await TradeGecko.invoice(order);
await TradeGecko.pay(order);
await order.unlock();
// once we are done updating the order
// we can unlock it and make available
// for other processes requiring it

We decided to not make locking mandatory on fetching of every document, but instead, it is at developer’s discretion whether to use locks in the particular case or not. Sometimes we just want to fetch current version of the object and show it on the frontend, in this case, we are not waiting for the lock to be released thus reducing the number of pending requests.

As an author of the plugin and locking framework I’m curious to know about your solutions to the similar problem as well as your thoughts on whether your product would benefit from our framework. We might consider publishing this module as a part of our open source initiative once it proves to be stable.

Preventing data corruption in a microservices architecture was originally published in Kent and Lime Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Product at Kent & Lime sits with technology and serves as a conduit between business, customers and engineering. Our fundamental aim with Product is to:

“Ship the right product, to the right customer, at the right time”

1. Shipping Quickly

Shipping at the right time normally for us at Kent & Lime is shipping quickly. This is not new in this space. Shipping quickly has numerous advantages — for example you can test things faster and fix things faster. On average we ship every 3–4 days. Shipping faster also avoids the problem more commonly seen in a waterfall methodology where constantly changing requirements are different to when the initial scoping was done to when it is implemented.

Something we’ve learnt and followed is not to be scared to slow down delivery in order to allow to speed it back up. An example of this would be when we spent a long time automating what’s known as continuous integration (CI). By working closely with the Engineering team, we discovered that a lot of time was actually being taken up by relatively manual deployments. We then decided as part of the roadmap to lessen our delivery by building out continuous integration. We’ve seen massive output in velocity after this was done, with a decrease in deployment time from 20% to effectively 0%.

There is a caveat to shipping quickly however and that’s to make sure to ship at the right time. For some cases where we ship major updates we may time our deployments or spend a little bit more time testing specific things until we launch. Shipping at the right time lies on a range between shipping fast and shipping when things are perfect. We tend towards the faster end though it is a fine balance.

2. Ship the right product

Shipping the right product is key. If you only ship quickly and ship the wrong product, what’s the point! Whilst this seems to be a pretty obvious point, when you get into the subtleties of planning features and functionality, the lines become blurred. What we’ve seen a lot is that when asked to rank functionality on a scale of 1–5 (1 being most important), we often see nearly all of it tending towards the 1. This isn’t exactly helpful when prioritising and so a key phrase that we use to help us prioritise ruthlessly is:

“The customer comes first”

Customer first as a mindset allows us to prioritise the product roadmap aggressively and only deliver things that will provide a better customer experience. Instead of focusing on things such as revenue, we prioritise for the best customer experience. The follow-on effects we have seen from this is immense. To help facilitate this, we collect and use feedback to inform the roadmap.

Another aspect of shipping correctly lies in when we ship and what we ship as part of it. What has worked well with us is breaking each feature down to a specific “MVP” concept, delivering it and then building the rest of the feature out. Doing so has allowed us to test various assumptions quickly and rectify where needed.

3. Shipping to the right customer

To ship the right product we need to know who we are shipping to in order to set ourselves in their mindset. Not all customers are made equal. We know that at Kent & Lime we cater for a specific customer. We can’t cater to the entire population of men in Australia and the world nor do we want to at our stage (though we aspire to in the future). This means honing in on our customer personas and making sure when we receive feedback to inform our roadmap, we are talking to the right customer.

Putting it together

What then is Product Management to Kent & Lime? Product Management is the ownership of the product and the product roadmap through liaising with the various facets of the business. Talking to customers to understand customer requirements, talking to business to understand constraints and possible improvements, and talking with engineering to work around complexities and future-proof the platform.

If we were to distill product management then, it would be a single key word: prioritisation. We as product managers take in all the various conflicting inputs and try to understand and prioritise what needs to be done in order to deliver a well thought out product. Not enough prioritisation and we face the feeling of slow delivery. Wrong prioritisation and we then go into ineffective delivery.

What role does Product play? was originally published in Kent and Lime Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jump back a few years and the only real way to achieve true webpage responsiveness was to either use a pre-built CSS grid system, such as Bootstrap, or use messy CSS media queries to adjust elements based on the device size. This has some inherent limitations in that it forces developers to make their content fit within the 12 column grid container. This system works great for very simple large layouts, such as a single page designs. However, we see the limitations of this grid when creating complex pages, containing multiple smaller components (such as cards in a material design layout).

Enter the Flexbox

Flex-box aims to provide a system to which a container is able to affect the size, order, position and distribution of its child elements. Through a use of a number of flex properties it allows control over the width/height of items, the direction, and most importantly it allows you to control how elements fill the remaining space within a container. Items within a flexbox are able to expand or shrink to fill remaining space or prevent overflow. The flex-grow and flex-shrink properties define how the remaining space within a container is utilised. In the below example the right-most element has the flex-grow property which allows it to expand to fill the remaining space in a full width div. Notice that by default, items within a flex box container will act like inline elements.

The main property available in flexbox is that of flex. By assigning the flex property to an element within a flexbox, we can control the width of items easily and responsively. Flex allows us to define the width of elements as a ratio of the total container width. In the below example, the last element (flex 2) takes up the same space as the first two (flex 1 + flex 1 = flex 2). This is very similar to the traditional CSS grid but with much greater flexibility. Any number can be used as the flex value (including decimals) allowing much finer control than a CSS grid.

My favourite flex-box feature by far is the ease in which alignment can be achieved. Prior to flexbox, achieving vertical alignment was a near impossible task which often left me giving up and manually setting the margin-top property of the element in frustration. Flex-box saves the day by providing an align-items property for aligning items vertically. A justify content property is also available for horizontal alignment. Using these properties on a container allows us to easily and painlessly align all child elements within a flex container both vertically and horizontally. The following example shows the various values available for the justify content property:

If you would like to read more, CSS Tricks provides a comprehensive explanation of the various flexbox properties available, as well as providing detailed examples. I highly recommend you check it out!

Here’s one I prepared earlier

Now let’s take a look at flex-box in action! The below example is one of our new web components showing off its flexy goodness. You’ll notice that for desktop, the right content view will stay at a fixed width in order to maintain readability and the image on the left the shrinks to fit into the remaining space.

To achieve this, we apply the flex-basis property with a value of 330px to the content container which tells flexbox that the container should not flex below 330px which ensures the content does not get too small. Next, we assign the flex-shrink property to the image container and set the background image to cover. This tells flex-box to shrink the image container to fill the remaining space in the container while maintaining the content at a fixed width of 330px.

When the mobile breakpoint is reached, we want the card to split into one column. To achieve this, we simply add a mobile media query to our container and set the flex-wrap: wrap property on the container. This property will break the content onto multiple lines if an overflow occurs.

Browser Compatibility

It is important to consider your user base when adopting flexbox. Flex-box is unsupported for Internet Explorer 10 and earlier, so you should either not use it at all, or use alternate stylesheets for IE. It is also worth noting that Safari 7.0 and newer have an telnet version of the align items property known as WebkitAlignItems.

Final Thoughts

While flexbox is amazing for achieving responsiveness in small web components, it does not do a very good job of laying out the page as a whole. For page layout, I still believe that the traditional CSS grid system is the best option. I recommend using a CSS grid system to lay out the main By Paul Pagnancomponents on the page, then using flexbox to achieve responsiveness on the individual components. This allows the page layout to remain intact when resizing, but allows the individual components to resize to suit.

In summary, I recommend considering flexbox for your next project (as long as you don’t have too many IE users).

Happy flexing!

Move over CSS grids, it’s flexy time was originally published in Kent and Lime Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Net Promoter Score (NPS) is an easy way of tracking customer satisfaction, which we send to the customer after each purchase. As part of the NPS feedback, we incorporate a free text asking the customer either what went wrong or what we could do better.

Whenever feedback is captured it auto-populates and creates a task in JIRA (for those not interested in using the API you can always use Zapier for integrations). The severity of each one was correlated to the actual score itself (1–6 was detractor and major, 7–8 was medium, 9–10 was minor). At the end of each week we amalgamate the feedback.

We are then able to prioritise tasks based on a function of the rank and count/frequency of severity. For example, we would prioritise feedback which had 10 items and had a number of majors and mediums over another piece of feedback that had 20 items with only minors and mediums.

Finally, we build stories out of each one of these and discuss feasibility before assigning story points to each one.

So, how has this simple strategy worked out for us?

When we started to collect feedback we were sitting at an NPS of 16.4. Since then, we’ve incorporated a lot of the feedback using the method above and from that the NPS has been growing. As of writing this article, we are sitting at an NPS of 27, a near 70% increase from just a couple of months back.

By Nick Tong

Customer Driven Development — incorporating the customer voice into our product design was originally published in Kent and Lime Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.