LabVIEW Craft
  • Blog
  • About
  • Contact
  • Tools
  • Resources

The God of Software

2/1/2017

4 Comments

 
Jon McBee
I love reading about ancient Roman history and I also love reading about software design.  Occasionally those two areas of interest smash together in my brain and weird ideas come out.  This post is one of those weird ideas, I'd like to introduce you to Janus, the god of software.
Picture
Janus is the ancient Roman god of beginnings, gates, transitions, time, doorways, passages, and endings.  As the god of transition Janus presided over the beginning and ending of conflict, and hence the doors of his temple were open in time of war, and closed to mark the peace throughout the ancient Roman republic.
In Latin Janus is spelled Ianus and Cicero explains the etymology of the name as being derived from the verb ire, meaning to go.  From Ianus we get the words ianua, which is door, and ianitor, which is janitor.  Saving the topic of janitor being derived from Janus for later, we can begin to see that Janus embodies the idea of  transitional movement, which we will call change.  Extrapolating one step further we can say that Janus is the god of change.
In his Clean Code series, Robert Martin (a.k.a. Uncle Bob) talks about the primary and secondary values of software.  Uncle Bob states that software's secondary value, which is the type of value we are most familiar with, is that our software does what our customer wants it to do today.  Our customers typically have this secondary value in mind when they evaluate what we deliver to them.
However, Uncle Bob claims that our software's primary value is that it is soft, i.e. it is able to meet the changing needs of the changing customers.  This statement has a profound impact on how we both interact with our customers and write our software.  It is this idea of change that is core to the principles of agile software development.
Janus is typically depicted as having two faces, one looking into the past and one looking into the future.  ​As software developers we don't have the luxury of being able to look into the future and so we have to move forward knowing that change is inevitable.  We account for this inevitable change by cleaning our code as we write it, so that our code is able to embrace the changes as they come.
So let's embrace Janus as the ancient Roman god of software development.  Janus embodies change and as software developers we need to embrace change.  Closing the etymology loop, we saw before that the word janitor comes from combining Janus with the suffix -tor, meaning "caretaker of a building, person employed to see that rooms are kept clean and in order".  As software developers we act as janitors of our code, caretakers focused on keeping it clean and in order.  It is by being janitors of our code that we are able to deliver on our software's primary value.

Jon McBee is the Founder and Managing Partner at Composed Systems and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, an NI Certified Professional Instructor, a LabVIEW Champion, and a Certified ScrumMaster
4 Comments
Frank Whalen link
2/3/2017 09:20:59 am

Jon:
Are you familiar with Arthur Koestler, author of "The Ghost in the Machine" and "Janus"? He coined the term "Holon", something that is simultaneously a whole and a part, assembled in a hierarchical system.

From https://en.wikipedia.org/wiki/Janus:_A_Summing_Up:
"Every holon is like a two-faced Janus, the Roman god: one side (the whole) looks down (or inward); the other side (the part) looks up (or outward). Each whole is a part of something greater, and each part is in turn an organizing whole to the elements that constitute it. "

Individual LabVIEW VI can be thought of as a holon within a hierarchy of VIs which create a LabVIEW application. Each VI is both an autonomous whole, and a dependent part, subject to control at higher levels.

Reply
Jon McBee
2/3/2017 11:02:49 am

Hi Frank,

I had not come across Koestler's idea of Holon's before, it's an interesting take on hierarchies as a context for LabVIEW programming. It reminds me of Simon Brown's approach to software system design that he calls the "C4 Model".

Reply
Russ Fear
10/1/2019 03:14:08 am

Amazingly, i ended up on this page looking for inspiration on what to name a database that i am about to create a C4 notation blueprint in. Holon it clearly is!

Yoni Bar
4/17/2024 01:00:30 pm

Why complicate it ?
If you are looking for a God to worship just go for Hephaestus
He is the god of all Engineers, artisans, blacksmiths, carpenters, craftsmen, fire, metallurgy, metalworking, sculpture and volcanoes.

Reply



Leave a Reply.

    RSS Feed

    Tags

    All
    Abstract Messaging
    Actor Framework
    Agile
    AI
    Asynchronous Programming
    Best Practices
    C#
    Complexity
    Continuations
    Control Values By Index
    Craftsmanship
    Dependency Inversion
    Dependency Viewer
    Futures/Promises
    Genetic Algorithm
    Liskov Substitution
    Malleable VIs
    Mediator Pattern
    .NET
    Object Oriented
    Object-Oriented
    Packed Project Library
    Parallelism
    Polymorphism
    Pub/Sub
    RawCap
    Root Loop
    Scrum
    Task Parallel Library
    TCP/IP
    TDD
    Test Engineering
    UML
    Unit Test
    VI Scripting
    VI Server
    WireShark

    Archives

    October 2019
    April 2019
    July 2018
    October 2017
    March 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    August 2015
    February 2015
    January 2015

    LabVIEW Blogs

    Eyes on VIs
    LabVIEW Hacker
    VI Shots
    LabVIEW Artisan
    Software Engineering for LabVIEW
    ​Wiresmith Techology
Picture
Powered by the Panda Ant

  • Blog
  • About
  • Contact
  • Tools
  • Resources