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

That only works if the new pieces correspond to old pieces. If there's no good structure to build on, the units to be replaced will constrain the architecture of the new ship.

At some point you end up trying to change a pumpkin boat into an aircraft carrier, and there's no obvious way you can do that one piece at a time.



> If there's no good structure to build on, the units to be replaced will constrain the architecture of the new ship.

Which is why you do it in stages: add scaffolding until local rewrites are possible, then rewrite the business logic, then tear the scaffolding down.


That's a good analogy actually. Scaffolding is a kind of temporary test structure that you can use to maintain function while you figure out something better.


Maybe there are some underlying architectural problems that need to be addressed, but it would be impossible make those changes from the current situation. It sounds like it is impossible to even know what code is live vs sitting on the server. How do you even know you have a firm grasp on the current architecture when it is unclear what code is even running the product?

A lot of low hanging fruit to be addressed that will likely lead to meaningful improvements. Once the code is in better shape and some unfortunate legacy pattern is identified, than it can be considered time to re-tool the architecture.


Agreed. The first thing to do is figure out WTF is going on. This is perhaps the hardest kind of thing to do as a developer.




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

Search: