Building a top-notch software development team. Confession of a CTO
What influences the code quality? Is it just the responsibility of developers? They need to be passionate about their work or just be experienced? What makes developers bad? How to maintain the best security of their work? How to manage their work? How to estimate software development?
These are the questions that every person responsible for building a software development team has to answer.
After 11 years of experience as a software engineer and then as a CTO of a software company Untitled Kingdom, I want to share with you more thoughts regarding key challenges in building software teams.
If you are more interested in the topic, here you can find my first article about code quality.
DON’T CHOOSE BETWEEN PASSION OR EXPERIENCE IN SOFTWARE DEVELOPMENT. YOU NEED THEM BOTH
If the software is being used and further evolved during 5, 10 years, many people will try to work on it, and each of them will struggle with those problems and pay for them with time when trying to understand the code, when trying to modify the non-modular, amorphic, copy&paste code absolutely unfit for any evolvability, and finally when hunting bugs caused by those failed attempts. And the time of those people is quite expensive and it is the customer, originally supposed to profit from the quick hack solutions, who pays the bill.
Jakub Holý, quotation from his blogpost Code quality matters to the customers. A lot.
So there is one of the most common problems for young startups and companies, especially when there is a lack of technical knowledge, which can be used to verify if the codebase quality is doing ok. Let me explain.
Experienced developers and companies know their value. And even though at first sight it might sound like its a lot, compared to wasted time, money and nerves you can end up with working with someone passionate but inexperienced. But remember that a higher price doesn’t have to mean better quality. It’s always necessary to do your research.
If you are a technical person, you can, of course, verify the approach and knowledge by yourself. So what to do when you lack that valuable knowledge? Try to look for someone in your friends’ network that could help you or at least look for some references that could express their opinion and experience with a particular team, person or company.
SECURITY AND IMPORTANCE OF REFACTORING
Talking about security, its recommended to have a process to check those things once in a while. Most often our apps evolve and pivot over time. Continually adding and changing features sometimes makes it difficult for the codebase to keep up with the concepts that developers have designed initially without that knowledge. That is why it’s best to take it into account in a software development process as a regular and very good habit to do. As with everything, it is better to do it often and in small pieces, before the number of things to fix will be overwhelming.
If we are going to get there it might be sometimes better and simpler to rewrite some modules from scratch but that, unfortunately, takes a lot of time and might fix current problems and bug, but almost certainly it will generate new ones.
I was in that situation where the legacy code wasn’t allowing me to add newly requested features, wasn’t super readable, but the most important thing was that it wasn’t extensible.
It took me a long time to make the right decision as the code was not covered with tests, so the refactoring was dangerous, and rewriting the whole module would take me two months at least. Adding a unit test to a code that needs to be refactored doesn’t make sense as it will change and usually if it’s not a right code will be impossible. That’s why I figured out that creating more complicated UI test scenarios will make sure that any changes I will perform won’t affect the current behavior. And I could comfortably start refactoring. In the end, I gained a new automated tool for future use, improved that lousy code, making it ready for adding new features and saved over six weeks of rewriting time.
Rewriting software is the most tempting solutions, especially for less experienced developers. That is why it’s good to challenge developers to see if there are maybe any other options. Sometimes complete rewrite might be the best solutions if the codebase is in pathetic condition. But I suggest to leave that option to be the last resort but don’t ever exclude it as a possibility.
HOW TO MANAGE THE WORK OF DEVELOPERS. PEER REVIEW AND TOOLS
Developers should be familiar with the possible amount of the codebase of the project. Depending on the size of it might be a complete app knowledge or at least one complicated module. If only one person has an idea of how a system works under the hood, it is a huge business risk. Especially if the quality of the software was very poor and undocumented.
Let’s imagine a situation where that project guru is absent for some reason. Not a very bright future, unfortunately. Even coworkers might have a problem understanding and onboarding to some parts of the system then.
There is a process that can improve two things at once. It’s called peer review. How it works is that besides the author at least one (or preferably more) colleagues examine every single change in the products codebase, document, graph, design or anything created to evaluate its technical content and quality.
The first problem it solves is the project knowledge; thus the author is not the only one that knows the mechanics of his creations. What’s more, it also reassures that the quality of the produced code is reviewed and evaluated by someone else. If that process works well, we can be sure that nothing sketchy won’t pass that point.
As a bonus, it’s a knowledge exchange for developers so they can learn from each other. There is an extreme case of doing so working in a pair programming approach. That means in front of one computer we put two developers so one of them is coding and the other one might be helping him or learning in the process. In our office, we do that once a week for an hour or two. It’s also an excellent idea as an exercise when hiring a new developer to see what is the quality of code and cooperation at once.
There are available plenty of developer tools helping keep the code in good shape.
Whatever your company is, it might be reasonable to perform a cross-review with a different company or use services of more experienced companies with a brief code audit. With small applications, it might take as short as a day to have a general idea if the code is acceptable or not. Later you can be advised to take a closer look at more crucial modules that raised some yellow/red flags or simply need more attention. A code audit is also a standard part of due diligence for example. So you might want to know what shape it is before is too late to fix it.
BAD CODE MAKES DEVELOPERS BAD
Developers want to learn new things, they want to work with new technologies, and they want to write a clean code of which they can be proud of at the end of the day.
Companies want to have happy employees and they especially want their employees which build their product to be happy. What’s even more important: there is currently a shortage of developers on the job market — so companies can’t afford to loose developers on a regular basis.
Last but not least: happy employees will work harder and write better code, which leads to even more happy employees.
Markus Oberlehner, quotation from his blogpost Code Quality Matters (for Developers)
HOW TO ESTIMATE SOFTWARE DEVELOPMENT
When creating software is hard to predict and estimate correctly, it puts a lot of pressure on the team which is demotivating and brings the quality even more down. It’s way better to finish a day being proud of your achievements and amount of work instead of living in constant stress. We only live once, so I recommend being happy and satisfied with what we are doing every day. That way you can trust more people you work with and without that might be impossible to scale up your business.
Also regarding scalability, with sloppy code adding more people to the team might be complicated as I mentioned before. With some processes and good practices, we should also reduce dependency on a sine developer to make our business more stable when everybody knows how the system works.
SUMMARY. BETTER CODE QUALITY MEANS HIGHER MAINTAINABILITY
At the end of the day better code quality means higher maintainability, you can add more features quickly without any risk of breaking something else, and that should leave more time for non-functional requirements like performance, scalability, security, reliability, etc.
Code quality, especially on the overall structural level, is an essential property of product software, which translates directly to financial losses or gains as the software is further maintained, modified and adjusted.
Shwe Yee, quotation from a presentation Importance of the quality of code
__________________
If you share my ideas and want to talk more about code quality or building a software development team, please leave a comment.
If you have a project to discuss, find out what I can do for you as a CTO.
