Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

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

by samizdat (Vicar)
on Mar 11, 2008 at 13:24 UTC ( #673490=note: print w/replies, xml ) Need Help??

in reply to The dangers of perfection, and why you should stick with good enough

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.

Don Wilde
"There's more than one level to any answer."
  • Comment on Re: The dangers of perfection, and why you should stick with good enough

Replies are listed 'Best First'.
Re^2: The dangers of perfection, and why you should stick with good enough
by Bloodrage (Monk) on Mar 11, 2008 at 22:28 UTC

    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.1

    1 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.

      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.

      Don Wilde
      "There's more than one level to any answer."

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://673490]
[shmem]: karlgoethebier: isn't bike riding a way of fixing lumbago?
[karlgoethebier]: shmem: scheiss technik
[karlgoethebier]: shmem: yes - i f you manage it to get on the bike. and pray if you must stop...
[shmem]: in the french alpes, at the end of a gravel road, we had a beer at a hut - and heard an enduro coming up.
[shmem]: not by the road, but from there below where you wouldn't want to walk.

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (8)
As of 2017-06-25 20:06 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (570 votes). Check out past polls.