DEV Community

Cover image for What can developers do to speed up time to market 🚀

What can developers do to speed up time to market 🚀

Alexandru-Dan Pop on June 21, 2020

Hello developers, let's have a chill discussion about: main things we can do to speed up time to market or help an app reach MVP level I've be...
Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop • Edited

Go for Serverless or JAMStack approaches

Those technologies allow developers to leverage the cloud as much as possible - hence focus on building applications, not complex backends.

Of course those are not always possible as sometimes the API's are your selling point.

Leverage external tools instead of building your own

Let's be honest. As developers we like to re-invent the wheel. There are hundreds of programming languages. Dozens of libraries that do the same thing, for each language.
Break out of this loop, re-use what you can and focus on delivering the needed value.

The art of keeping things simple

Developers also love to over-engineer things.
Product owner needs to show the users birthday on the settings page? Well of course it can't be done without having a few microservices communicate in the backend through a service bus. And all indexing in Elastic needs to be changed before you can get that data. Frontend... you'd better forget about it... we need to spend a month first to configure webpack for the new birthday-settings microfrontend. Also the frontend will depend on the i18n microservice that is being refactored so that will take some time.


Seriously now, don't do this. Build things in a simple and easy to maintain way. Challenge over-complicated designs.

Collapse
 
pavelloz profile image
Paweł Kowalski

I think your second point invalidates the first one. ;)

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

Might be, depends how you interpret the words :) What do you mean?

Thread Thread
 
pavelloz profile image
Paweł Kowalski

Well, going for serverless if you have a simple business site to do, with no DB, no processing, means you will inevitably overcomplicate a simple website.

I think most of the problems I see nowadays in frontend dev sphere are a result of overcomplicating everything and unconcious love for wasting time by devs. ;)

Thread Thread
 
alexandrudanpop profile image
Alexandru-Dan Pop

Yeah I know what you mean I wouldn't go serverless unless you actual need server side code. Would use static site generators if I see a use for them (ex build from markup files) or simple HTML files.

Thread Thread
 
pavelloz profile image
Paweł Kowalski

Yeah, and as someone with serverless experience (both native aws click through console, SAM, Serverless framework) i know it can be a timehole where suddenly you spend 75% setting up and maintaining serverless instead of focusing on the core of what you want to achivee.

I would personally treat serverless as cost & performance optimization (after MVP is done and works). For those who are not fluent with serverless tech, and only recommend going serverless from the start for advanced users who did it at least couple of times.

Im a big advocate of serverless, just not for novices and not when there is a deadline on their head - this probably wont end well for most :)

Collapse
 
alexlion profile image
Alex Lion

The best advice I've ever been given and I often see is: Use tools you master.

I tried to use JAMStack with serverless, it's like microservices. You use something you don't really need.
It's over-engineering.
Using React for Front + Hasura/Apollo Server for Back + Auth0 + Functions...
It adds a lot of complexity that you don't really control. I don't talk about Firebase because I don't like lock in but if you have a small app that's not going to grow in the future, it's still decent.

I use tools I master, monolith app. Rails is my go-to. I can build a MVP with builtin authentication with Devise in hours.
Gem are not like NPM you can download. It's not a package developed by a solo guy and updated 3 years ago. No.
Rails and its dependencies are battle tested by big companies like Basecamp, Github, Dev.to etc.

So, you can sleep soundly at night about the safety and robustness of your application.

All trendy topics like React, Vue... are dangerous. Remember: these technologies have been created to answer problems with huge application like Facebook. Your MVP don't need that.

Collapse
 
leob profile image
leob

So what's interesting is that we all agree on "don't over engineer and keep it simple" but when deciding on how to keep things simple we may end up with completely opposite solutions ...

Person one says "keep it simple, so use JAMStack and Serverless" ... :-)
Person two says "keep it simple, so don't use Serverless, use Rails" ... :-)

As we all know, keeping things simple is ... hard.

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

Serverless - like firebase:

  • you can abstract it in a thin layer - that can be replaced later if your app is succesful
  • you focus first on the thing that matters the most - building the app & getting a project shipped

React, Vue

  • would say it would be more dangerous to go rogue and build your own SPA-like tool
  • those are battle tested technologies used by large companies.
  • they provide a declarative way to encapsulate componentes and stateful logic & I think this speeds up developent & go-to market time

the JAMStack concept:

  • app is totally decoupled from API's
  • you think about performance
  • deploy app on a CDN - very easy to do today
  • leverage external APIs before building your custom ones
Collapse
 
alexlion profile image
Alex Lion

Hi Alex,

Look at these articles about SPA I agree with:

Collapse
 
pavelloz profile image
Paweł Kowalski

Gem are not like NPM you can download. It's not a package developed by a solo guy and updated 3 years ago. No.

You mean Rails, right?

Collapse
 
leob profile image
leob • Edited

You know what's the pattern or the tendency that I'm observing more and more? I think increasingly the perception is that the added value is in the frontend rather than the backend.

Why? Because the frontend is what users directly experience and also where you can most easily differentiate yourself from competitors.

Also, with things like Firebase and Serverless it looks like backend is becoming more and more commoditized.

Devs who only do backend should watch out, going forward they might be out of a job sooner than we think. Like it or not, I think the future is frontend (and for the time being fullstack is also still okay, but I fear that even that will largely go away).

 
leob profile image
leob • Edited

It's still there, but it's just a small snippet that gets uploaded as a Firebase proc or a Lambda function ... the point is that often (way) more than half of backend dev consists of "standard" things like signup, auth, sending emails, logging, monitoring and so on, much of which can be commoditized.

My wish or my intention is not to predict gloom and doom, I'm just trying to be realistic, I really see the writing on the wall. Devs who only do backend should be concerned, maybe not in the short term but for sure in the long term.

Thread Thread
 
alexandrudanpop profile image
Alexandru-Dan Pop

Goes the other way arround. You could go ahead and say frontend developers will not be needed because there will be very smart AI-powered app builders :D

Thread Thread
 
leob profile image
leob

Absolutely, eventually everything might be automated away, we can all go on eternal vacation.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao • Edited

If they had not done any grunt work like conducting user interviews, user persona, user journey, validating their idea to come up with a list of features for MVP. I would go this route.

1) Work with them to Interview the client and users to understand what is the list of features, pain points, the business objective for the MVP
i) Create a Lean Canvas
ii) Creating a design style guide
- Colour Schemes
- Typography
- Icons
- Logo
iii) User Flow/ User Journey/ Jobs to Be Done

2) Design a wireframe in Figma/Xd/Invision Studio/Sketch

3) Create a high fidelity design of the wireframe (May be considered an MVP as this can be presented for further user interviews)

4) Retrospective on user feedback, duration of development work, scaling down of features to qualify as an MVP.

5) Build it out & deliver the MVP - By then you can scale down the list of features based upon feedback and timeline to deliver the bare minimum amount of features base upon previous work in the high fidelity design and user feedback.

Collapse
 
elmuerte profile image
Michiel Hendriks • Edited

Slow down!

  • Write clean code.
  • Automate testing
  • Low Coupling, High Cohesion
  • etc.

Yes, you go faster by slowing down. Going fast is only faster when you are perfect, which nobody is.

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

Well said! 👍

Collapse
 
robdwaller profile image
Rob Waller

There are two ways to speed up time to market.

  1. Cut scope.
  2. Hack the **** out of things.

My advice is always go with option one, as option two will always result in unintended consequences, poor output and problems and costs later on.

I've written about this previously under the idea of the "Law of Minimum Cost". rbrt.wllr.info/2019/03/15/minimum-...

Also if you're selecting tools and technologies based on a perception they will speed up delivery then you are selecting tools and technologies for the wrong reasons in my opinion.

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

Thanks for the input will check out your blog post!

Collapse
 
meatboy profile image
Meat Boy • Edited

Learn Docker 😀👌 it saves a lot of time and makes setting up new services very easy

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

💯

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

Maybe sometimes too easy. It's like npm but for backends 🙂 easy to end up with some extra unneeded containers that people update and maintain later for no reason.

 
alexandrudanpop profile image
Alexandru-Dan Pop • Edited

You are making a point here, I am also wondering if development is headed in that direction.
The thing is there are repeatable things that you always need to do backend-side for every project like - authenthication, authorization, user management, containarize, ci/cd, setup an gateway proxy with TLS termination, ensure you have backups, etc. Those things can take a lot of time from the backend developers, so it might make sense that even they would leverage tools that gives them those repeatable things out of the box so they can focus on business logic.

I think there will always be needs for backend developers, but we will have services that automate some repeatable code (we already have).

Thread Thread
 
leob profile image
leob • Edited

I really HOPE that there will still be demand for backend devs, but my fear is that backend is the first thing that MIGHT be commoditized. I don't hope so, but I discern a trend, frontend is more and more stealing the spotlight and many devs are saying "oh don't worry about the backend, we'll just use Firebase".

We'll see, but I wouldn't be surprised if 5 or 10 years from now frontend is where it's at, and backend has become marginal. Not because I want to or because I like it, but I see the writing on the wall.

But I really do hope I'm wrong, and this "prediction" isn't going to materialize.

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

I like this tweet that illustrates this:

As a senior dev you really add value by thinking of ways and writing code that optimizes other developers time.

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop • Edited

Of course it's not only the devs job to figure this out - but I think we can help in a few ways:

  • we can have tests that show us how confident we are of the current features
  • strategies in case things go wrong (backup & recovery)
  • good CI/CD makes sure we can fix and ship new things fast
  • we can simplify some technical designs to help with reducing the scope
Collapse
 
ugglr profile image
Carl-W

Recently started looking at Strapi and I think it something with good potential to get up and running fast, and also keep performing if things should take off.

Collapse
 
kayis profile image
K • Edited

I've thinking a lot about this too in the last years. To educate people about this topic.

That's why I started Fullstack Frontend.

Much is happening in that space 🙃

Collapse
 
sebbdk profile image
Sebastian Vargr

Cheap, good, fast.

Pick two.