Technology Blog

We’re primarily driven by meeting 7digital’s goals and objectives

• Everything we do should be driven by clear business goals and objectives. Where they are lacking we should go and find them.
• We expect business needs to be provided as problems that need solving with clear expectations and measurables without prejudice towards the implementation.

Release Early and Often; Fail Early and LOUDLY!

• It’s essential we can respond quickly to changing business requirements. The best measure of our effectiveness in doing so is via frequent predictable releases through a steady rhythm of working. Things need to be easy to change (maintainable) and delivered at a sustainable pace.
• It’s far more preferable to get something in production as soon as possible and develop iteratively based on feedback than to get bogged down in speculative analysis or a fear of not making all the right decisions up front (be that regarding technology choices or requirements).
• Failures are expected, and welcome. When projects fail, we learn about other routes that might work. When software fails, it tells us about invalid assumptions we’ve made. The earlier and louder the failure, the more valuable that information is.

The best solutions come from everyone working together

• We do our best work when we work closely and collaboratively – within teams and across organisational disciplines.
• As much as we all have our specialities the most effective outcomes come from great collaboration and teamwork and rarely from deference to authority.
• We actively encourage a culture of healthy conflict and disagreement, but we also expect everyone to respect each other’s differences, to be looking to get the best out of each other and – when the consensus is against us – to work towards the chosen solution as if it was our own.

We prefer to solve problems that people haven’t solved before

• We prefer to use things that are already there. When faced with a challenge we should first be looking for – and evaluating – prior knowledge and implementations , whether that be internally, via open source software or 3rd party vendors.

• When we can solve problems using other people’s tools or software, we have a preference for things which are already used, already known, or already written … in that order.

We prefer not to do the same thing twice

• Repetitive manual tasks are cumbersome and prone to human error. If something needs to be done twice it should probably be automated.
• To aid this goal, when making choices we should lean towards those technologies that lend themselves to automation. These technologies often share characteristics such as having an API; being drivable from a CLI; not having licensing complications that require manual interactions; choosing to ask other services for information frequently rather than storing it internally.
• However, we’re aware of the desire to abstract solutions too early, in order to solve superficially similar problems with the same tool. We know this is both attractive and dangerous!

We make and use things which are discoverable and accessible by design

• Our applications and services, and information about their states, should be easily discoverable and accessible by services such as diagnostics, monitoring, other collaborating services, and the human eyeball.
• We should all work towards and comply with common shared standards, whether that be internal ones or industry best practice. Where those standards don’t exist we discover and implement them.
• We prefer 3rd-party technologies which are easily discoverable by design and best comply with our shared standards.

We are mindful of failure

• All our applications need to be resilient, robust and secure. To achieve this we should be preoccupied with all the ways our services can fail and design them in a manner that means they degrade gracefully, we’re alerted as soon as something is wrong and can quickly diagnose and rectify problems.
• We resist oversimplification and the urge to write off small problems as “business as usual”.
• We encourage a just culture where people can feel safe to report adverse events and near misses without fear of punitive action.
• We’re mindful of all the possible ways that our services could be exploited and have security front of mind with everything we do.

We don’t like inappropriate intimacy

• Applications or services should not have intimate knowledge about the innards of anything else.
• If one service fails this should not indirectly affect any of our other services.
• Tight coupling via unnecessary dependencies also causes business friction and slows us down.

This entry was posted on Friday, January 4th, 2013 at 10:11 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.