Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sounds familiar. I've worked on a similar code base, old code written during the startup years that is messy and have lots of subtle bugs and is a complete dependency mess.

When I joined I was told by one of the (post-startup) devs he had a rule: whenever he had to fix a bug or add a feature to a piece of code, he'd try to clean up the method or class he had to work on to implement the change. Bigger changes then allowed for bigger cleanups.

We also had the challenge of testing. So we decided to accept the situation, that we have a fragile project and that our changes will lead to bugs, and instead wrote an infrastructure that made it easy for our users to launch older versions of our application. For the most part this meant blocking bugs were not such a PITA for users, if we broke version 42 they could easily launch version 41 and use that until version 43 with a fix came along.

As for saying the lead guy did a bad job, I think you're making the mistake of looking at the code as the most important thing. It really isn't. The application and its functionality is the most important thing. Functionality is what makes the application useful to users. An application with no users is useless.



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

Search: