cost to refactor on medium sized freelance projects

Question

I've been working on a freelance project for about a year. I build a new feature every month as per client request. Things went smoothly the first several months. I built each new feature as a separate module. But today, there are too many different modules for me to manage and new developers on the project are confused by the complexity of the system. If I had enough time and money, I would re-write many of old modules and consolidate them under one super module to improve system maintenance.

When I compare working for a large company to working as a freelancer, it's easier to convince an experienced-supervisor of a big company than a freelance client on the costs and merits of refactoring a system. Supervisors understand software entropy while freelance clients generally don't. Freelance clients are prone to asking, "But I already paid you X dollars to build the payment system. Why do I need to pay you Y dollars to rewrite it? Is it because you didn't do a good job? Maybe I should hire someone else."

So I suppose my problems are as follow:

1) I find it difficult to convince my clients of the value of my work, so I'm often underpaid. Additionally, it makes it extremely difficult to convince clients to pay me to refactor old code.

2) I receive requests for new modules every month and build accordingly. Had a I known the "exact" details of future modules for the next several months, perhaps I'd be able to build a more generic framework for the long haul, instead of just tacking on one module after another.

3) Maybe these difficulties are the nature of freelance development and I should just accept it?

4) A client does not see no tangible results of refactoring. It's difficult to sell them on something they can't see.

I know I'm about to ask a very broad question, but with regards to all the issues I've stated above, what can I do to make freelance life easier?

Answer 1

I generally think refactoring is a natural thing in the lifespan of a codebase. It's not a matter of how good you are, its just something that will usually need to happen as a system expands. You should try to explain to your client that making the code easier to understand and extend, for both yourself and new developers will make implementing new features easier/faster and will help improve the overall quality of the system and can avoid costly bugs/maintenance.

In other words, investing in some refactoring will actually save them money in the long run.

Answer 2

I am in the same situation with a long-running project for a client. We've been building and building new features into a portal for the past four years, and while to the outside everything looks fine (whew! Well, there is some duct tape in a few spots), the inside looks like a mess in need of refactoring.

The main lesson I draw from this is, in the client's everyday business, it's impossible to plan ahead for every eventuality, so insisting on a pre-planned specification often just won't work. New needs and readjustments arise in everyday work, that's the way business goes. The relationship with the client needs to reflect that as well in that there is enough trust about what is being billed that not every little detail needs to be negotiated up front.

Now in my case, I am lucky enough to have a client I can talk to, and a good enough relationship that I find myself ready to put in some considerable refactoring time of my own too (I can take a lot back into a general code base I am allowed to reuse), so things will work out - it's a learning process for me as well, and one of the first year-long clients with one constantly growing project. For the future, what I learned from it is:

• Really refactor early, refactor often. Do it. It's damn hard to do, especially if nobody's up your ass about it, but it's really important.

• Take refactoring into all your calculations. When giving the client an estimate, pad it by 10-20% that you are not going to use just yet, but later, when refactoring becomes necessary.

• Learn from mistakes, and plan future projects so they can grow without the system breaking.

• Do not expect your client to understand any of this. They usually can't, and that's perfectly all right - it's not their job. Just quietly include it into your calculations as maintenance or whatever. If you are in the situation that you have to justify refactoring investments and the client can't see what for - if it's somebody you want to keep, consider putting in some time of your own, refactor, and calculate more realistically next time.

Answer 3

Presumably the re-factoring you're asking about is a fairly large effort; not something you'd just do quickly and fold into the regular bill.

In addition to others' answers, there are a few other things I've not see mentioned yet that you could do:

• Depending on how detailed your invoices are, you could refactor the code and bill the client for the time without mentioning that you refactored. Of course, this may prove difficult if it is a major effort.
• Refactor the code but absorb the costs yourself. Figure it's overhead, or worth it to save your sanity.
• Explain that ideally the code needs refactored to reduce bugs and the time (and cost) of maintaining it, but don't do the refactoring until the client agrees to pay for it.

One other suggestion that may seem obvious: I don't expect that most non-programming (or at least non-IT) client would understand the term refactor, so you may want to call it a re-write or something similar.

Good Luck!