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

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.