Hacker News new | past | comments | ask | show | jobs | submit login

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?



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.


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.


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?


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).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: