December 21, 2015 at 11:53 am
roger.plowman (12/21/2015)
Jeff Moden (12/21/2015)
roger.plowman (12/21/2015)
Good, fast, and cheap, pick any two...Always include "Good". Fast and cheap usually follow auto-magically.
I wish. Good and fast (delivered) isn't cheap, good and cheap isn't fast (delivered)
No, sometimes (quite often, actually) it goes as Jeff said. Often when we decide to do it good it will be released earlier than if we had decided to do it fast instead, and every time we decide to do it good it will cost a lot less in the long run than if we had decided to do it cheap instead. However it is generally impossible to convince non-technical managers of this - after all, most companies have a pretty crazy organisation where the cost of customer (or end-user) support of a product doesn't come out of either the development manager's budget or the QA manager's budget. So those managers' concept of "cheap" (slapdash hurried development which cuts the development manager's cost combined with slapdash inadequate QA which cuts the QA manager's cost) ignores significant costs so that it is unrealistic and often their "cheap" is the most expensive path for the company as a whole.
The first serious management job I had (a very long time ago) the dividion I was in (and perhaps the whole company, I don't know) had a very different approach. As development manager for a particular set of products I was reponsible for agreeing requirements/specifications, and for providing development, QA, release, installation, and customer support. Yes, I was under timescale pressures from higher up the tree, and no, we were far from perfect, but everyone in the dividion from the director (VP to our American friends) down to the trainee programmers was fully aware of the real cost of aiming for cheap and the risk that aiming for cheap will end up being very slow.
Tom
December 21, 2015 at 11:57 am
TomThomson (12/21/2015)
roger.plowman (12/21/2015)
Jeff Moden (12/21/2015)
roger.plowman (12/21/2015)
Good, fast, and cheap, pick any two...Always include "Good". Fast and cheap usually follow auto-magically.
I wish. Good and fast (delivered) isn't cheap, good and cheap isn't fast (delivered)
No, sometimes (quite often, actually) it goes as Jeff said. Often when we decide to do it good it will be released earlier than if we had decided to do it fast instead, and every time we decide to do it good it will cost a lot less in the long run than if we had decided to do it cheap instead. However it is generally impossible to convince non-technical managers of this - after all, most companies have a pretty crazy organisation where the cost of customer (or end-user) support of a product doesn't come out of either the development manager's budget or the QA manager's budget. So those managers' concept of "cheap" (slapdash hurried development which cuts the development manager's cost combined with slapdash inadequate QA which cuts the QA manager's cost) ignores significant costs so that it is unrealistic and often their "cheap" is the most expensive path for the company as a whole.
The first serious management job I had (a very long time ago) the dividion I was in (and perhaps the whole company, I don't know) had a very different approach. As development manager for a particular set of products I was reponsible for agreeing requirements/specifications, and for providing development, QA, release, installation, and customer support. Yes, I was under timescale pressures from higher up the tree, and no, we were far from perfect, but everyone in the dividion from the director (VP to our American friends) down to the trainee programmers was fully aware of the real cost of aiming for cheap and the risk that aiming for cheap will end up being very slow.
Yep, that's a trick question. If you pick good you get all three. It's only when you don't pick good as your principal driver that you escalate the costs of the other two.
There are no facts, only interpretations.
Friedrich Nietzsche
December 21, 2015 at 12:13 pm
barry.mcconnell (12/21/2015)
TomThomson (12/21/2015)
roger.plowman (12/21/2015)
Jeff Moden (12/21/2015)
roger.plowman (12/21/2015)
Good, fast, and cheap, pick any two...Always include "Good". Fast and cheap usually follow auto-magically.
I wish. Good and fast (delivered) isn't cheap, good and cheap isn't fast (delivered)
No, sometimes (quite often, actually) it goes as Jeff said. Often when we decide to do it good it will be released earlier than if we had decided to do it fast instead, and every time we decide to do it good it will cost a lot less in the long run than if we had decided to do it cheap instead. However it is generally impossible to convince non-technical managers of this - after all, most companies have a pretty crazy organisation where the cost of customer (or end-user) support of a product doesn't come out of either the development manager's budget or the QA manager's budget. So those managers' concept of "cheap" (slapdash hurried development which cuts the development manager's cost combined with slapdash inadequate QA which cuts the QA manager's cost) ignores significant costs so that it is unrealistic and often their "cheap" is the most expensive path for the company as a whole.
The first serious management job I had (a very long time ago) the dividion I was in (and perhaps the whole company, I don't know) had a very different approach. As development manager for a particular set of products I was reponsible for agreeing requirements/specifications, and for providing development, QA, release, installation, and customer support. Yes, I was under timescale pressures from higher up the tree, and no, we were far from perfect, but everyone in the dividion from the director (VP to our American friends) down to the trainee programmers was fully aware of the real cost of aiming for cheap and the risk that aiming for cheap will end up being very slow.
Yep, that's a trick question. If you pick good you get all three. It's only when you don't pick good as your principal driver that you escalate the costs of the other two.
Noooo, I'm afraid I'm going to have to disagree here. Quality takes time. Quality isn't just meeting specs, there are a lot of intangibles involved too. Is it secure? Will it scale? Is it maintainable? Has it been well documented? (both in the code and db-related design).
All that takes extra time and is part of "good". 😀 But that time is also cost, and if you want it delvered yesterday (and tell me one client that doesn't) you're going to have to throw lots of resources at the problem--which isn't cheap.
Not to mention if you want it fast (as in executes quickly) that requires a lot of optimization--which takes time.
That's why it's an engineer's triangle. 😎
December 21, 2015 at 1:10 pm
Tom and Barry said something like, If you pick good you get all three--Yes this.
December 21, 2015 at 1:58 pm
GeorgeCopeland (12/21/2015)
Tom and Barry said something like, If you pick good you get all three--Yes this.
I disagree with them, you can only get two of the three, depending on the values you assign each one. Good enough may be "good", but it's still at the cost of either delivery time or added expense.
December 21, 2015 at 2:12 pm
roger.plowman (12/21/2015)
GeorgeCopeland (12/21/2015)
Tom and Barry said something like, If you pick good you get all three--Yes this.I disagree with them, you can only get two of the three, depending on the values you assign each one. Good enough may be "good", but it's still at the cost of either delivery time or added expense.
Perhaps it's because so many take that view, without realising that it leads straight to expensive and overdue product of low quality, that software is so often such an awful mess and the software development business is not treated as engineering - after all, not trying for good is not anywhere a real engineer would go (I can assert that because I am a real engineer, and I doubt that you'll find a real engineer that disagrees - of course by "real engineer" I mean someone (a) bound by a professonal engineering code of ethics and conduct required by an professional society of engineers and (b) recognised by the relevant society as a professional engineer).
And anyway, even in order to get two of the three you have to start by aiming at good, because aiming at quick will lead to expensive and not good while aiming at cheap will lead to late and no-good and rather expensive once all costs are taken into account.
Tom
December 21, 2015 at 2:28 pm
TomThomson (12/21/2015)
roger.plowman (12/21/2015)
GeorgeCopeland (12/21/2015)
Tom and Barry said something like, If you pick good you get all three--Yes this.I disagree with them, you can only get two of the three, depending on the values you assign each one. Good enough may be "good", but it's still at the cost of either delivery time or added expense.
Perhaps it's because so many take that view, without realising that it leads straight to expensive and overdue product of low quality, that software is so often such an awful mess and the software development business is not treated as engineering - after all, not trying for good is not anywhere a real engineer would go (I can assert that because I am a real engineer, and I doubt that you'll find a real engineer that disagrees - of course by "real engineer" I mean someone (a) bound by a professonal engineering code of ethics and conduct required by an professional society of engineers and (b) recognised by the relevant society as a professional engineer).
And anyway, even in order to get two of the three you have to start by aiming at good, because aiming at quick will lead to expensive and not good while aiming at cheap will lead to late and no-good and rather expensive once all costs are taken into account.
The problem is when there's a disconnect between developers and customers about what defines good and in a lot of cases cheap and fast are good for a customer. What's good from a technical stand point may not be relevant to an end user.
December 21, 2015 at 3:10 pm
ZZartin (12/21/2015)
TomThomson (12/21/2015)
roger.plowman (12/21/2015)
GeorgeCopeland (12/21/2015)
Tom and Barry said something like, If you pick good you get all three--Yes this.I disagree with them, you can only get two of the three, depending on the values you assign each one. Good enough may be "good", but it's still at the cost of either delivery time or added expense.
Perhaps it's because so many take that view, without realising that it leads straight to expensive and overdue product of low quality, that software is so often such an awful mess and the software development business is not treated as engineering - after all, not trying for good is not anywhere a real engineer would go (I can assert that because I am a real engineer, and I doubt that you'll find a real engineer that disagrees - of course by "real engineer" I mean someone (a) bound by a professonal engineering code of ethics and conduct required by an professional society of engineers and (b) recognised by the relevant society as a professional engineer).
And anyway, even in order to get two of the three you have to start by aiming at good, because aiming at quick will lead to expensive and not good while aiming at cheap will lead to late and no-good and rather expensive once all costs are taken into account.
The problem is when there's a disconnect between developers and customers about what defines good and in a lot of cases cheap and fast are good for a customer. What's good from a technical stand point may not be relevant to an end user.
Even if the definition is "good enough" it will still be cheaper and faster because it meets the requirements. Rework is the real issue behind fast and cheap. Doing it twice will never be faster and cheaper than doing it once to specs. If you have bad specs, that is a whole other problem.
There are no facts, only interpretations.
Friedrich Nietzsche
Viewing 8 posts - 61 through 67 (of 67 total)
You must be logged in to reply to this topic. Login to reply