When is "enough" enough?
jjames
Posts: 2,908
I just got back from doing some fixes on a job I did about a year and a half ago. I'm not proud of the job, but it is our biggest to date. Bugs keep popping up, and it's not very solid. But it works decently. I did the job with only a year's true work experience and to say I was still a rookie would be accurate. The job consists of 18 touch panels in a residential setting (4 x 8400, 2 x CV12, 7 x CV7, and 5 x four inch panels.) There are several panels that are literally no more than 20 feet from eachother, so there is a lot of tracking that is needed.
To do this type of tracking, and management after a year's experience was difficult and I'm not entirely sure I actually grasped it at the time. I did however have some outside help which eased the pain. I have had to go back to the job numerous times and even still after a year and a half, I am still going back to fix things. The client is perhaps the best I've ever worked with. He knows what he wants, and has been very greatful and patient with my work. However, I think that even the most patient person loses their patience and I'm not really sure how much more my boss, the client or I can take.
At what point do you say enough is enough and re-write the entire thing? I look back at the code and it makes me cringe, and I dread having to work on it. Many of the things we have worked on lately is a direct result of doing this particular job. There is so much more we can offer him now, but the main problems of having to rewrite it is: 1) the time it would take to check out the system, and 2) the time it would take to rewrite it. Obviously, none of this time would be billable, which most of the time I spend over there fixing stupid problems is not billed. Thirdly, we're so busy that I don't have a lot of time to do it.
So - my question is when do you bite the bullet and rewrite it? And also how do you convince your boss to allow you to rewrite it? Sure, I could rewrite on my own time. But checking it out on my own time would be questionable. So - ideas? Thoughts? Anyone?
To do this type of tracking, and management after a year's experience was difficult and I'm not entirely sure I actually grasped it at the time. I did however have some outside help which eased the pain. I have had to go back to the job numerous times and even still after a year and a half, I am still going back to fix things. The client is perhaps the best I've ever worked with. He knows what he wants, and has been very greatful and patient with my work. However, I think that even the most patient person loses their patience and I'm not really sure how much more my boss, the client or I can take.
At what point do you say enough is enough and re-write the entire thing? I look back at the code and it makes me cringe, and I dread having to work on it. Many of the things we have worked on lately is a direct result of doing this particular job. There is so much more we can offer him now, but the main problems of having to rewrite it is: 1) the time it would take to check out the system, and 2) the time it would take to rewrite it. Obviously, none of this time would be billable, which most of the time I spend over there fixing stupid problems is not billed. Thirdly, we're so busy that I don't have a lot of time to do it.
So - my question is when do you bite the bullet and rewrite it? And also how do you convince your boss to allow you to rewrite it? Sure, I could rewrite on my own time. But checking it out on my own time would be questionable. So - ideas? Thoughts? Anyone?
0
Comments
I would say that a re-write is in order if you find the system shooting itself in the foot due to overly complex routines or you lack the ability to add functionality without substantial re-coding. Some of my first few programs make me want to either shrivel up or vomit depending on the mood of the particular day that I think about them. I have re-wrote most of those early dogs when time allowed and incorporated all I have learned since.
You mentioned a residential project with lots of panels. I'm assuming that it's a one-master system. I may be flamed, but I find panel tracking, even in a system with this may panels, to be overrated. The vast majority of master-to-panel events can be sent to a device array of all of the panels without major complication even if some panels are off-line. Just be sure that online events update individual panels with anything that may have changed while the panels were napping.
If you got the time I say do it over, it will only help your programming skills and it seems to always come back to help you.
You did the best you could at the time and that's the best that any of us can do. You don't owe them a thing but that's not to say if you have new and improved modules that were develope afterwards during other projects that could easily be inserted into that program when onsite for maintenance or remotely then by all means spend a little extra time on your dime or the boss's to make some improvements. It's good for business to have the best system available up and running for them to show off to their friends. Just don't go out of your way and take quality away from the current projects.
Suggest a tune up with added features at a compromised fee so every one makes out. You and your employer don't lose money and the customer doesn't really pay twice.
Excellent suggestion. I have several systems that I have added equipment to over time. I take the opportunity to touch-up any old programming while adding the new stuff.
As far as not having the time . . . I do have my own time. To be able to sit down adn re-write the code would be a little painful, but not as painful as it is each time I go over there and see all the bugs, then trying to fix them.
I do take pride in my systems when I can. There have been a few jobs where things went off without a hitch and I have not had to make one revision yet - that makes me happy (as I'm sure it does my boss as well.) This job . . . ugh. I just wish I knew then what I know now. (Some might say that I did, but that I was too bull-headed at the time.
I say go for it. I've done it myself. If your family / job circumstances allow, indulge your pride in your work and go fix it, take all weekend. BUT: coding is only half the job; or a third, or a quarter, depending on the circumstances. What matters most is the client's willingness to cooperate, and to test the result and to report the test results accurately. You will be judged by how many hassles you cause. That's what matters.
Now in regard to your own time, I'm sure you already spend a good majority of that on current projects as I think most of us do. So, it's a hard. Ideally, go for it but reality is, can you!
As a pro for rewriting, you should be able to fly through the systems testing if 1) all the devices worked in the old system and 2) you already know how you want to wire the guts of the code (TP tracking, etc.) and have used that method in other systems. Sure, there will be the usual typos and head-desking, but you've got a head start if you're already talking to all your devices successfully.
Jeremy
I'm a semi-retired music producer/audio engineer and musicians suffer from the same thing. They hate what they did in the past. As a producer, I've always tried to get the artists out of the mindset that what they are doing is a 'grand work of art' that will be carved in stone. I've tried to steer them in the direction of thinking that what we're recording now is mearly a snapshot of what's going on now.
If you transfer this idea to programming, you have the total advantage that a program on the same set of gear can be altered without loosing what it fundamentally is. You can just improve how it goes about doing something. Or you can, as you suggest, improve the user's experience by adding functionality. This does amazing things for the long-term relationship of the customer and doesn't really cost you too much.
I too have older projects that I wonder what was in my tea when I typed. I made my boss understand that the way I operate in general is to slowly improve chunks of code and after testing them on the newer systems, propegate them out to the older systems. I make arrangements to make a 'courtesy' call to the residence and do the upload. I can upload remotely, but I always want to be there to test and make sure it works.
The clients don't seem to mind and appreciate the attention. Quite often, they'll start chatting and asking for different things and it ends up being a sales call for the designers.
I'd say try to work it into your routine. We always have some kind of down time when we're waiting 5-10 minutes for something.
As I said, we all have those skeletons in our closet. You were just brave enough to voice it.
The music producer in me says, "embrace this feeling and grow from it." I'm sure in 2 years we'll look back at the 'improved' code we're writing now and roll our eyes and declare it 'garbage.' Meanwhile the Earth just keeps turning and turning....
To me it was easier to rewrite it and update the flow and stuff then to try and patch work it. Plus I felt better about it also. I want the customer to be happy and a self pride in knowing that they are getting what they paid for. I did the best that I could at the time, but now that I can do better, lets fix it.
Do it if it'll stop you shuddering when you see the client's number on your call display. This job is stressful enough from the things you CAN'T control.
Jeff
Vining's comment cracked me up - I have so many "lost weekends" (some embarassing and some very cool) -- for me to then think some productive clean up is too precious...(especially for a client that put you on the map) -- ROFL.
Bill
If you have landed other jobs because of the work you initially did, then you can justify the time and expense as advertising. There is no better advertising than a happy customer!! Customers that can afford AMX have friends that can afford AMX. While you are at it, sell the customer some newer interfaces. Let him know you want to take care of him and at the same time do some timely upgrades.