I'm a freelancer transitioned into a very-small agency.
The projects we take on are typically startup products. This enables us to work on leading edge tech. However as my reputation grew - people/companies have started seeking me for some of their old projects. I do take on maintenance for the products we developed.
However the other maintenance projects that I get asked for are because "that vendor was too-slow/did-not-deliver-to-expectations/not-responsive".
When I look into the code for these older projects, most of the times that is spaghetti code and lots of it. And the customer/lead wants us to maintain and add features to that instead of allowing us to rewrite full or part of it. Obviously, the cost of rewrite is higher, but in reality the cost of keeping the spaghetti is even higher over a longer term. I make sure they atleast hear the pros and cons - but then I don't push too hard on a rewrite.
First, taking such spaghetti projects is profitable. Adding to spaghetti is not too hard. The customers are asking for it - hence its not unethical. These customers have already proven they don't care about the internals. And then spaghetti also has patterns within - making it easier to understand as we spend more time with it.
Second, these projects are extremely frustrating. We know what's wrong, but voluntarily decided to live with the wrongdoings of other developer(s). Of course we get paid well.
BUT I am worried if I should continue taking on similar projects. I code too and I have experienced friction with other good devs in the team because of such projects. I kind-of understand why thats happening. And planning to add a few average developers (as a different team) to take on such "spaghetti projects" - hoping that would work. But not sure if thats a good idea.
I guess many freelancers/agencies faced such problems. How was your experience and What did you do?
1. Keep taking the projects on as they come and deal with it. 2. Make working on projects like this your niche and charge extra. 3. Stop taking on these projects and seek out only greenfield projects.
We, too, take on projects like this a time or two per year and can usually up-sell them on some refactoring by explaining to them the longer-term cost in maintenance. If the existing works are sufficiently FUBAR, I generally won't take the project on unless they agree to some restructuring of the project.
Our team's current mix is generally around 60% brand new projects, 20% maintaining code written by my team, and 20% maintaining others' code.