Software

  by: Stovall, title: Tribal Dragon, inspiration: face down



Rousing the Sleepy Dragon
When I graduated from college I wanted nothing to do with software.  I was itching to develop motion control systems.  In fact, my first engineering job out of school was at General Electric Medical Systems, where I was assigned to work on X-Ray Computerized Tomography (CT) Scanners.  I was ready to design compensating networks and PID controllers, not if-then-else statements...

I quickly discovered the really cool adaptive control algorithms were best managed with a microprocessor, and those microprocessors required firmware.  I, the chap who boasted I would never write software, found myself cross assembling Z80 code on a DEC PDP-1170.  Fortunately there were experienced hands close by to help me learn the craft.  We had binders of control flow charts that I could read and digest.  When it was my turn to design some fresh code, I reached for my plastic flowchart template.  Boxes, diamonds and lines were hand translated into structured assembly code, where each line was dutifully commented.

It was beautiful.  The firmware controlled the electronics which in turn tilted the gantry; raised and lowered the table, and moved the patient into the scanning region in synch with a rotating X-Ray tube. 

 


 

Learning to Breathe Fire
Frankly, although it all worked and patients were scanned, something was missing.  My code lacked elegance and structure. It was daunting to change.  This is where my long association with formal methods of SW development begins.  I attended my first course in Real-Time Structured Analysis, based on the ideas of Ward and Mellor, with some Constantine's Structured  Design thrown in for good measure.  I was hooked on modeling.  I now had useful practices and a visual language I can use to communicate with my colleagues, and myself.  This was far better than dialog in assembly or control flow charts.  My code structure improved.

As it turns out, every software job I had from that point on: individual contributor, technical lead, consultant, manager, director, or influencer, was an opportunity to go deeper into formal methods and visual modeling.  I learned event modeling, state modeling, information modeling, and object-oriented modeling.  My curiosity drove me to learn, along with the challenges of building larger more complex systems, with high-level languages, software frameworks and infrastructure.  As a I manager I goosed organizations by introducing formal methods of architecture and design, and modeling into the culture.

 

by: Nobges Title: Dragon Flying
 

Learning to Fly
Convinced I knew how to design and program, I turned to the question of how to improve the overall productivity of teams.  That brought me to the human element of software development. I already knew how to communicate with the written word; my thesis advisor saw to that. But how to get the most out of my interactions with others was a new chapter for me.

My experience as a modeler and software architect led me to consulting, specifically helping organizations change how they approached Software Development. I guided dozens of companies, each in short bursts, on making change. I was soon to learn my effectiveness as a consultant would depend on having models of human interaction that worked, and worked quickly. Over the years I have studied and experimented with various models of human interaction. I learned techniques for influencing others with integrity, acting congruently, and most importantly, becoming clear. Without clearing my own distortions and blockages, how can I possibly influence others? Or as one of my teachers, Jerry Weinberg puts it so eloquently,

“If you want to be a star spread it wide and spread it far.
But if you want to change the sun, best to start with number one”.

 

 

Title: Smaug, Illustration from Lord of The Rings, by J.R.R. Tolkein



Hoarding Treasure
Dragons are known to be hoarders. They gather gold, silver and other precious metals. Some say it is to lure adventurers into their lair. Others believe as they sleep, the metals adhere to dragon skin forming a hard protective layer. I like to think the reason for hoarding gold is because it is eternal, and never rusts.

Like a dragon I hoard treasure. That is, I gather technologies that are useful for my practice. I program in new languages on new platforms, learn new frameworks, build web sites, take on-line courses, and also learn about disciplines indirectly related to Software.  The technologies adhere to me, forming a thick skin and protection against the blows I may encounter in my daily project work.

My learnings will sometimes lure developers, business analysts, program managers, and other wanderers into my lair. Unlike a dragon I do not truly hoard. My preference is to share what I have learned with others. More often than not, such sharing comes back to me as new treasures I receive from others. Another difference between the Software professional and the dragon is the nature of the treasure itself. Gold is eternal, technology is not. Technology constantly changes and if not careful, the dragon may be perched on a pile of wonderful, but powerless memories. That is one reason why I believe it is important for architects to remain “hands on” and participate in system construction as well as system specification activities. 

 

 

Title: Dragon Drinking Water On Beach.  Artist: GreatRuler



Sipping from the Cool Stream
Forging their art in flames, the dragon needs to consume gallons of water every day to rejuvenate after discharging fire. Balance is key. I seek balance in writing, tai chi, bicycling, hiking... any activity I enjoy that takes me into a new state of mind for a little while. Coming back to a problem rejuvenated and recharged, I find more solutions flowing from my intuition and a more focused ability to visualize, think and create.