5 ms·
Isn't it: Quality, price, speed pick any two.
by hartror 16y ago
Isn't it:
Quality, price, speed pick any two.
- anujkk 16y agoVery true.
- redthrowaway 16y agoI don't think quality and cheap are compatible. I can't envision a scenario whereby a project taking a long time will allow it to be done cheaply and well.
- jarek 16y agoBreed monkeys, give them keyboards, wait a million years.
- redthrowaway 16y agoEven then, you'd still only get Perl.
- JoachimSchipper 16y agoFind a good freelancer, offer him/her some interesting work with a deadline of "when you get around to it", and negotiate on price? I don't think this is impossible. (Of course, you'll need to find a freelancer who can do a good job but can't fill 100% of the hours (s)he wants to work. That may not be trivial, but it's possible.)
- retroafroman 16y agoDoing it yourself over a long period of time as a personal project. That way you could do it as time permits, which is pretty much free, and then the code would also be up to your own standards because you did it yourself.
- anthonyb 16y agoFor the love of Knuth, stop using Quality as one of your project axes! Quality is non-negotiable - as soon as quality slips, everything else slips, too. Better options are Cost, Scope and Schedule (or Features, Price, Speed): http://en.wikipedia.org/wiki/Project_triangle http://en.wikipedia.org/wiki/Project_triangle
- Stormbringer 16y agoYes! That is it. Software must be one of the few things in life where going for the higher quality actually makes it cheaper and faster to develop.
- jshen 16y agoYou only have to get over a certain bar. Improving code after that point isn't a good ROI
- quanticle 16y agoNot necessarily. Having code that is easier to modify or has fewer errors is a competitive advantage. Given that all your competitors are trying to improve their codebases, you should be trying to improve yours as well.
- jshen 16y agoI don't think you understood my point. I agree with you up to a point. No programmer I have ever met has felt that any significant codebase they are working on is perfect. At some point you have to say that it's good enough and move onto new features or new projects.
- anthonyb 16y agoI'd love to see that, but all too often it's the opposite - stuck on bugfixing antique, crappy code because somebody did a dodgy hack and figured it was "good enough". Taking the time to do it properly means that you ultimately go faster, not slower.
- gvb 16y agoIn this case, speed wasn't a variable. I intentionally left it off. (Thanks for being my straight man ;-).