|
|
| | Ask YC: What do you do when a small project keeps getting larger? | |
13 points by chez17 on Aug 18, 2008 | hide | past | favorite | 20 comments
|
| | I am working on what started as a simple web scheduling program. Since its inception, the client has added different types of customers, different types of jobs, job tracking, schedule editing, etc... Basically, because this system has expanded beyond everything it was originally supposed to do, the code has gotten extremely messy and hard to maintain. This is all my fault of course, but I am not the super programmer many of you experts are here. I don't know what to do at this point, small changes are taking forever and some of the stuff they want done seem to be almost impossible now. Any help is extremely appreciated. Help me News.YC, you're my only hope. |
|
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
|
http://www.reddit.com/comments/6wn6j/maintenance_work_blows_...
The short answer is that it sounds like it's time for you to begin taking code quality seriously (better to have done so from the start, but we all fail at that most of the time). Whatever your language of choice is, find the resources that cover good coding practices, and begin making use of them. I work in Perl, and the definitive work is Perl Best Practices (and perlstyle covers a few bits and pieces)...there may not be such a definitive work in your preferred language, but I'm sure there's something. JavaScript has Crockford's new book which, based on reviews, is excellent--I trust that's true, as his lectures and his website are truly wonderful resources.
If you don't have tests, start writing them, and including test development costs in your estimates. If you don't have good code documentation, for yourself and future maintainers, start writing it, and including the cost of writing it in your estimates. It doesn't take that much longer to write a test while you're working on a piece of code--it's fresh in your mind, so you know exactly what you need to test (or vice versa...some folks write the tests and then write the code...I flip back and forth based on whether I know how the code is going to work yet or not).