3 ms·
Better is generally better than worse is better. The passive nature of worse is better postpones problems till later on. The philosophy of "worse is better" wor
by lkrubner 8y ago
Better is generally better than worse is better. The passive nature of worse is better postpones problems till later on. The philosophy of "worse is better" works for those who are competing mostly on price, but are you sure you want to spend your career in that category? That can be a tough life, ground down by low cost bids. Among the consultants I've known in New York, the better one's definitely avoid the "worse is better" philosophy. I'm talking about those consultants who charge in the range of $200 to $400 an hour. These people are hired to implement a "best is best" approach. I'm working on a project like that now, where we brought in one of the best AWS consultants in this region to build out a complex infrastructure, following best practices. We are pleased to see something take shape that we know is very good.
Consultants of this type can not afford to be passive, because they are being paid, in part, to push pass obstacles, including political obstacles, and implement an architecture as close to idea as possible.
- pierrebai 8y agoThe problems with that position and how your phrased it are that it is wrong, sounds condescending, is an easy way out and more importantly, completely ignores the real issue. And the real issue is time vs result. That's the essence of worse is better. It's the well documented fact of diminishing return and exponential cost of additional quality. You can deliver N features over a given fixed time. Given the urve of quality vs time, there is a true sweet spot where your maximize value, for whatever criteria you want for the value. Spending too much time on fewer items or too few time on too many will respectively waste time on unnecessary polish and deliver stoo many items of no value. There is a sweet spot.
- pdimitar 8y ago> There is a sweet spot. There is, but it definitely is NOT at one of the extreme ends of the curve where experienced bean-counters will negotiate down the engineering effort (and thus money) to the absolutely minimum necessary for the project not to implode 2 days after release. Truth is, at one point in your career you have to start pushing back against those bean-counters. They will never get tired, and they are everywhere. At certain point you take a stand, put your foot down and say: "No, this will NOT be done in 2 days. It will be done in 5 and thus it won't have to be patched 10 times in the space of a week. If you don't like it, my resignation is ready." You would be surprised how often that works. Many of the business types and managers are bullies only because nobody ever fought back. ...Or you could take a more diplomatic, but still firm, stance. Like "the overall cost of this feature will be much lower if I work on this for 5 days instead of 2". But IMO that almost never flies so I became blunt with time and I simply don't care. I passed five job offers lately for similar reasons and I couldn't be happier about it.
- dustingetz 8y agoI've done consulting at that rate. There is selection bias in what you describe: the kind of client who will pay that rate tends to already know they want "best is better" which is why they hired the fancy consultant in the first place. I have also consulted at that rate to pre-revenue startups, a much harder sales pitch because you're literally decimating their burn. The pitch here is advancing their business to the next stage as fast as possible. For this, worse is absolutely better as they don't yet even know what "best" is. They do however know what "done, delivered your MVP in two days" is. BTW if any of you want your MVP delivered in two days, consulting portfolio is in profile.