14
.
11
.
2023
28
.
12
.
2020
Ruby on Rails
Business

Why code quality and engineering approach is important for your business. Part 2

Michał Piórkowski
Founder

Engineering quality for mature products

In the previous article I covered the basics of what code quality & engineering approach actually means (just to remind you, we call them engineering quality from now on) and I also described their value for early-stage companies that need to make a decision regarding the approach used to build their initial product.

In this article I’d like to focus on another type of product - mature one.

First, let’s understand the basics - as to what do I mean by saying “mature product”. In most cases it means that the product:

  1. is already existing in terms of application written and working (na matter the state of the code).
  2. initial or full-blown traction is there - so there are a lot of clients using it.
  3. the business model/idea is proven - it means the founders now know for sure that they are indeed solving a business problem of their customers.
  4. the interest for the product is growing.
  5. there are plans for new features.

It doesn’t mean all of those elements have to be present, but definitely most of them should be there.

Now, what does it mean for a mature product to take the path of quality engineering. In our case we always suggest starting with an extensive code audit. The reason for that is twofold:

  1. Understand the code better, as we are going to work on it in the future.
  2. Understand (and this is important) the state of the application. This gives us the opportunity to understand which approach (quality or non-quality) was taken when building the initial version, and what comes after that, how much effort is needed to be sure that the code is decent, there are no (or limited) legacies. It also gives a good helicopter view about possible security and performance issues.

Once we have done this the next step is - OBVIOUSLY - understanding the business. We (as your future tech partner) need to understand what is your current business model/shape and (what’s even more important) what are your business goals for the future. Knowing those two we can then discuss the potential features the client wants to build and analyze if those features are actually the best way to achieve your goal. Based on the business requirements we can also make some tech-related decisions as to which parts of the system need to be refactored/rebuilt or rewritten from scratch. Sometimes it’s wiser to actually write parts of the system from scratch, if the old code is really bad - especially if those parts will be expanded in the foreseeable future. This will not only save money in the long run, but will also cause less bugs and problems on the client's side - and usually the client is in a point where he needs to be sure of the stability and performance.

Once we know all those facts we can plan our work - create a solid implementation plan, together (if applicable) with a plan to refactor what needs to be taken care of. This not only guarantees the client a solid plan of work, but also makes him safer in terms of being a predictable partner for the clients.

The good news is - you are in good hands if this is the approach, on the other hand this will demand a lot of effort from you. Sometimes the hardest part is for the client to understand that if something was built 5 years ago and is still working then it doesn’t mean it’s care-free. In most cases the fact that nobody touched the app for quite some time means a LOT of work just to make it up-to-date. And (to answer the question you may have) you absolutely need to do it. Otherwise, you’re putting your data/business at risk of vulnerabilities that may be present in legacy solutions. This is a key factor to understand whenever trying to drastically expand any existing system. But speaking about the effort mentioned - you will need to spend a considerable amount of time to:

  • Explain your current state of the product.
  • Write (together with our PM who would guide you) very detailed business requirements for the future plan of your product.

This is essential - only when we have a good business plan we can focus on engineering work. Otherwise you are just hiring a feature factory and basically burning cash in many cases - and believe me - nobody (especially engineers) wants that.

In Visuality every team member wants to contribute to the business with any means possible - engineers by their work, project managers by managing it all, and the business side (me and Michał Krochecki) in any kind of connections/partnerships/VC contacts possible. We truly want to be considered as your tech partner, as we believe that in most cases this is the way to go.

Michał Piórkowski
Founder

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Michal - Highlights from Ruby Unconf 2024

Highlights from Ruby Unconf 2024

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality
Cezary Kłos - Optimizing Cloud Infrastructure by $40 000 Annually

Optimizing Cloud Infrastructure by $40 000 Annually

14
.
11
.
2023
Cezary Kłos
Backend
Ruby on Rails

Smooth Concurrent Updates with Hotwire Stimulus

14
.
11
.
2023
Michał Łęcicki
Hotwire
Ruby on Rails
Software
Tutorial

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial

GraphQL in Ruby on Rails: How to Extend Connections

14
.
11
.
2023
Cezary Kłos
Ruby on Rails
GraphQL
Backend
Tutorial

Tetris on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Backend
Frontend
Hotwire

EURUKO 2023 - here's what you've missed

14
.
11
.
2023
Michał Łęcicki
Ruby
Conferences

Easy introduction to Connection Pool in ruby

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Ruby
Tutorial

When crazy ideas bring great time or how we organized our first Conference!

04
.
12
.
2023
Alexander Repnikov
Ruby on Rails
Conferences
Visuality