If you don’t know where you’re going, any road will get you there.
– Lewis Carroll
So far, this series has been exploring some typical disastrous software projects. As well, I have presented a model for analyzing these projects, which so far seems to be able to explain why these projects went off the rails. But of course, it is my model and my examples, so isn’t that a little too convenient? 
I’m sure at this point, many readers who are Engineers have objections to some of the things I have said. Taken at its worst, I’m saying, “Nothing you do within the deep bowels of the Engineering function is particularly important.”  Some will say, “How can you be so sure that it’s the interaction with Customers that matters most? How about code quality? How about Test-Driven Development? Isn’t Architecture really important? How about Continuous Integration / Continuous Delivery? Where do Microservices fit in? And the cloud? And blockchain, you idiot! Have you lost your mind? Are you really a technical person (I saw a picture of you in a tie! And I heard you are really good at PowerPoint!)?” 
So, ignoring these questions for a moment, let’s talk about the objective or purpose of the Engineering function. We all have our own opinions on what this is and deciding amongst opinions is tricky, so I’m going to analyze the objective objectively . I’ll accomplish this by doing something very Engineer-like: going back to first principles. So, let’s start with the general principle of objectives in organizations. 
Alignment of Organizations
In any complex organization, there are many separate components or sub-organizations. The overall organization has a defined objective (or so we hope). How do we determine the objectives of each smaller part of the organization?
I propose that each sub-organization within the overall organization has to have an objective that aligns with or supports the overall organization. So, what does this look like? Let’s imagine that we draw an organization chart and represent the overall objective as a big arrow pointing straight up. I am suggesting, that to be high functioning, each sub-organization’s objective (arrow) should point in the same direction in support of the overall objective. 
I know that this sounds obvious, but I expect that if you were to write down the objective of each division in your organization (or, more accurately, their inferred objective based upon their actions), you would find this not to be the case.
How am I so sure this is the right model? What if we imagine the opposite – let’s imagine a real organization where the Accounting group believes that the most important objective is to contain costs; the Sales group decides that the most important thing is to maximize top-line sales and the Engineering group decides that the most important thing is perfectly written software. The overall organization is a for-profit one, so let’s assume that its objective is to maximize profit. You can imagine the mayhem that ensues (I’m sure many of you don’t have to do imagine). The Sales team says whatever it needs to get Sales and cares little about margins or Accounting . The Engineering team tries to perfect their art and takes forever to ship; the Accounting team finds the spending very upsetting, so cuts budgets for Sales visits and the Engineering team. We shouldn’t wonder when the overall objective of profit is unmet. 
This would look a little like:
As obvious as this sounds, many Sales, Engineering and Accounting operations act precisely like this. Only when the objectives are the same (or at least aligned) top to bottom can an organization achieve what it intends.
In my footnotes, I explain (for those of my readers who are fans of the Life Sciences, as opposed to the Computer Sciences) how this organizational model mirrors the natural world. But do you know what is interesting about the above organizational model from a Computer Science perspective? It’s precisely how software works – code has an overall objective and a starting point (called “main” in many languages). From that starting point, the code calls various functions  and each function fulfills some portion of the overall objective. The resulting call flow is something like (and this might look familiar):
You would never intentionally write code that did something completely useless to the objective of the overall program. Such code could cause a bug or some other type of mayhem, such as sucking up all the computing power or memory . Code that does a lot of things that it shouldn’t looks a little like (and this might look familiar):
So, I hope you’re bought-in to the fact that for an organization to function effectively, each sub-organization has to have objectives aligned and supportive to those of the overall organization. Based on this conclusion, for us to figure out the objective of the Engineering function, we can start with the overall objective of the company and work our way down.
So, what is the overall objective of a software company? Let’s assume that we are dealing with a publicly-traded company  – its highest-level objective is to increase shareholder value. The owners of the company expect to make a profit on their shares over the long run, either through dividends and/or an increase in share price. But how do we do that? For nearly all companies , increasing shareholder value is accomplished by increasing profit, which is normally accomplished through increasing Sales . How do we sell more software (and/or Services if that is also part of the model)?
There are generally two ways to sell more: through selling the same software to more customers or by selling more software to the same customers (or both, of course). How do we do that? In the former, by having software that provides obvious value and selling the hell out of it. For the latter, by creating new features or completely new products with obvious value. By “obvious value”, I mean having something that the customer looks at and says one or both of: 1) this will make us more money than it costs, or 2) this will save us more money than it costs .
So, based on the earlier assertion that every sub-organization should have the same objective (or one in direct support of) the overall organization’s objective, the primary objective of Engineering should be to deliver value to customers. I don’t think anyone in Engineering would vehemently disagree with this, but I would suggest that, by their actions, most Engineering groups I have observed don’t take actions consistent with this primary objective. So let me restate this objective, because it is one you will hear repeated in nearly every post on this site because it is the foundation of succeeding as an Engineering group:
The primary purpose of Engineering is to efficiently create valuable functionality for Customers.
Notice that this objective doesn’t directly say anything about Architecture, frameworks, languages, coding standards, testing approaches, etc. It’s not to say that these things are not important, but they are only important in so much as they help achieve the overall (and really, only) objective which is to provide value. A corollary of the above objective is the following:
The only Engineering activities that are worthwhile are those that lead to delivering value to the Customer.
Ironically, this is pretty much the same as what I posited earlier in the Customer Membrane model:
So, we’ve arrived at the same conclusion through two different routes , so I’m hoping my bold statement  above carries some credibility. It is my most strongly held belief about successful software development and will be the foundation of everything we talk about going forward. That is also to say, if you believe otherwise, please comment below so we can discuss.
In the next post, I wrap up this series by suggesting the first step to solving our Engineering problems.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
 It is pretty convenient and thanks for asking. My best suggestion is for you to inventory software disasters from your own experience and see if their failure can be explained via the model. Any model or theory is best measured by its explanatory power over a wide range of data points.
 I’m absolutely not saying that, by the way. I’m just saying that the amazing work we can do as Engineers needs to be guided pretty close to 100% by what matters to Customers.
 BTW, my general answers are: “Read on”, “It’s a good practice, but don’t go crazy with it”, “Yes, please do that”, “Of course”, “It’s vital”, “Not that important”, “It’s just someone else’s computer”, “I have exactly 0.00000 Bitcoin”, “Yes”, “Yes (and 1: don’t sell a tie short– it somehow makes you more attractive, and 2: Please don’t tell anyone because it’s a little embarrassing [like driving a moped], but I’m a PowerPoint god. But before you dis PPT, recognize that it is Turing Complete )”
 Repetition intended (for no good reason). I suppose I could have said “empirically”.
 I apologize if what follows sounds a little theoretical or formal, but it is vital that we establish an air-tight definition of the objective of Engineering or it will be challenging to proceed. You might not agree with the final objective, but I’m hoping you’ll have more difficulty disagreeing with the approach that gets us there.
 Interestingly, if we replace the word “organization” with “organism” and look at the natural world, we would see that the objective of every component or sub-organism either has the same objective or something in direct support of the overall organism. If we trust the Theory of Evolution, every new trait in a species, if it persists over time, does so because it supports the entire organism’s objective, which is to propagate as many copies of its genes as possible.
 although they seem to be very interested in getting their commission.
 Some might point out groups such as accounting, security operations or compliance seem to have objectives at odds with the company’s objectives. At first, these groups might appear to have objectives that are tangential or even orthogonal to the company’s. But if, for example, compliance keeps the organization from being prosecuted for accounting irregularities or prevents a major security breach, you can see that these organizations contribute to an unstated goal of keeping the company running without unplanned interruption or calamity. The overall goal of increasing shareholder value is severely impacted when the company is de-listed off the stock exchange for accounting irregularities (this happened at one company I was at – link).
 i.e., methods, subroutines, procedures, etc.
 or what Engineers would call “unintended side effects”
 The example doesn’t really change if it’s private, although it might if it is non-profit or open-source.
 Ignoring blips such as the Internet bubble of the late 1990’s, the recent bitcoin frenzy and Beanie Babies.
 You can only squeeze out so much cost.
 You can suggest other scenarios, such as “this will provide better Customer Service”, but usually, that distills down to either making more money or saving it. In fairness, this is a very business-software centric thought. For consumer software, such as games or personal productivity tools, there are different assessments made by the Customer. For gamers, it’s something like, “Will I get more than $70 of fun out of that game?”, but it doesn’t change the overall question – “Am I getting enough value out of the software to justify the cost?”.
 The equivalent of checking your work in Math by doing it two different ways.
 Bold in typeface and in its provocativeness.