4 ms·

I have actually worked on a code base like you're describing, on a contract basis, for a client. I loathe maintenance programming, so the relationship didn't la

I have actually worked on a code base like you're describing, on a contract basis, for a client. I loathe maintenance programming, so the relationship didn't last very long -- just a few months. So: 1. Make sure you have a rock-solid contract in place with the client that will ensure that you get paid, get paid well, and get paid often. Receiving a check in the mail makes it easier to look at the code. If your payment terms are anything like, "payment-upon-completion of ...", or, "paid net 30 after invoice", or anything like that, you simply won't want to work on the code. 2. If "soul-crushing", "depressing", or "makes me want to hang myself" are phrases you'd use to describe the code or your state of mind when looking at it, then go into this project knowing that you're not going to last long. There are people who genuinely enjoy working on stuff like this. You aren't one of them. 3. Everybody that says "rewrite" is dreaming. It is impossible to rewrite something that large without breaking something and spending too much money. Re-factoring a function is doable. Re-factoring a thousand-line file is doable. Re-factoring part of a database is doable. Re-factoring all of it all at once is starry-eyed fiction. Not gonna happen. 4. But, if taking ownership of this code base is something you want to do, then add re-factoring time in to your agreement with the client -- something like, "20% time spent replacing bad code" -- and focus on the tiniest little ugly thing you can find, and re-factor that. Start on it, don't stop until it's done. Keep it in small bite-sized chunks. 5. Make sure you're getting paid for time spent just getting familiar with the code base. If you work with it long enough you'll actually get pretty familiar with most of it, but you want to do that on their dime, not yours. 6. Get help. They surely realize by now that they've got a mess on their hands. Talk with them about whether or not you can bring on additional help. If they flat-out refuse, run. (That is what killed my work with my client; I wanted to move into a position where I managed a junior programmer and focused on code rewrites and higher-level stuff; they refused, I quit. They wanted an employee, not a contractor.) 7. Version control and a sane bug tracking system (Mantis isn't horrible) are must-haves. If they don't have these, again, make sure they pay for it. Dealing with a code base like this one is as much about state-of-mind as anything else. Either you can handle it or you can't. No amount of advice here will make it more palatable to you if you're not the sort of person that's OK with inheriting a disaster. Also, even if you've got some kind of agreement in place with the client already, it sounds like you've just now gotten your first look at the code. This, in my opinion, makes it totally OK to go back to the client and re-negotiate. You can open it with, "I'd like to work with you, but now that I've seen the project that you want me to work on, I can understand why this has been a problem for you, and I need to make sure that we can come to an agreement that will work for both of us so that I can fix this for you." (Or something.)

robomartin 14y ago
" Everybody that says "rewrite" is dreaming. It is impossible to rewrite something that large without breaking something and spending too much money. Re-factoring a function is doable. Re-factoring a thousand-line file is doable. Re-factoring part of a database is doable. Re-factoring all of it all at once is starry-eyed fiction. Not gonna happen." I don't think so. Yes, the opportunities to do something like this are rare. It is up to the project lead and the client to decide whether or not this makes sense. Also, keep in mind that a "complete re-write" doesn't necessarily literally mean that every line of code must be re-written. There's often tons that can be salvaged. If the code base is an absolute disaster I would not touch it without the understanding that the project might entail massive re-writing of portions of the codes base as well as significant structural modifications. Maybe I'm lucky in that I've never really had to go look for work. I would flat-out reject a project like this without massive client buy-in. If it is mission critical for the client and they can afford it there is no reason not to step back, truly evaluate the situation and consider a significant redo of the app. For any non-trivial enterprise having a solid and maintainable code base is nearly priceless. Is it worth investing a year and the corresponding financial commitment to fix the problem once and for all? For the right business, yes! The alternative is to live with a patch-work of code for the next ten years of more. Because I move across disciplines I have seen this sort of thing in many areas outside of just software code-bases. I have, as an example, seen data processing facilities with millions of dollars in equipment designed in patch-work fashion that bleed money on a daily basis. In one such cases I proposed a complete redoing of the facility (in staged fashion in order to not affect business). It was very costly, but the owners where under such pain due to the constant bleed that they saw the intelligence in investing a lot of money to lay down an infrastructure that would withstand the test of time, not to mention stopping the bleeding. Similarly, I have seen this in faulty processes. Process optimization or redesign can be critical to a business. The most well known example of this is the automobile industry. Car manufactures like Mercedes were devoting fully 20% of their factory floor space to repairs. Cars would come off the assembly line with defects that would have to be repaired after the fact. This consumed a tremendous amount of time, money and resources. In sharp contrast to this, companies like Toyota where using an approach that aimed to have cars come off the line with zero defects. They'd stop the assembly line when an defect was detected. At first they nearly couldn't make cars. The philosophy was to ensure that detected defects never re-occurred. With time cars started to come off the line with few, if any, defects. Most car manufacturer have now adopted these ideas. The point is that sometimes a "complete rewrite" is warranted and even necessary. On cannot categorically state that the idea of a re-write is "fiction" any more than stating that it is an absolute necessity while being completely detached from the players and their circumstances. I suggest that it is for the client and consultant to evaluate and decide. On a personal note. I don't enjoy working with crap. I enjoy my craft. Whether it is writing code, designing electronics or mechanical. I enjoy doing good work and working in quality projects. Life is too short to work on shit projects. You learn nothing and nobody is happy.

robomartin 14y ago

" Everybody that says "rewrite" is dreaming. It is impossible to rewrite something that large without breaking something and spending too much money. Re-factoring a function is doable. Re-factoring a thousand-line file is doable. Re-factoring part of a database is doable. Re-factoring all of it all at once is starry-eyed fiction. Not gonna happen." I don't think so. Yes, the opportunities to do something like this are rare. It is up to the project lead and the client to decide whether or not this makes sense. Also, keep in mind that a "complete re-write" doesn't necessarily literally mean that every line of code must be re-written. There's often tons that can be salvaged. If the code base is an absolute disaster I would not touch it without the understanding that the project might entail massive re-writing of portions of the codes base as well as significant structural modifications. Maybe I'm lucky in that I've never really had to go look for work. I would flat-out reject a project like this without massive client buy-in. If it is mission critical for the client and they can afford it there is no reason not to step back, truly evaluate the situation and consider a significant redo of the app. For any non-trivial enterprise having a solid and maintainable code base is nearly priceless. Is it worth investing a year and the corresponding financial commitment to fix the problem once and for all? For the right business, yes! The alternative is to live with a patch-work of code for the next ten years of more. Because I move across disciplines I have seen this sort of thing in many areas outside of just software code-bases. I have, as an example, seen data processing facilities with millions of dollars in equipment designed in patch-work fashion that bleed money on a daily basis. In one such cases I proposed a complete redoing of the facility (in staged fashion in order to not affect business). It was very costly, but the owners where under such pain due to the constant bleed that they saw the intelligence in investing a lot of money to lay down an infrastructure that would withstand the test of time, not to mention stopping the bleeding. Similarly, I have seen this in faulty processes. Process optimization or redesign can be critical to a business. The most well known example of this is the automobile industry. Car manufactures like Mercedes were devoting fully 20% of their factory floor space to repairs. Cars would come off the assembly line with defects that would have to be repaired after the fact. This consumed a tremendous amount of time, money and resources. In sharp contrast to this, companies like Toyota where using an approach that aimed to have cars come off the line with zero defects. They'd stop the assembly line when an defect was detected. At first they nearly couldn't make cars. The philosophy was to ensure that detected defects never re-occurred. With time cars started to come off the line with few, if any, defects. Most car manufacturer have now adopted these ideas. The point is that sometimes a "complete rewrite" is warranted and even necessary. On cannot categorically state that the idea of a re-write is "fiction" any more than stating that it is an absolute necessity while being completely detached from the players and their circumstances. I suggest that it is for the client and consultant to evaluate and decide. On a personal note. I don't enjoy working with crap. I enjoy my craft. Whether it is writing code, designing electronics or mechanical. I enjoy doing good work and working in quality projects. Life is too short to work on shit projects. You learn nothing and nobody is happy.