The next instalment of this series of our Coolblue Tech Principles is on coding clean.
We prefer code that is easy to read and simple to understand. Code isn't just written for computers, but also for humans. Team members and colleagues have to read your code and understand it. Each programming language will have its own standards defined, but in general we all comply to the following programming paradigms.
YAGNI
You aren’t going to need it (Acronym YAGNI).
This is about not adding additional functionality to a product, until deemed absolutely necessary. Keep what we make focussed on delivering value quickly. If we need a knife to eat lunch, we create a basic knife. Not a scalpel and not a Swiss army knife.
The scalpel is over-engineered. Too much time has been spent on perfecting it for a use case that isn't applicable. The Swiss army knife tries to deal with all possible scenarios of usage and fails at really satisfying the customer need. In our designs we must still consider the future, we build for today without getting in the way of tomorrow. We build the simplest thing that works, without violating any of the other principles.
KISS
Keep It Simple, Stupid.
Coolblue is growing and that means increasing numbers. Increasing numbers of customers, increasing numbers of products, increasing numbers of stakeholders and increasing numbers of developers.
But, it should be understood we’re not even close to the same order of magnitude as Amazon, Facebook, Pinterest, or even some companies closer to home. Understand where we are. Understand what we need to be and how that should affect our choices.
We should have a target of getting as close as we can to scaling linearly. In some cases, this might be a stretch. In others, it’s probably an underwhelming goal. KISS is our goal, and any service that doesn’t meet this standard needs refactoring.
Don't reinvent the wheel
As a developer, you have a responsibility to know (or discover, if you don’t know) what is already available in our landscape. Therefore, when it comes to choosing a tool/technology/framework/library etc, you have a duty to consider if a pre existing item can fulfil that need. That includes, where appropriate, commercial of the shelf software (COTS) and open source solutions. Reuse over reinvent.
Be aware of where you should be placing your effort. As guidance, consider that we could say there are 2 types of development work:
Type A: Value Add - The differentiating factor. Differentiating between what the user sees today and what they want tomorrow. It’s what the Product Owner (PO) really wants.
Type B: Plumbing and foundation. E.g., the stuff the user doesn't care about and the stuff the PO doesn't see/ask for.
Examples of Type B development work:
- Libraries and tools for doing what you want (e.g., database interface)
- Logging/Monitoring etc
- Automated build/deployment etc
- Other shared/shareable utilities
Do not spend time on ‘Type B’ unless it isn't available.
Recognise that teams have a responsibility to improve/reduce their cost of development/maintenance. For example teams could consider a Commercial Off The Shelf Product (COTS) to replace a self-built system, as the reduction in maintenance cost may outweigh the initial cost over time.
Refactoring & A bit better everyday
We aim to address refactoring as part of feature development. Not as a separate refactoring activity. That makes it part of the cost of developing a feature. Only in the most extreme circumstances should refactoring be on a team’s backlog as only refactoring work, in which case it will need significant justification.
The choice on whether to introduce technical debt and the following consequences is a joint decision between a team, its lead, and the Product Owner. The Product Owner takes final ownership of the choice and any potential consequences.
We live by this rule: "always leave the campground cleaner than you found it". The same goes for our code. That means if you change some code you take ownership for the code in the encapsulating scope. If you want to make an improvement related to this, and on that rare occasion it is not part of a feature or story PR, you can use [SCOUT] as the prefix for your PR title.
For example, when changing something in a line of code, refactor the line. Change a line of code, refactor the function. Change a function, refactor the class.. Always using your best judgment. Keep it simple. This approach supports minor refactoring and consistent maintenance of (volatile) code over time.
Top comments (0)