Professional Perfectionism

Many professionals tend to approach tasks with a strong, sometimes overriding focus on the ideals of their profession. This sounds good, unless you are footing the bill.

I think a lot of discussion around "doing software right," especially the economics thereof, is biased by a sort of ProfessionalPerfectionism by software engineers. To even talk about doing software "right" implies an ideal, and that anything less is "wrong." But I would argue that to some degree, we produce some combination of products and services, and our criteria for success or "right" should be value to the customer. It is nice to want to create excellent, elegant, flexible, customizable software solutions, and even better to do it with a new, improved process, but if we don't (1) solve the customer's original problem, (2) stay within the customer's budget, and (3) meet the customer's need in a timely way, then we've let the perfect be the enemy of the good... -- AndyMoore

I would paraphrase the above to say that a professional views software as a support service provided to a customer, not an end in itself. Once you view software as a service, many of the issues relating to "perfectionism" vanish. -- WayneMack

You notice this quite often with auto mechanics. You bring your car in for routine maintenance, or some specific minor work, and the mechanic points out half a dozen other things your car "needs." When these items are clearly safety hazards, you're grateful that they raised red flags about them. But there's a slippery slope here; in theory, almost every problem in a vehicle is a potential safety hazard. You feel uncomfortable deferring any work that your mechanic recommends; you feel like you're gambling with your life if you do. Even when they aren't safety issues, many people don't feel they are in a position to question or negotiate with a professional; they aren't experts, and the professional might be right. See FearUncertaintyAndDoubt.

The point is that, at any given time, the components of a car are in various states of functionality, different points on a continuity between "perfect" and "totally broke." Where you want or need your car to be is a personal choice, and is very dependent on many factors, including need for safety (do you drive your family in that car?) and financial situation. Only you can decide what repairs you are willing to pay for at any given time. Your priorities are often entirely different from the professional who is doing the work. You're paying for it, so you have the ultimate decision.

On the other hand, you could argue that professionals are responsible for the safety of a vehicle, regardless of the wishes of the owner, and shouldn't allow an unsafe vehicle to leave the shop. (Not sure what the laws are in this area; probably varies a lot by locality.) If your profession is building bridges or other areas where safety issues are broader and the results of errors greater, this argument becomes even stronger; at some point the professional needs to override what the customer says they want and give them what they need (satisfy the unwritten requirement that your work not cause death, injury, or other unpleasant results).

When I was in England, my car was subjected to an annual "MOT" (Ministry Of Transport) inspection. If any of several items failed, the mechanic was essentially forbidden from releasing the vehicle (if you insisted on taking it, there was a reporting process). At best, you didn't get your MOT badge, and driving without one was good for a fine and other hilarity.

It might be amusing to imagine "MOS" (Ministry Of Software) regulations that obliged the programmer to "detain" a system if their inspections discovered "financial safety issues" in the code. "Sorry, sir, you can't have your program back until I fix these math routines. Where did you have your last work done? Yes, I understand, sir, but you'll just have to rent another program for a month or two while we clean this up; it's a real mess. No, sir, if you insist on taking it as is I'm obliged to report your software as unsafe to operate in financially related matters. Right then, we'll get right on it. When? I'll just get a few of my mates down here and we'll have it set right before June. Glad to be of service.

-- GarryHamilton

The problem is that usually "perfect" is merely an opinion. Software can always be improved, but we need to focus on a limited set of improvements to do now.

See IsThereEverGoingToBeSufficientEconomicIncentiveToDoSoftwareRight. I think to ask the question in that way shows ProfessionalPerfectionism.

One person's ProfessionalPerfectionism is another's ProfessionalResponsibility.

I once read that the industry should encourage perfectionism to motivate developers to make more reliable software, and the argument was that way too often one writes a piece of code thinking it will make it more reliable later. I identify with that developer: checking, constraining, writing contracts on interfaces, etc., is not quite the interesting part of coding, but nevertheless it's crucial to reliability. Any line of code contains invisible boundaries and they are often ignored. I discovered that when I started coding with assertions and contracts. I was astonished how bad my code was in the details despite the ultra-flexible architecture that I was so proud of. -- CosminApreutesei

Ever watch an expert craftsman (potter, painter, welder, ...) working on something? They don't slow down to avoid mistakes--they just avoid mistakes. If it takes me six years to carve a flawless tombstone, I should find another trade. Unlike programmers, there is no particular shortage of stonemasons. There is no need to choose between shoddy work and no work at all. Professionalism includes doing flawless work without slowing down. It takes native ability, a lot of practice and serious dedication. --MarcThibault

I submit that this is untrue, or at best a tautology - one way of defining expertise is how few mistakes you make and how fast you can work. Interestingly, most tombstones are a) not made by experts and b) not unflawed. I think our definition of flawless is not consistent between software and mechanical things and our ingrained acceptance of lack of perfection in the real world makes our tolerance almost invisible. Your software can be less than perfect without being shoddy. I don't think software is perfect, far from it, but if we're going to define our standard by other professions and by real-world mechanisms (which I am not convinced is usefull in any case), then we need to do a realistic and accurate analysis of those professions and real world mechanisms. Is software a mass-produced chair, built from stock parts and assembled by minimum wage employees, where a slight bend in a leg or imperfection in a join is fine as long as it doesn't fall over when you sit on it? Or is it a one of a kind chair hand made by a master carpenter, using only the best wood, carefully planned and envisioned, with every piece measured precisely and joined perfectly? The difference between these things is important. There's a reason why the chair you're sitting on right now is very unlikely to be the latter. --ChrisMellon?

Agreed. Of course, the more complex and interactive the application (a wrought iron gate has a quite finite scope) the more consideration has to be given to the other (complex) things in the mix. The programmer is working simultaneously with his compiler, OS, hardware constraints, business rules, user needs, user mistakes, and the needs or demands of his co-workers and/or company. So, while he may not "slow down" he may stare off into space as he constructs future scenarios involving various unknowns and occasionally unknowables. It could be likened to many-handed chess, where some boards are viewed and some hidden, but with the twist that a failure on one board might cost you the game on another. So, yes, practice and dedication, and in this case, vision. -- GarryHamilton

The difference between a program and a chair is that, if I have a program, I can sell it and I still have it. The better craft analogy is to consider the mold that's used to cast a chair or one of its parts. Like software, the mold will be made once and used many times--the cost of doing it well is amortized over many uses and the value is multiplied by the number of times it's used. I want my best people making molds. --MarcThibault

CategoryIdealism