5 ms·

Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?

ragebol 2y ago
Code is often written for an audience: yourself on a year, maybe a younger team member you have In mind. Knowing you won't be around to explain can help drive some decisions and write docs for the audience.
- j45 2y ago
  It’s can be less about code and more about supporting the evolution of the business process.
henryfjordan 2y ago
If you do go this freelancer route I would assume that there will be no code to maintain long-term. The freelancers should be building a prototype, not something intended to last decades. Either the freelancers work out and you begin hiring a permanent team (hopefully converting some freelancers to full-time) who will promptly rewrite / revise the prototype or you will go back to paying for software. Either way the prototype code should die or be taken over.
- kelnos 2y ago
  Is it common to build a prototype to throw away, and then actually throw it away and build the "real" thing? I've never seen that, ever, in 20+ years of software work. The prototype ends up being the long-term production version, for all its faults and weaknesses.
  - intelVISA 2y ago
    I don't think so sadly, even an iron willed CTO will have to risk a lot of c-level trust to justify rewriting something "that works" (at first glance).
- Silhouette 2y ago
  The artificial distinction between a prototype and a production system rarely survives reality in my experience. But that doesn't matter because the situation with long-term maintenance is not so different with freelancers doing the development to what you'd have to do with an in-house team. It's rare for anyone to be around to look after the code they write for you forever. Ironically you might have more chance of a good long-term relationship with some of your freelancers - having a few good clients who come back to you from time to time is an excellent strategy as a freelancer. So you always need the system and processes to be designed with future maintainability by other people in mind. Good developers will do that whether they're employed or freelance. Bad developers will mess it up either way too. Choose the people you work with wisely and try to make sure when you do bring in new people they have a good way to get up to speed so they can naturally take over as others leave. There's not much else you can really do.
- davedx 2y ago
  Not my experience: freelancers have often built the initial versions of a product that have then become the permanent version. Even products that start as prototypes, if not total trash, often end up evolving into real software projects. Why throw away software when you can iteratively improve and build on it? Unless the tech stack was wrong.
conductr 2y ago
Acknowledge and incent the exit plan from the beginning Incrementally, it might make sense to hire an independent audit on occasion. This might be hiring a senior to jump into the codebase for a week or two to see if they can make sense of it or see any glaring red flags. The important part is them knowing this will take place and them not knowing exactly when or by whom.
- Silhouette 2y ago
  The important part is them knowing this will take place and them not knowing exactly when or by whom. I recommend caution with this kind of approach. Even if you're bringing in a team of freelancers instead of hiring employees trust is still an essential foundation for the relationship. Clients who play silly games tend to get fired abruptly because it creates a toxic working relationship that isn't good for anyone involved. You should be able to have an open and ongoing conversation with your team of freelancers about the long-term intentions for the system they are building for you and they should transparently and proactively work towards your goals without being nannied. If that's not happening then you don't need some kind of surprise audit - you need to find different freelancers who are on the same wavelength as you.
maccard 2y ago
Consider where the company is right now - they're entirely reliant on a third party product that doesn't suit their needs. Every codebase is maintainable (to a certain extent), and the first step in getting a long term maintainable code base is... getting a code base. Freelancers don't inherently write better or worse code than FTE's. Some of the most braindead, unreadable, undefendable code I've seen has been written by FTE's while contractors are leaving them in their dust.
davedx 2y ago
The same way as with permanent employees. Agree on technical standards and documentation policies from the start. Build a good engineering culture.
ssousa666 2y ago
There is a whole class of hybrid incubator/vc firms in the US ("VC Studios") that have used this model and achieved success. Sometimes the model is inverted, in that the VC studio will build the MVP with their small, in-house engineering team before staffing the "real" company and eventually handing the codebase off to founding engineering team.

ragebol 2y ago

Code is often written for an audience: yourself on a year, maybe a younger team member you have In mind. Knowing you won't be around to explain can help drive some decisions and write docs for the audience.

j45 2y ago
It’s can be less about code and more about supporting the evolution of the business process.

henryfjordan 2y ago

If you do go this freelancer route I would assume that there will be no code to maintain long-term. The freelancers should be building a prototype, not something intended to last decades. Either the freelancers work out and you begin hiring a permanent team (hopefully converting some freelancers to full-time) who will promptly rewrite / revise the prototype or you will go back to paying for software. Either way the prototype code should die or be taken over.

kelnos 2y ago
Is it common to build a prototype to throw away, and then actually throw it away and build the "real" thing? I've never seen that, ever, in 20+ years of software work. The prototype ends up being the long-term production version, for all its faults and weaknesses.
- intelVISA 2y ago
  I don't think so sadly, even an iron willed CTO will have to risk a lot of c-level trust to justify rewriting something "that works" (at first glance).
Silhouette 2y ago
The artificial distinction between a prototype and a production system rarely survives reality in my experience. But that doesn't matter because the situation with long-term maintenance is not so different with freelancers doing the development to what you'd have to do with an in-house team. It's rare for anyone to be around to look after the code they write for you forever. Ironically you might have more chance of a good long-term relationship with some of your freelancers - having a few good clients who come back to you from time to time is an excellent strategy as a freelancer. So you always need the system and processes to be designed with future maintainability by other people in mind. Good developers will do that whether they're employed or freelance. Bad developers will mess it up either way too. Choose the people you work with wisely and try to make sure when you do bring in new people they have a good way to get up to speed so they can naturally take over as others leave. There's not much else you can really do.
davedx 2y ago
Not my experience: freelancers have often built the initial versions of a product that have then become the permanent version. Even products that start as prototypes, if not total trash, often end up evolving into real software projects. Why throw away software when you can iteratively improve and build on it? Unless the tech stack was wrong.

conductr 2y ago

Acknowledge and incent the exit plan from the beginning Incrementally, it might make sense to hire an independent audit on occasion. This might be hiring a senior to jump into the codebase for a week or two to see if they can make sense of it or see any glaring red flags. The important part is them knowing this will take place and them not knowing exactly when or by whom.

Silhouette 2y ago
The important part is them knowing this will take place and them not knowing exactly when or by whom. I recommend caution with this kind of approach. Even if you're bringing in a team of freelancers instead of hiring employees trust is still an essential foundation for the relationship. Clients who play silly games tend to get fired abruptly because it creates a toxic working relationship that isn't good for anyone involved. You should be able to have an open and ongoing conversation with your team of freelancers about the long-term intentions for the system they are building for you and they should transparently and proactively work towards your goals without being nannied. If that's not happening then you don't need some kind of surprise audit - you need to find different freelancers who are on the same wavelength as you.

maccard 2y ago

Consider where the company is right now - they're entirely reliant on a third party product that doesn't suit their needs. Every codebase is maintainable (to a certain extent), and the first step in getting a long term maintainable code base is... getting a code base. Freelancers don't inherently write better or worse code than FTE's. Some of the most braindead, unreadable, undefendable code I've seen has been written by FTE's while contractors are leaving them in their dust.

davedx 2y ago

The same way as with permanent employees. Agree on technical standards and documentation policies from the start. Build a good engineering culture.

ssousa666 2y ago

There is a whole class of hybrid incubator/vc firms in the US ("VC Studios") that have used this model and achieved success. Sometimes the model is inverted, in that the VC studio will build the MVP with their small, in-house engineering team before staffing the "real" company and eventually handing the codebase off to founding engineering team.