The RAD philosophy

Introduction

What does it mean to be a RAD, or responsibly acting developer? In general, it means you will try to uphold the values that we stand by. As a result, for every decision you take for your team, you will try to take all the factors into account and do the right thing.

TL;DR

- I don't feel like reading all the stuff below, can you summarize?
- Sure! Don't do anything that will hurt your team or project in any way. Also, get certified and put a sticker on your laptop!

6 factors to take into account

When choosing any technical solution for your project, there are 6 main factors you will want to consider. We will give you the short version on this page.

1. Technical fit

Is this technology suitable to solve my problem?

In any case, you will want to choose an option that makes your life easier. This can only be achieved if you choose a technology that is adapted for the problem you are solving. It is possible to do almost anything in any framework, but if you choose poorly, it will just work against you.

Ask yourself questions such as:

  • Does this help with our problem?
  • How does it compare against competitors?
  • Is there something that will help us more?
  • Is this the simplest thing we can do?
  • Does it bring unnecessary costs?
  • Is there extra maintenance after we implement this?

2. Check for warning signs

Can this technology become a risk?

Even if a solution fits technically, it can still become a risk to your project. For instance if the only maintainer stops maintaining it, if the company gets bought by a competitor, if the licensing terms change, etc. You will have to assess the likelihood of such a thing happening for any dependency you have.

Ask yourself questions such as:

  • Who maintains this library?
    • Are there multiple maintainers?
  • Are they still actively working on it?
    • Are there recent commits?
    • Did they write a recent blog post about it?
  • Is the source available?
    • Is it readable and well structured?
    • Can we legally use it?
  • What does the licensing model look like?
    • How likely is that model to change?
  • Has the product recently been acquired by another party?

3.Team skills

Can we get everyone up to speed on this?

Once you start using a certain technology, it becomes embedded in your solution. This means that almost every team member will come into contact with it sooner or later. And that means that they should all have a working knowledge to develop, monitor and troubleshoot this particular piece of technology.

Ask yourself questions such as:

  • Do we have the knowledge?
    • About what it does?
    • About how it is meant to be used?
    • About what the pitfalls are?
  • If not, is the knowledge available?
    • Documentation
    • Tutorials
    • Book
    • Code samples
  • Can we teach the team?
    • Should we give a presentation
    • Can we build a POC together (hackathon?)
    • Does everyone have the background to understand?
  • Can everyone do some work with it?
    • For the initial implementation?
    • To build new features with it?
    • For maintenance?
  • What documentation do we need?

4. Take away the magic

If you understand how it was built, you’re a lot less likely to use it wrongly.

For a lot of developers, key libraries in their solution are like a black box full of magic. These libraries solve a problem for them, but they have no clue what is going on inside. And because of that, they are way more likely to misuse that library and cause problems. By studying these libraries in more detail, you can avoid these problems most of the time.

Ask yourself questions such as:

  • Do we know how it works?
  • Do we understand how it was built?
    • What did the developers use?
    • What concepts & technologies are applied?
    • Could we (theoretically) build our own?
  • Do we know what the effect of our usage is?

5. Trim your stack

When new tech goes in, old tech must go out.

When working on a long lived project, it isn't uncommon that you change the way you do things. You switch to a more modern way of doing frontend, you introduce new backend technologies, etc. What is important, however, is that you keep the size of you stack under control. This means that with every new introduction, you must seriously ask yourself if another technology can be phased out, and if so how much effort that would cost. Keeping the old one around is never free!

Ask yourself questions such as:

  • What problem does this new tech solve?
  • Do we really need that?
  • Which old, similar, thing do we have?
  • Can that be replaced by the new one?
  • How much effort would that be?
  • What effect does having both have?
    • On the maintenance of our solution?
    • When we're on-boarding new developers?

6. Evolving Architecture

Your architecture should follow your problems, not the other way around.

Doing microservices because Netflix does them is as bad a reason to make that decision as getting a Ferrari because Bill Gates has a Ferrari. Your situation is not the same as theirs! And as long as you don't have a real reason to do microservices, they will just get in your way. So architecture-wise, it makes sense to start with the simplest thing you can get away with and then find out, as you go, what architectural challenges you encounter.

So in short:

  • K.I.S.S.:
    • Start with the simplest solution. (A monolith?)
    • Discover your needs from PROD
    • Adapt to those needs, extract services
  • Start with microservices when:
    • Services need to scale independently (balance scale with cost)
    • You have multiple clients (so they can adopt features at will)
    • You have different technology stacks
    • You have conflicting dependencies

Conclusion

There is no golden rule, but taking all the above factors into consideration will at least give you a way to start thinking about the decisions in front of you. Good luck out there, you will need it!