I say — Yes to automation! No to complexity! Hell yeah to collaboration and strawberry jam doughnuts!

Tom Parandyk
Jul 15 · 5 min read

🍩🍩🍩🤩

I will work with an assumption that you

want to ship features that matter and

don’t want to run out of money in the process.

It’s hard to deliver on the above, would you agree?

It’s hard because everything else gets in our way.

We are overloaded with meetings, specifications, refactoring, testing, bugs fixing, and deadline racing.

Specifications are never enough.

From problem solvers, we turn into ticket diggers.

The code we write becomes a tech-debt faster than ever

Here’s a list of the weakest links in our current workflow and some thoughts on what needs to change for us to start delivering at scale.

The hand-off

We build one product, not two, not three. The disconnection between product owners, designers, and engineers is staggering! We need to stop dividing deliverables into specs, mockups, and code.

Change: No process can change that disconnection on its own and without the help of smart tooling. What’s not enough: the fake mockup tools like Framer, InVision, Sketch; the templated app makers like Google App Maker, Appyourself, Trunkable, Zoho, and million others; the tools that integrate designers only on some points of the process, but not entirely, like Supernova, React Studio, PageDraw; the good, old school code editors, like VS Code, Atom, Sublime. We need new tools that make simple things simple, and complex things possible for everyone on the team.

The tech stack locking

Innovation and progress didn’t slow down. Last time it was React, this year it is ReasonML. What’s gonna happen in 2020?

The better the technology gets, the more it enables, the more problems it solves, the harder it is to choose and switch between many languages and frameworks without significant refactoring effort and taking big risk.

I’m a product designer, not an engineer, but I see the struggle against time and resources in my dev team.

Change: We need our architecture to be automation enabled with an easy way to swap languages and frameworks. We need smart compilers to let us try, experiment, and quickly assess the benefits of using other technologies in our stack.

The mindset

We are stuck in estimations and methodologies. We depend on the process more than on each other. We grow to become experts, and that’s ok, as far as we remain aware that the more we know, the more questions there is to answer. We take our jobs for granted. Let’s be honest we can always find another one. We identify more with a framework rather than a company and its vision. We don’t have time to transfer our knowledge on the job.

Change: Work should be challenging and fun. We should use one common lingo and environment where we can work together, discuss; share ideas, successes, and failures.

The inconsistent code-base and design system

It’s hard to make the code consistent when multiple teams work on different parts of the product. The same challenges apply to the code-base and the design system. Currently, we tend to throw more resources into the mix with dedicated Dev-and-DesignOps teams; and it works, don’t get me wrong, until you start scaling the company. People are the worst to scale.

Change: Not everything can be automated, I hope we all agree with that, like the decision making process. We need well-designed layers of automation to take care of time-consuming and opinion prone processes. I call it “Common Sense Automation”, which stands for flexibility of configuration combined with the simplicity of developer-designer experience.

An example of a simple thing is a change of the a color or label on the button.

An example of a complex thing is a requirement for a custom component, like Google Map.

An example of a configuration is a rule that compiles React code with JSX, or with separate CSS files.

The complexity of running services

I remember times when, as a requirement, we had to have two system admins for every four engineers. Then the Cloud and the Docker came along, and everything changed, became faster, more productive to set up, deploy, and test. Today there is no app without data, there is no data without services, and there is no service without Application Programming Interface (API). Unfortunately, we are still forced to design without data because, at the early stage, the services are not yet written.

Change: We need to get to the point when we can develop all parts of the product at the same time. Ideally, we would have the data schema and services derived for us from the specification. 🤔 Again, ideally!

So after all that ☝️, let me pose this question:

What if we could have an automated way for all the stuff we are forced to do manually 😏 ?

Would we use it?

☝️

(FYI, We are working on it either way because we need a way to stay sane)

Until now, we’ve managed to automate:

  • transformation of SVGs, images, and fonts into React components
  • generation of HTML and CSS as React<render> function
  • creation and management of application flow in React

Here’s a post with more details on the benefits and the workflow we managed to achieve as we keep adding more tools to our delivery process 👇

For release dates and early access to our tools, follow me here or on Twitter.

Views Tools

Find product market fit before you run out of money

Tom Parandyk

Written by

My goal is to simplify software development so that more people who find it hard to break into technology space have a chance for success. #techforall

Views Tools

Find product market fit before you run out of money

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade