On Tue, Jan 3, 2012 at 9:17 AM, Gabriel Michael Black <[email protected] > wrote:
> Quoting Steve Reinhardt <[email protected]>: > > On Sun, Jan 1, 2012 at 10:36 PM, Gabe Black <[email protected]> >> wrote: >> >> A hack that works is not necessarily any better than code that doesn't >>> work because it will have to be maintained and worked with/around for a >>> long time. >>> >> >> >> I strongly disagree. There's a huge difference between "works" and >> "doesn't work", because those map directly to "useful" and "not useful". >> Obviously "maintainable" is also hugely important, but if we think that >> "maintainable" is more important than "works", we should just give up now. >> A piece of code that does nothing is supremely maintainable, and its only >> flaw is that it's not useful, so that's the destination you're headed for >> if you prize maintainability over utility. >> >> Obviously we really want both, but let's keep our priorities straight. >> >> Steve >> ______________________________**_________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >> >> > I'm keeping my priorities where they are. It's much better to take the > extra time to do something the right way than to waste little bits (or > lots) of time again and again over the long hall. That's especially true > when the first pass becomes the only pass, and some poor soul gets stuck > with fixing it after everyone including the original author has forgotten > all about it. > > And of course I'm not talking about extremes. Never writing the code at > all is not the same as taking a bit longer to write quality code with a > good design. Quality code is not the same as perfect code. No one is arguing against taking "a bit longer to write quality code". We consistently spend a lot of time tweaking patches on reviewboard to improve things even in small ways before they go in. The issue is what we do when doing something the "right way" is a huge project involving a significant complex code rewrite that no one is currently working on or even imminently planning to work on, versus an admittedly inferior but simple change that does fix the immediate problem at hand. Your original statement very clearly says that you would prefer to leave the code broken indefinitely into the future than to settle for the simple change. That's what I disagree with. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
