@mjgardner
> There’s nothing more permanent than a temporary fix that works
... until something breaks in a way that can't be fixed without refactoring ; ) But that's not an argument against temporary fixes. Even the most thoughtful design can't anticipate every future change in dependencies, deployment scale etc.
@mjgardner from the people who told you to write prototype in a language that your company doesn’t deliver or run in production comes the next variant on this idea: Prototype it in Rust! At least this way, it’s in a safer language and some of the demons will be kept away.
@mctwist My vice is #refactoring other team members’ code when reviewing their merge requests, especially when they’re making a small fix to some grotty #LegacyCode. (Spoiler: it’s all grotty legacy code)
@mjgardner I wrote a 200 line Proof of Concept, that by the time I left last job had turned into a ~14K LOC behemoth that should never have been put into production for all these reasons.
@godeater “...[T]here are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
If it's a proof of concept that proves the concept, then the concept has been proven and we can let it prove it to the end of time and we can move on to the next concept to prove.
Add comment