loading words...

Dec 03, 2018 12:10:30

Designing A System

by @valentino | 455 words | 77🔥 | 453💌

Valentino Urbano

Current day streak: 77🔥
Total posts: 453💌
Total words: 216096 (864 pages 📄)

We always love to just jump in and start coding away at problems before we are ready to.

We create a new project, start coding our vision just to just realize hours later that we didn't think it through and need to throw away code.

Next time you think about starting a new project stop. Analyze the problem first. Make a design documentation. I know what you're thinking about, a design documentation for my side project? That's way too much!

It doesn't need to be an actual formal document, it can be a text file where you write down your ideas so you have a frame of reference later.

- Architecture and Why

Of course, this applies mostly to medium/big projects. On a small and time constrained project, this might not be viable, but you should still do a minimum of analysis. You are going to save time when you realize that like you coded it's not going to work and you need to rewrite the whole thing. If you planned you would have noticed the problem in the planning phase and already solved it even before writing a single line of code. Of course, there are a lot of problems that only emerge once you start coding, those are fine but don't have those on top of avoidable ones too.

- Database Scheme

If you're using a database take time planning out your models and relationship. You can optimize access time, decide if you should have an index on a column or on another and which foreign key constraints to apply.

- API Endpoints

If you're using or serving an API take time to define your API specification. Make sure to also write it down, so you don't have to change it once you already started and forget to reflect the changes in your documentation. You'd never want to publish a document that doesn't apply to your API because you added something at the very last moment.

- Auth

If you have User Accounts and an auth system first ask yourself. Why? Do you need it? If you don't just don't have it! But if you do, remember that you need to abide by GDPR and store the passwords securely. Use a known and recognized framework. Don't roll your own, please...

Next decide how your application will authenticate, if with tokens, OAuth, password grant. Each has its own pros and cons.

Keep in mind that, in most mobile applications, it is trivial to extract a key from the application archive. Have other safeguards in place to protect your server.


Next time you're building something take the time to dive keep on the design side before jumping into coding.

You will thank yourself for that later on.

Originally published at www.valentinourbano.com

  • 1

    @valentino Usually I prefer to start with defining what the value proposition is (why I want to build this). Then I do the visual identity (it's inspiring me to name my db tables haha). After all that I do the back-end, and finally the front.

    Basile Samel avatar Basile Samel | Dec 04, 2018 10:17:37
    • 1

      @valentino @basilesamel Yeah these steps are for when you have already decided what to work on. Before doing that you should define the value proposition and the reason why the product should exist.

      One thing to add would be the visuals I agree, but it has never been my strong suit.

      Valentino Urbano avatar Valentino Urbano | Dec 04, 2018 17:25:52
contact: email - twitter / Terms / Privacy