I've been running Visuality software house for 13 years now and during this time I've interacted with a lot of founders and discussed their businesses. In time, the knowledge I've gained became more and more statistically significant and there is one thing I'd like to address - code quality & engineering approach in software development.
Before we jump into the article itself I'd like to just say a few words about our team. We are engineer-oriented experts. We focus on a very thorough recruitment process which allows us to hire the best talent - people that are not only great programmers in their field of expertise, but thanks to engineering approach, they are able to learn new technologies, approaches very fast and add a lot of value to the cooperation (but this will be explained further in both articles).
The projects I've been observing were varying between early-stage startups and mature, existing businesses. In each of those cases this topic can be addressed differently, so I decided to divide this article into two parts, each of them will be focused on a given type of project.
But before I'll dig deeper into either of them, I'd like to cover the basic question - what is code quality and what engineering approach really means. For this particular question I decided to talk to one of our most experienced engineers, because this matter should be resolved mostly by a technical person. I (more of a business-person) will later show you the impact of the technical approach directly to business.
So without further ado, I'll allow Michał Łęcicki, who holds a position of Ruby on Rails developer in Visualty, to say a few words about what engineering approach and code quality really are.
Engineering approach and code quality
At Visuality we believe that true engineers should possess not only technical knowledge, high level of skills, and experience, but also should understand the needs defining each product they are working on. Therefore, the approach every developer takes has two fundamentals: mastering technical excellence and being close to clients.
Let's start with the more obvious one: technical background. As every modern software house, we try to apply good practices defined by the software community:
- using TDD methodology,
- making code reviews,
- performing frequent deployments,
- monitoring app performance,
- using trusted tools to make it all easier (like CodeClimate or CircleCI).
But there are also a few things worth mentioning that are quite unique among other companies. First of all, due to extensive experience in creating web applications, Visuality was able to create its own development rules aka good practices. Our developers could see which theoretical rules are efficient in the real world and what's really working in our client's applications. It resulted in creating a set of guidelines expanding standard rules, eg. we know which library to pick or what problems to expect when using some certain API.
One secret technique used by our developers is a "study-plan-execute" method. It indicates the way every problem should be handled and solved efficiently. It's a very common mistake that when a developer is tackling a problem, he immediately goes to the implementation phase. It's easier and usually it works - after a few trials, changes in the code etc. it's possible to find a working solution. But it doesn't mean it's beneficial from a long term perspective (eg. it can introduce some architectural flaws hard to spot on the first sight). So our company policy says otherwise - spend at least half of the time on analyzing the problem: find different approaches to solve it, search for similar cases in other projects, ask others to share their knowledge and then create a detailed plan. Writing the code is the very last step and usually the easiest one when the developer knows what to do.
On the other hand, developers should not be completely focused only on the technical side of the project. It's tempting, because usually developers feel much better (and safer!) in a code editor than forming relationships with clients, but this is not the right way. We place great emphasis on understanding the real needs of the business and all feature requirements by each team member. It's beneficial in many ways: from making the implementation phase much easier (because devs really know how to implement certain features) to making suggestions by developers about feature changes or improvements. It's often the developer who can realise how to solve business problems in an easier or better way.
Nowadays, applications could be written using different languages, libraries and infrastructures and each choice has its pros & cons. Understanding business needs can help in picking up the right one and building applications prepared for future expansions. Also, when the team understands the core of business logic, they can write the most important parts of the code more carefully and test it more extensively (such code usually is also double-checked during code review). This ensures that more time is spent on the things that really matter.
One last thing, being close to the business often means being close to the client. We try to have refinement meetings with the whole team and the client to get to know each other better. Thanks to that a lot of knowledge can be shared and developers have a chance to ask questions not only about specific features, but also about the application itself, current problems and challenges or plans for the future.
Engineering Quality for Startups
Now that we’ve covered the basics (thanks to Michał Łęcicki) I hope you have a better understanding of engineering quality (from now on that's what I'll call engineering approach combined with code quality).
So let's take a look why as a newly founded startup you should (or shouldn't) care about it.
What's the typical story behind a startup? Naturally, a founder (or few of them) has an idea of solving a business problem for a group of consumers. I won't dive into the common problem that a lot of the founders have limited knowledge of those problems, having just a "cool idea". For the purposes of this article, let's assume that we're dealing with a person that is well prepared for the journey.
In most cases, the software is the key to solve the above mentioned problems. Now it all comes down to funding. If we assume that you have a limited amount of money then it means that you have to test your main hypothesis as fast as possible. In that case it's hard to actually follow engineering quality - but it doesn't mean it's impossible. :) In my professional opinion, the right approach here is to do a prototype and test it. Most probably it would be a throw-away prototype, but at least you will have good feedback. If you want to know more about prototyping you can read this article, but in a few words - prototype will not focus that much on the code-quality, which probably will mean faster delivery time, but rather try to pin-point the main problem and solution.
IF your hypothesis will be proven, then you already have a proof-of-concept app and first clients. All of this will make it easier to gather more funding to build a solid application.
Second scenario is having a sufficient amount of funding to skip the prototyping phase and focus on building a quality-engineering product from day one.
Why is it important? It's simple. If your product achieves success then you will save yourself the time and money that you would need to refactor a low-quality code in the future. Additionally, having the business-oriented approach (which in my opinion is the key to engineering quality) will allow you to focus on essential features. In a few months you will have an app that will last for a long time and will be easy to expand, as the documentation, tests and proper architecture is there. The reason for saying so is actually my own experience at Visuality - very often we have a client that has a already gathered a lot of users, but was written with no (or very little) engineering quality. And bear in mind, that having a lot of clients, demanding new features, is not the perfect moment to actually refactor/rewrite most of the code. So what we usually do is fix whatever can be fixed in as little time as possible and then focus on features with the "refactor while doing" approach. It works, but is taking time, and still doesn't give as good results as one would hope for. But in many cases it's the only way. I know for a fact that those founders realise what mistakes they have made in the past, but it's a little too late to fix that. That's why I truly believe that as a young founder you HAVE TO understand what the whole engineering process is about. You cannot simply assume that it will work - it's never that easy.
Now there is one thing I said, that some of you may misinterpret. I assumed that if you have money you should go with the full blown quality engineering approach. It's not always this way. It all depends on the level of risk that you see in the product you're building. If you have a lot of money, but the risk of failing is huge, you should consider prototyping nevertheless. Sometimes the risk is high, but the competition is breathing down your neck - maybe quality engineering is the way here? I'm simply trying to say - there is no such thing as "one size fits all" solution. EVERYTHING in the software development process should be based on business decisions. Let's say you want to skip tests - if that is based on the business decision (the software can be buggy as hell, but hey, at least you have customers and you will deal with it later - maybe it's a good thing). I'm not the ultimate expert here (and nobody is) - you have to make this decision on your own. We as a software house are happy to show you the possible directions, their drawbacks and advantages (please do remember though, that skipping tests is an extreme example and we never recommend doing that as it raises the costs of any future development).
Seems hard, right? Yeah, nobody said that running a tech-oriented business is easy, especially if you're not a technical person yourself. That is why I always say that if you want to run any business you should understand its foundations - this will make your job easier in the end. But to be honest - that's the only, responsible way to go. Some of the most successful founders I met actually did this homework. I hope you are one of them and if you need any advice/direction - I'm happy to help. You can reach out to me directly at michal@visuality.pl.
For now I'd like to put a comma, next week I'll dig a bit more into quality engineering for existing products (although in this article I may have spoiled it a bit). [UPDATE] Here is the link to the next article.
