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

What can developers do to speed up time to market 🚀

alexandrudanpop profile image Alexandru-Dan Pop Updated on ・1 min read

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 been thinking a lot about this lately 🤔, also tweeting about it:

👇 Comment below 👇

Discussion

markdown guide
 

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.

 

I agree with the points mentioned. But I'd like to add that only less experienced developers (we have all been there!!) like to reinvent the wheel or over engineer.

The more experienced ones know what this leads to and make a constant effort to reuse and avoid reinvention, as well as keep things simple (iteratively, if otherwise not possible).

If we do want to reinvent or over-engineer for pleasure, we do so in our pet projects, not while on the clock.

 

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).

Yep, there is definitely a perceptional mismatch between frontend and backend on the client side.

But I don't think backend work will be rationalized any time soon. At least not for tailor-made solutions. Someone has to take care of the business logic behind the frontend, no matter what service you use.

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).

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.

And were would the business logic go? The core logic that no SaaS (Firebird, AWS, Azure services) can deliver out of the box?

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.

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

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

 

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.

Absolutely 👍👍 Well said. And yes, I am grateful for every programmer who has gone the extra mile to save my time. And that is exactly what I'm trying to do with my code - save time for those that read and work with it.

 

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

 

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

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. ;)

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.

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 :)

 

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.

 

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.

 

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
 
 

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?

 

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.

 

Thanks for the input will check out your blog post!

 

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.

 

Absolutely. Sad thing is, many decision makers (especially those not experienced enough) come to the opposite conclusion by not seeing the speed of a project in the long run but only at the moment.

Those tend to be unwilling to go more slowly now (= invest in a clean and solid codebase) in order to be faster (more flexible) over the entire product life.

Of course, Pros always know that quick and dirty is the road to hell.

 
 

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.

 

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

 
 

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.

 

I think this instigator questions has it backwards. It reads as though it's primarily the dev's responsibility to get a product into market quickly.

I'd say there is not really much a developer can do -- assuming they are pros and highly efficient.

Given the iron triangle (scope, cost, time) I'd say you get into market faster if you reduce scope (thus, deliver less features). It's that simple. But hardly a paying stakeholder is willing to do just that.

 

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
 

Reducing scope is the silver bullet in my opinion! But as you said, sometimes is difficult to convince the stakeholder to think or act like that. In a perfect world, I think it takes to do do A/B tests constantly to know which features the end user value most and, that way, can continue in the product.

 

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.

 

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 🙃