Perhaps many people faced with a situation when potential client is looking for someone to help him in refining existing web site. There are certain pros and cons and in this article I would like to share my personal experience and thoughts on this point.
First of all i’d like to gather critical things both parties should understand:
in the beginning immediate releases are out of the question;
it should be a dedicated person whom you could ask questions as they arise. Trust me, they will occur frequently You can not pass the code and respond to questions once per day. This will take ages
initially it’s better to confirm all your changes as this potentially could affect whole system
it is almost impossible to give an exact budget and timeline; without knowing whole project your figures will be either understated or overstated. Of course the best way to learn the project is to start doing something concrete, but if you claim for final price and timeline in the first day – at least it is not professional
most often maintenance costs more (higher hourly rate) than in case of its development from scratch
What should I look at:
take metrics (benchmarks) from the current code; Of course it doesn’t mean that problems will be with every single customer and not every customers can even know the real metrics of his code, but potentially you could work on completely unrelated code and the client would say that because of your recent changes the dashboard starts working very slow.
make code review summary; you need to evaluate the code: what is good and what is bad and let the client know in advance
check if the project have unit tests. Otherwise, even very simple change could kill the old logic
last but not least is to understand the reason why the previous developer had not completed the work he started
Software maintenance is pretty complex, challenging stuff.
In most cases, the people who do maintenance tend to be those who are new on the job or not very good at development (maintenance is their chance). There’s a reason for that. Most people would rather do original development; maintenance is too constraining to the creative fellows. And so by default, the least capable and the least in demand are the ones who most often do the maintenance.
We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.
This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.
Although there are certain positive and very important pros:
- not all code is bad by default. This potentially can be very good additional experience for you as a developer
- doing good job at this project you can earn trust from the client and he may give you all other projects (old and new)
- no need to write banal things (authorization, basic layout etc.) you have to do in a project from ground
- this is great opportunity to give client a taste of your quality quickly
- it is a certain “challenge” for you, as a programmer
- such projects often already have real users, which means your code will not be in a trash. I think everybody wants their code to be useful