Prometheus Blogs

Software development in the late Cretaceous period

09/14/2016

The harder a problem is, the more helpful understanding and analysis become. UML can be used as a tool for visualizing and refining a solution at early, less expensive, stages of development. I pluralized “stages” because I’m not recommending waterfall.

Most people see the folly of constructing a building without a blueprint, based only on a verbal description. And yet software is often built that way. I can only speculate as to why.

  • Many managers like to see progress. Even if it’s false progress toward an unsustainable solution. When a manager is more enlightened, stakeholders may not be. Intangible things (like understanding) are presumed to be worthless.
  • People are often afraid of complexity, and UML diagrams superficially look complicated. Ideally, that fear wouldn’t matter. Most people believe they are logical thinkers. More often than not, human decisions are actually rationalizations of decisions based on emotions. The neocortex is really a public relations spinmeister for more primitive parts of the brain. This is pretty well accepted by psychologists, including people in sales. Demagogues (such as Joseph McCarthy) provide even clearer examples.
  • Mental inertia. Many people would rather continue to do what they already do (even if it doesn’t work well) rather than “wasting” time and effort trying to find a better way. Heck, people persist in suboptimal practices even when a better way is tied up with a bow and delivered on a silver plate. As a gut wrenching example, physicians accepted as normal a mortality rate of 10–35% among new moms. When Ignaz Semmelweis (image below) demonstrated in 1847 that hand washing reduced mortality to 1–2%, the medical community largely ignored him and his theory of hand-borne “cadaverous particles”. They didn’t take Semmelweis’ hand washing advice seriously until Pasteur and Lister confirmed germ theory, a few years after Semmelweis was beaten to death in an asylum - about twenty years after his ignored discovery.

Ignaz Semmelweis

Physicians of his day rejected Ignaz Semmelweis’ crackpot ideas about hygene, in favor of using leeches to balance the four humours.

  • Inability to acknowledge mistakes. This is closely related to the above. See, for example, ”Mindset: The New Psychology of Success”.
  • Misconceptions abound:
    • “UML is time consuming”. If your process is well automated, UML is actually faster. Even if you lack that automation, UML is less time consuming than rewrites.
    • “UML is just documentation”. Some people use it that way… and that doesn’t mean it the best way to use UML. I regard UML as just another language - a higher-level, more productive language.
    • “UML locks you into a design”. UML isn’t immutable. Code can easily lock you into a design at least as easily as a model can. I don’t want to be unpleasant - and it seems to me that only fools and madmen would deny having seen plenty of hacked-together code that was likely to fall apart at the slightest touch. Accurate models can make it much easier to see what you need to refactor, and how to do it.
    • “You can’t define a problem until after it’s solved”. This seems to presume that problems are solved magically by blundering about - a random walk in solution-space that investigates many non-solutions until enlightenment slowly dawns, or every wretched non-solution has been exhausted. No doubt some people do work that way - they are best avoided in favor of someone who accepts the “measure twice, cut once” idea. My experience has been that problems can always be defined, that careful definition of a problem takes you most of the way to a solution, and that half-baked non-solutions are an impediment rather than an aid.

UML models should be living things, that grow and evolve side by side with code as the software grows and changes. You can, of course, engrave models in stone at the beginning of a waterfall process, but it certainly doesn’t have to be that way. At each step, make or revise UML models, paid-for by automation. It’s not theoretical. Some tools do round trip engineering. Personally, I prefer to pick one artifact (I’ll let you guess) as fundamental, and generate the others. So please, don’t throw out the proactive baby with the bath waterfall.


This was also published as an answer on Quora.

Reader Comments
Leave a Comment

Back