First Principles

We still don’t know how to describe ourselves

We all know the problem. Software developers still don’t know what we do for a living. We’re told we’re all manner of things we’re not: craftsmen, artists, engineers, athletes, scientists, machines. There are facets of each of those <i>things</i> in what we do. But even added together, those are not what we do.

… first-principles analysis is never complete; much like a theorem, demonstrable but never proven.

If we use first principles we might be able to deconstruct the what and the how of software development. Maybe then we can define our profession. We might even come up with a new name.

Let’s start with what we do.

What do we do?

So let’s use first principles to break down what we do. I imply no order in this list.

• We exhibit domain expertise in two domains: the technical and the problem. (Problem domains might include business, retail, manufacturing, distribution, medicine, aviation, communication, or entertainment; among hundreds of others.)
• We pursue simplicity.
• We avoid cleverness.
• We identify problems and break them down to their smallest parts.
  • We are a race of listeners.
  • We have experience in finding the atomic elements of both problems and solutions.
  • We know and study patterns of both business and automation.
  • We never stop asking “why.”
• We invent solutions to those problems with the problem domain as the primary concern; not the technology. In this, we are like Frank Lloyd Wright who built homes and businesses with three viewpoints in mind:
  • the environment
  • the resident
  • and the use
• We judge:
  • Importance of problems
  • Difficulty of solutions
  • And we weigh the balance between both
• We act adeptly in isolation or in groups, with little preference for groups. We act efficiently in pairs, though.
• We deliver automated solutions that people want to use and like to use that change the outcome of systems.
• We test our assumptions and test our knowledge.
• We rebuild what we built when we judge that we built it poorly.
• We constantly study to extend or expand our knowledge.
• We constantly train to hone our skills.
• We constantly communicate with others in our profession to share and learn synergistically.

What do we make?

Using first principles again, what do we make?

• We write logical instructions a computer can understand that have the following qualities:
  • They can be easily and repeatedly measured;
  • They are easily modified;
  • They are easily understood;
  • They act in an expected manner;
  • They are efficient;
  • They remain sufficiently isolated so that state changes or code changes remain local;
  • They result in a desired outcome;
• We design and present pleasing and ergonomic methods of interaction for the user or the systems.
• We attempt to model, to the best of our understanding, the problem domain and our solutions.

No, what do we really make?

We build transformation engines that act rationally on inputs and produce changes in outcomes.

Let me repeat that:

We build transformation engines that act rationally on inputs and produce changes in outcomes.

[emphasis added]

A “first principles” breakdown of that follows.

We don’t write code, or automation, or ETL, or any such drivel, any more than an explorer, dipping a toe into the Mississippi River would be satisfied with “wet.” Our charge from our customers is to change outcomes.

Game developers change reality into death-defying excitement and overcome death with a resurrecting reset.

Business developers change time-consuming build and ship processes into streamlined instructions and intuitive information so that they can beat their competition and win customers.

Medical developers acquire and interpret physical and medical readings to remove clutter and provide priority information to doctors and medical staff to save lives.

Notes about differences

In the preceding section we can see facets of architecture, craftsmanship, engineering, and automation. But there’s a distinct difference.

No architect ever built his shrine to architecture with the thought, “I must design this in a way that allows change. Better architects will follow and should be able to improve it without destroying the entire building.”

No craftsman ever carved his ornate cabinet facade with the idea that the materials and style must yield to fashion when the style changes.

We are a race of listeners.

No engineer built a bridge knowing that every year, or month, the bridge would require additional properties: new lanes, different supports, fewer trusses, more cables, or even new exit ramps to different streets.

Software developers may be called architects, craftsmen, or engineers, but no architect, craftsman, or engineer would tolerate, much less accommodate these ridiculous expectations. Yet, software developers go into the task knowing these — and far more, even more ridiculous demands — await.

The difference is the difference

Back to first principles, if time and caprice demand that we plan and allow for changes in our code, then code cannot be our purpose. The code can only embody the current genetic expression of our purpose. Still, this means that something lurks behind the code, even behind the expression of the code that can, more clearly, define software development.

Software developers may be called architects, craftsmen, or engineers, but no architect, craftsman, or engineer would tolerate, much less accommodate these ridiculous expectations.

This conclusion agrees with other configurable aspects of our profession: that we may work in different languages and still deliver a customer’s solution; that we may provide a host of different algorithms and still solve a problem; that we may host our solution on multiple platforms (all at once!) and the solutions still hold.

Therefore, the thing upon which most observers and contributors judge us — our code — serves as the very thing that obscures our underlying significance: our first principle of existence.

Why do they hire us?

Employers and clients hire us. We must provide something valuable – or at least promise something of value – for that arrangement to persist. The first of twelve principles of agile development states, in part:

… satisfy the customer through early and continuous delivery of valuable software…

http://agilemanifesto.org/principles.html

This wording allows interpretation and, depending on the perspective, several bud, but only one or two common interpretations remain true to the values of the agile manifesto. Improperly broken from context (and from the rest of the principle) two get loud acclaim by managers:

• Satisfy the customer
• Continuous delivery

But the whole must be embraced within the context of what we’ve come to realize: that software development does not start nor stop at software.

Satisfying the customer comes through software developers when they fully embrace the customer’s problem (and problem domain) and fully solve the problem by delivering software that changes the customer’s state. If code were the answer, we could have machines generate code and our customers would be delighted. (Indeed, offshore machines endeavor to produce code that must, often, suffer complete rewrites before it is even acceptable to the compiler.)

Successful software developers enjoy a kind of binocular vision to see both the problem state and the solution state; capable of finding the path that leads from the problem to the solution, manifesting the state changes that transform from prior to subsequent states, until the arriving at the solution. Sometimes these states represent data. Other times they represent human effort or perception. But even a simple data transformation from OLAP to report can demand such vision and transformational exploration that few but experts succeed without many trials.

Indeed, offshore machines endeavor to produce code that must, often, suffer complete rewrites before it is even acceptable to the compiler.

Beyond the ability to transform the state of a system, customers often call upon software developers to alter the quality of a system. A best example comes from the adage, “Garbage in; garbage out.” But in our latter day, the demand comes from customers: Garbage in; Gospel out. In other words, they expect (and software developers deliver) systems that take questionable — or even bad — data and transform it into good data.

These visible trappings of our profession do not, of themselves, represent anything that makes us different or makes us valuable.

This is nothing short of the magic of the alchemists who were tasked with transforming lead to gold.

Next, but far from last of the reasons customers hire software developers, we understand and accept the rigor of logic. This alone places us beyond the pale of artist, craftsman, scientist, or even engineer. We not only accept the rigor of mathematical logic, we thrive within it and bend it to do our will… logically. In other words, we are naturals within our technical domain and can, with the least pain possible, translate human ideas into machine instructions that seem, even if they’re not, natural.

Lastly, and likely most importantly, we succeed at altering outcomes of systems.

In first principles

Software developers think and act at the whole system level. We understand that complex systems only function when working together. By slicing and dicing them, we realize that systems become useless silos. Therefore, when we work, we work systemically.

This doesn’t mean that we work on the entire system all at once — all at the same time. Indeed, no. We use our skills to isolate, but not separate units in the system. And there’s a unique difference about what we do and how we do it.

We use these taxonomies in our problem and solution domains to retain the dependencies while separating those issues that can be manipulated independently. These analytical skills grow with experience and do not arise naturally. This is because complex business and technical systems are not natural, but grow from invention and necessity.

In simple words, we use non-destructive, four-dimensional inspection to analyze systems and their outcomes in order to design and create automation changes that will improve outcomes. To do that we leverage the following:

• We fully embrace the customers’ problem domain, dedicating to learn it, in some cases more completely than the customer.
• We fully embrace the solution domain. This is often the outsider’s only view of software developers, because this is where they see us work and where our terms and tools confuse them.
• We are explorers who can find a clear path from problem to solution.
• We can visualize techniques to transform many original states to solution states.
• We can manipulate entire systems to transform quality.
• We inhabit logic and make it look natural.
• We deal in outcomes, not output.

That’s what we do. Everything else misleadingly applied to our work (code, software, documentation, estimates, tests, et.al.) are tools and techniques, or intermediary products. These visible trappings of our profession do not, of themselves, represent anything that makes us different or makes us valuable. It’s a trap!

The problem remains

The problem remains. What do we name ourselves? It would seem so simple to call ourselves, software developers. But that name already carries so many overloaded misconceptions that it’s safer to ditch the name than to rehabilitate it. The same, sadly, follows for any other professional nomenclature to which the modifier, software, has previously been attached. Therefore, software engineer, software scientist, software developer, and more must be ditched. In fact, since the term software misinforms from the start, it should be ditched, too.

• conductor
• transformation
• change
• policy
• alchemy
• sysalchemist
• automation sysalchemist
• enterprise sysalchemist
• sysformer