4 ms·

I guess a line needs to be drawn. Have you been paid for a general set of deliverables and only now are the specific requirements coming out? If you haven't b

by t0pj 18y ago

I guess a line needs to be drawn. Have you been paid for a general set of deliverables and only now are the specific requirements coming out? If you haven't been paid yet, will they not pay until they're "satisfied"? Is the site even online yet? That line being drawn is between the original contract and the hourly rate which you'll charge for further enhancements. (I don't know if you're doing this on contract, as a favor for a small set amount, or for free.) If maintaining the codebase is becoming unbearable, you probably can't throw away the whole thing and start over. Maybe you could start the reorganizing effort with the enhancements and work in changes to your yucky, "legacy" code as time permits. Warning: Any changes you make to simply allow easier maintenance of your code in the future can possibly not be seen by the customer as requirements or time that they'll pay for.

chez17 18y ago
The site is online and live. They use it daily. The changes have been made over a couple of years, so I have been paid for the work that has been completed, which is everything except this last round of changes.
- tstegart 18y ago
  So you just never expected it to get this complicated and you didn't plan for it? Are you looking for help on how to fix it, or how to approach your client and let them know that its become unworkable?
  - chez17 18y ago
    More about the philosophy of quality code. I am going to do the work, that's not the issue, but I was asking for advice on how to proceed with the coding. I'm sure this has happened to people before and will happen again. I was also thinking that a thread on something like this would be very useful to many people besides myself.
    - gruseom 18y ago
      There are all kinds of things we could discuss about this. It might be fun if you mentioned some specific examples and people could offer suggestions. In general, though, I'd suggest you begin paying a lot more attention to what, and when, you're duplicating in your code. There are lots of ways for duplicate code or data to creep into a system. Developing awareness of what they are, and discipline to do something about it, is probably your best bet to start with. You'd be surprised at how far that alone will get you. Edit: I'll add something about my own practice. When making changes to a system, I nearly always bundle the visible changes together with invisible changes to clean up problems with that portion of the code (if I see any). I don't ask for permission to do this and I don't do big cleanup projects as standalone endeavors. Rather, I amortize the cost of design improvement as evenly as possible over the lifetime of the project. Think of it as paying off your credit card bill each month, rather than waiting for the collection agency to come after you. In other words, there's basically never a day when I'm not correcting or improving code in addition to adding it. If I were you, I'd start doing this now, and I'd start out with low-hanging fruit (obvious, easy improvements) rather than attempting anything too grand. You may experience a slowdown in your progress if you switch to working this way - but your throughput will be greater in the long run. Besides, it sounds like you've hit the point, with this codebase, where your changes are taking longer no matter what you do.
    - t0pj 18y ago
      If you haven't yet, then please have someone else take a look at your code. I'm thinking they'll be able to give you some pointers. I can only guess in what a mess your codebase must be; spaghetti code with sparse, little "helper" functions, perhaps? Is there duplicate code? 1) Opening and querying databases. 2) Presentation/UI. 3) Dynamic menuing systems; it's all static behind the scenes. Can you give us more of an idea of how it's so difficult to work within your project?
    - alex_c 18y ago
      More about the philosophy of quality code. I can offer the following vague advice: - When writing new code, do the best you can with the information you have. Resist taking shortcuts (copy & paste instead of a minor refactoring, etc.) - Refactor old code as you go along, but do it cautiously, and only when it's worth it (very clear performance or maintainability advantages, for example).

by t0pj 18y ago

chez17 18y ago

The site is online and live. They use it daily. The changes have been made over a couple of years, so I have been paid for the work that has been completed, which is everything except this last round of changes.

tstegart 18y ago
So you just never expected it to get this complicated and you didn't plan for it? Are you looking for help on how to fix it, or how to approach your client and let them know that its become unworkable?
- chez17 18y ago
  More about the philosophy of quality code. I am going to do the work, that's not the issue, but I was asking for advice on how to proceed with the coding. I'm sure this has happened to people before and will happen again. I was also thinking that a thread on something like this would be very useful to many people besides myself.
  - gruseom 18y ago
    There are all kinds of things we could discuss about this. It might be fun if you mentioned some specific examples and people could offer suggestions. In general, though, I'd suggest you begin paying a lot more attention to what, and when, you're duplicating in your code. There are lots of ways for duplicate code or data to creep into a system. Developing awareness of what they are, and discipline to do something about it, is probably your best bet to start with. You'd be surprised at how far that alone will get you. Edit: I'll add something about my own practice. When making changes to a system, I nearly always bundle the visible changes together with invisible changes to clean up problems with that portion of the code (if I see any). I don't ask for permission to do this and I don't do big cleanup projects as standalone endeavors. Rather, I amortize the cost of design improvement as evenly as possible over the lifetime of the project. Think of it as paying off your credit card bill each month, rather than waiting for the collection agency to come after you. In other words, there's basically never a day when I'm not correcting or improving code in addition to adding it. If I were you, I'd start doing this now, and I'd start out with low-hanging fruit (obvious, easy improvements) rather than attempting anything too grand. You may experience a slowdown in your progress if you switch to working this way - but your throughput will be greater in the long run. Besides, it sounds like you've hit the point, with this codebase, where your changes are taking longer no matter what you do.
  - t0pj 18y ago
    If you haven't yet, then please have someone else take a look at your code. I'm thinking they'll be able to give you some pointers. I can only guess in what a mess your codebase must be; spaghetti code with sparse, little "helper" functions, perhaps? Is there duplicate code? 1) Opening and querying databases. 2) Presentation/UI. 3) Dynamic menuing systems; it's all static behind the scenes. Can you give us more of an idea of how it's so difficult to work within your project?
  - alex_c 18y ago
    More about the philosophy of quality code. I can offer the following vague advice: - When writing new code, do the best you can with the information you have. Resist taking shortcuts (copy & paste instead of a minor refactoring, etc.) - Refactor old code as you go along, but do it cautiously, and only when it's worth it (very clear performance or maintainability advantages, for example).