Re: The dangers of perfection, and why you should stick with good enough

[samizdat]

Since we don't want The Business to 'shoot the engineers', we'd better be part of the solution. :) I think you've raised some great points here, as has BrowserUK. I agree with them, so the question becomes, 'how do we get not broken, sometime soonish, and reasonable cost?' I've been exposed to an Agile Programming seminar recently, and I think there's a lot to be said for some of their arguments. You have to be willing to rethink 'not broken', though, and that's hard to get an engineer to do. We want to spend lots of cycles perfecting underlying mechanisms, but Agile says 'release early, release often'. The seminar presenters suggested that there's more value to mocking up an end-to-end transaction for one use case, and getting customer buy-in on it, than in crafting a perfect back end. By using such methodology, we hand the responsibility for deciding 'good enough' back to The Business, where it belongs. As you iterate through more and more use cases, you get instant feedback on what 'not broken' means, so you end up crafting a better end-to-end-product. The Business, in turn, gets to draw the line on 'sometime soonish' and 'reasonable cost' without ending up with crap.

As you can gather, I'm sold on this concept. I have been on dozens of projects -- and run some myself -- where engineering of internals, or programming methodology, took precedence over pleasing customers and responding to their feedback. All too often, the temptation is to get lost in details because they're fun and they're safe. Unfortunately, without constant pressure to prove 'not broken', we often end up with smoothly functioning but worthless pieces when the business runs out of patience or money.

We engineers need to grow into having more business sense. It's less and less possible to be a subject matter expert in a prograamming language and have that be enough. In truth, the 'business sense' I'm talking about is not that different from 'common sense', but the sad fact is that few have that, either.

One piece of advice I heard recently was 'spend the company's money and your time as though it is your money and your time'. Ultimately, it is.

[Bloodrage]

One piece of advice I heard recently was 'spend the company's money and your time as though it is your money and your time'.

I've seen this work spectacularly badly at Universities, where every effort is made to horde the income from projects for 'rainy days', to the detriment of the project. Very similar to the way the project leader ran his own finances (lived like a pauper on a strong salary). This was really bad in two ways: His group constantly ran cost over-runs because of equipment failures because of the refusal to service or upgrade equipment, or doing specialist tasks in-house rather than contracting the specialist (usually the statistician). This also often breached the contract with the agency who gave him the grant money for his project! All the funds were for a specific project, not something else and not for profit (which is how 'savings' have to be catagorised here). What was worst was that he never spent those savings, the internal account he stashed his savings in kept getting (legitimately) skimmed to cover costs in other projects (company accounts aren't bank accounts after all).

Money, especially a clients money for a project, is to be spent not saved.¹

---

¹ This of course excludes the money marked as 'profit' that should be taken out of the project managers hands immediately, I'm talking about the money that was marked down as 'costs'. Never ever bloody ever run under budget.

[samizdat]

I certainly can't disagree with you, Bloodrage, that there are situations where anal-retentives in the wrong place screw things up. I'm hoping that most engineers I know won't be so stupid as to act like a bean-smasher.

What I meant by that advice was that we should have the attitude that we have to make each dollar and each hour of our time count. That kind of individual sense of responsibility is what makes a free market work and it's also the way to keep a big corporation from descending into bureaucratic ossification. The best way to reduce operating expenses is to get development done as rapidly and effectively as possible. Sometimes that means spending more to get enough tools to do the job right, other times it means spending more design time on a whiteboard before spending money.