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:
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (30)
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 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:
React, Vue
the JAMStack concept:
Hi Alex,
Look at these articles about SPA I agree with:
You mean Rails, right?
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).
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.
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.
Slow down!
Yes, you go faster by slowing down. Going fast is only faster when you are perfect, which nobody is.
Well said! 👍
There are two ways to speed up time to market.
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!
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.
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.
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.