This post is part of a collection of posts we’re publishing on the subjects of low internal software quality, refactoring and rewrite.
Not only physical matter deteriorates, software does too
It’s known that physical matter deteriorates. People accept that and have always dealt with it. What people don’t accept so easily is that software “deteriorates” too. Unlike physical matter, it doesn’t happen due to some physical or chemical phenomenon. It usually happens because of some business change or people change. Let me give you an example.
Imagine you’re leading the tech or product team of a startup; you’re the CTO. You already launched your product’s first version, and it was a success. Your business model was validated, and now you’re in a growth stage. That’s awesome! But it has its costs, and it brings a new set of challenges.
The first version of your product is working, but the codebase is not in the shape you’ll need from now on. Maybe your team’s velocity is not as good as it used be. Your team keeps complaining about the code quality. The CEO and the product director want new features, and your current projections will not meet the business needs.
It’s not uncommon that one of the main sources of all these problems is the poor quality of your product’s codebase. You may need a refactor1 or a rewrite.
When the codebase is not in good shape, everyone can get frustrated
If the internal quality of your product is not good, everyone becomes frustrated.
Your whole team, including developers, will get frustrated because they would like to ship features faster, but the current code quality and architecture are not helping.
The IT, product, and software departments suffer because they’re not able to meet the expectations of the other departments.
The customer also suffers because of frequent bugs, how long it takes for them to be resolved, and how long it takes new features to be launched.
You get the picture.
Identifying the symptoms
It’s the leader’s job (let’s say the CTO) to identify when a refactor or a rewrite is needed. In order to do that, he or she can look around for some symptoms, like the ones below:
- Everything is hard: Almost every feature or bug fix your team needs to do is hard. It was not always like that. You remember the good old days when your team was fast and everything ran smoothly.
- Slow velocity: Your team’s velocity decreased or is decreasing. When you were building the first version of your product, it was fast to develop a new feature, and your team used to build lots of them every iteration. Now it’s different.
- Slow test suite: Your test suite takes 10x, 20x, 30x more time to run than before.
- Bugs that don’t go away: Your team fixes a bug, then in a week or so it appears again. Every now and then your team is fixing a regression bug.
- Your team is demotivated: Your team keeps complaining that working in the project is not as productive as it was in the past. A single person can’t build one feature alone; there are too many moving parts.
- Knowledge silos: There are some parts of the software that only a single developer knows well enough to maintain. It’s difficult for the rest of the team to work with that specific code.
- New developer ramp-up time is taking too long: When new developers join the team, it takes too much time for them to be fully productive.
The reason you got into one of these situations is probably not a technical one. Maybe you needed to deliver too much, too fast while you were building the first version of your product. Maybe your team didn’t have the maturity and experience in the past they have now. Analyzing the root cause is important too, but you need to do something else. You need to solve your problem.
If you’re experiencing the symptoms above, you probably have a low internal software quality problem. Recognizing the symptoms is already a big step. The next step is to think of solutions. Some solutions you may take include refactoring or a rewrite process.
Refactor or rewrite?
There’s no definitive guide about when you should do a big refactor or a rewrite, because it depends a lot on your context. That said, there are some rules of thumb that you should consider when evaluating which solution to go with:
When to rewrite
- The technology you use is outdated, and it’s not maintained anymore.
- Your software is really slow, and changing the architecture is not enough or is not viable.
- The supply of software developers that know the technology you use is low and decreasing.
- There are new technologies that offer a significant advantage compared to what you’re using.
When to refactor
- The technology you use is still maintained and relevant.
- It’s viable to improve your application in an incremental fashion.
- The problem you’re solving is just technical and not a business one.
Choosing one of these options is not an easy decision, and once you go with one of them, there will be an entire new set of concerns you’ll encounter. Stay tuned, in our next blog posts we’ll talk about what to consider when doing a big refactor or a rewrite.
Now I would like to know about your experiences. Have you ever been in a similar situation? How did you identify that your problem was low internal software quality? Please share with us!
- I prefer the term “code refurbishment”, but people aren’t generally used to it. So I’ll use refactoring in this blog post for the sake of clarity. ↩
Every once in a while people ask us how we hire and interview software developers at Plataformatec. In this post, we share the key things we do when looking for and interviewing job candidates. We focused the post on actionable hints, from the basic tips up to some specific characteristics to the hiring process at Plataformatec. This is what has been working for us and we hope it is useful for you too.
Part One – define your Candidate Profile
Having a well defined candidate profile can save a lot of your time and is fairly simple to put together. A Candidate Profile makes easy for a non-technical person (an HR colleague for example) to help you find and identify potential candidates. These are some examples of what could be in your profile description:
- common “job titles” (specially if you are using LinkedIn Search to find candidates. ex.: software engineer, software craftsman, ruby developer, and so on)
- the most common skills
- their degrees and/or the universities the candidates went to
- their graduation year (if you’re looking for recent grads)
- companies they have worked for in the past
- also, it helps a lot to describe the things you are NOT looking for
But be careful not to make this list too long, it is supposed to be something simple to use. Our experience says that 4 to 5 characteristics are enough. If you want, you can download a Candidate Profile template at the end of this post.
Part Two – preparing your interview questions
The interview is a great opportunity for you to detect evidences (strong signals) that a candidate would be a great match with your team and that he/she is able to do the job… but you’ve got only 60min to do it. Wow, that’s hard! Where to start?
We’d suggest that you follow these steps:
1) Think about your company Culture and Values
- identify which behaviours…
- …reinforce your company culture
- …are definitely against your company culture
2) Think about the challenges of being in the role/job
- make a list of the key skills that the candidate must have to perform it’s activities
- describe a typical day of a person in this position
- think about the most difficult tasks this position requires
3) Focus on ‘how the candidate solves a problem’ rather than ‘the right answer’
- So, when building technical questions:
- avoid technical questions that are “right or wrong” type
- prefer questions where the candidate has to compare X and Y and present you good arguments (the pros and cons), ex.:
- “When would you recommend using X and when you would use Y?”
- we usually ask the candidates to criticize something that they really like, e.g.:
- “Tell me three things you don’t like about Ruby on Rails.”
4) Test your questions
- once you have finished writing your questions, ask them to yourself, to your colleagues or friends. Take notes about the type of answers you’re getting.
- remember, your job during the interview is to look for EVIDENCES, so if the answers you are getting are not providing you any evidences, then you need to refactor your questions.
Part Three – the interview
All right, you are about to finally meet with the candidate face to face. And if you’re using Skype or Google Hangouts please turn on your camera and ask the candidate to do the same. For the interview here are a few notes and reminders:
- Ice-breaking is important, and so is being nice. There’s high probability that the candidates will be nervous when the interview starts. So, the first step is to make them feel comfortable. This is good for them and for you too. If they feel comfortable, they will be able to be more authentic, show their real personalities. So, it is your job to turn the interview into a pleasant conversation. If the candidate is stressed during the whole interview you probably won’t be able to find any of your evidences.
- Pair-Interviewing. At Plataformatec, we like to interview candidates in pairs because we believe that two people can detect evidences better than just one. Usually one of us conduces most of the interview while the other pays close attention and takes notes. But try to avoid more than two interviewers as it could increase the stress level for the candidate and that wouldn’t help at all.
- The candidate should interview you too. Remember to spare a reasonable amount of time (preferably after you have asked your questions) to present your company to the candidate and to answer her/his questions. It is a respectful gesture. They have saved a few hours preparing and answering your questions and the least you can do is to return the gesture. And don’t forget that they are choosing where they want to work with you too. At Plataformatec, we feel that we had a good interview if the candidates leaves our office with more admiration and appraisal to our company’s culture, even if they are not moving on to the next steps of the hiring process.
- Look for for Cultural Fit evidences. As an interviewer, your job is to detect if there is a fit between the candidates and your company. Sometimes we hear from others interviewers comments like “We scared the sh#@ out of the candidate!”. That is a very corrosive attitude. Besides making candidates uncomfortable and being disrespectful, it is unlikely they will suggest your company to their colleagues.
Well, that’s it. I would love to hear your experiences in this topic and I wish you good luck in finding great teammates for your company!