Category Archives: Uncategorized

Traits of Analytics Led Companies

Imagine you are the CEO of a retailer. The economy is roaring, people are starting to shop more at your higher end shops, increasing margin. Quarter over quarter top line revenue growth is coming in, albeit at a slow, measured growth rate. You are even getting some level of margin growth by implementing some measures to remove excess cost out of the business. Things are going great!

Then, some year, everything changes. A new competitor emerges. Similar brand strength, similar cost structure, even similar locations. However, they seem to get twice as much revenue per square foot, based on some new traffic pattern analysis that they are doing. And they seem to have very savvy staff who are empowered by their systems to recommend products for customers that they seem to actually want to buy. This, when combined with the investment they have made in omni-channel customer experience, is allowing this new upstart to drastically cut into your marketshare.

You are paralyzed by fear. You’ve read a few articles about big data, but given you are a brick and mortar retailer focusing on the high end, you did not think this was as much of a priority. You’ve been focused on cost control and squeezing an extra 10 basis points of margin out of your existing model, and your competitor has leapfrogged you by creating an entirely new model that increases margin 2%. In retail. Where such a margin increase can mean profits rise by 40%.

You used to be aware of analytics. Now you need to lead the charge to be analytics led, before your competitor ends up beating you so badly that you become an aquisition target – with your declining brand and your real estate becoming the only assets that remain. You are faced with a new imperative – how do I drive this organization to become analytics led, and in a way where I can “re-leapfrog” this new upstart competitor?

Becoming an analytics led company – a company that drives strategic advantage through analytics – is a journey that requires rethinking of how your entire business operates. It requires agility to be able to change tactics and strategies in response to data coming from how your customers interact with your products, retail locations, and your brand in general. You will not get there overnight. There are, however, traits that such companies share – traits that you can use as a marker to know whether you are at least on the way to becoming such a company.

Contextual Intellectual Capital is Valued

For purposes of this discussion, contextual intellectual capital is the sum of learning from analytics that has taken place and exists in the minds of people actively involved in shaping the business. For example, a tuned collaborative filtering model that forms the basis of a recommendation engine, paired with data scientists who know how to evolve the model, could be considered such capital. It is contextual, because it’s value is derived from properties unique to the company – the brand, the people, the culture, the customer base. Even if you “copied the code” to a different company, it’s value would deteriorate, because it is optimized for that particular brand.

Analytics led companies have a great deal of contextual intellectual capital. It is the models, the learning, and the people who know how to leverage and improve the model. It is the ability to create new models in response to changing business conditions – that build on what is learned from prior models whose value is derived not just from the math, but the context they come from.

Driven by Data, But Intuition Still Matters

One of the more surprising things you find in analytics led companies is that, while they are naturally driven by data, as you would expect them to be, they do not completely discount intuition. Intuition is a unique capability humans have for processing lots of complex information from diverse sources in parallel. This ability is something that humans excel at much more than computers do.

What does this mean? A human will have the context to intuitively know, based on data on whether a model has worked (or not) how a model may need to be tweaked. Intuition will give us a safe harbor to know when results from a model that is new should be called into question. For example, if a new model for managing up-sell recommendations is having great results well beyond what it should, intuition will tell us to look at the data closer so we can know whether some one time black swan style event is influencing the recommendation.

For example, during a cold snap, more people may buy face-masks that cover your entire face while they are buying new winter coats – but that does not imply that such face-masks should always be up-sold, as this condition only exists perhaps when the temperature goes below 10 degrees Celsius. Models running 100% unmanaged, if they are not including weather in the analysis, would not pick up this detail, where a model combined with intuition is much more powerful.

Optimized for Learning

Analytics led companies usually think quite a bit differently about what the source is for sustainable value. At first glance, a competitor may think it is the presence of a killer model that tells them what customers want to buy with incredible accuracy. However, as valuable as that is, in a competitive market, competitors will quickly figure out ways to reverse engineer and replicate the model. It is not a static model that really provides the value in an analytics led company, it is the organizational capability to learn from and quickly adjust the model to changing conditions.

Imagine you are a retailer who has been selling products in primarily western economies for the last ten years. As you move into emerging markets, how does the system that evaluates product mix change? Organizations that do not have agility to update and evolve models risk using inappropriate models for new conditions and situations. Companies that are optimized for learning can quickly adjust to new realities and change models to meet new business conditions.

Powered By Science

Is there any type of science that isn’t driven by data? Analytics led companies understand that data science is really *business science*. Such science has a process, and that process is the scientific method. You form hypotheses, you test them, and if they fail, you learn and move onto the next hypothesis. Data science as a term may be a fad, but the scientific method, and application thereof to business, is most certainly not.

Part of science, of course, is embracing failure of models, even if the ideas behind them come from a high ranking executive. Proving that models don’t work, in science, is just as important as proving that they do. In analytics led companies, while intuition matters (see above), when a hypothesis is falsified when under test, the outcome is accepted in favor of alternative hypotheses. The rank of the idea’s progenitor does not apply.

Practitioner Driven Tool Choice

In analytics led companies, the CIO does not buy analytics tools based on conversations that occur on a golf course. While tools are used, tool choice is vetted by the data science team.

Thankfully, most data scientists tend to be very pragmatic about tool choice. The tools of choice these days tend towards free or open source when possible – things like Hadoop, R, Python, and related libraries. Paid, proprietary tools have their place in certain situations, but the defaults tend to be tools that lower the cost of experimentation, so that too much capital does not get spent in yet to be unproven ideas. Nobody wants to invest seven figures in tooling for a model that may not work – for at some point, too much investment in an unproven model will create pressure to “make it work”, even if it turns out to be wildly wrong.

Analytics Driven Strategy

The most important trait of analytics led companies – above all – is that there is confidence that science properly applied to business has potential to deliver breakthrough value. The executives have not only seen it in competitors or upstarts encroaching on their turf, but they are prepared to compete by executing an analytics strategy that plays to their own strengths.

Does this mean that brick and mortar retailers all replicate the strategy of Amazon? Of course not. It means a contextual strategy that plays to the retailer’s strength. If it is a retailer that has strong location coverage in certain kinds of communities, the analytics strategy will consider that. If it is a retailer that has a brand that appeals to a different kind of consumer, it will consider that as well. They deeply understand that context matters – and that the unique combination of analytics model, people, corporate culture, and brand for the basis of a successful analytics strategy.

The Analytics Maturity Spectrum

There is no doubt “Big Data” has taken the tech world by storm. I have spent much of 2013 talking about analytics and data science with people all around the US, going to conferences like Strata, and immersing myself in this world for the last 12 months. Over the course of this journey, I have started to notice some patterns about how various people in various kinds of organizations understand and invest in analytics.

The analytics led company is a concept I will define here as a company that seeks to use analytics (predictive, prescriptive, or descriptive) as one of their chief competitive weapons. The canonical example is Amazon, whose use of analytics is part of the DNA of the company. However, there are other more traditional companies that are analytics led, such as Walmart, Proctor and Gamble, Kolhs, and dozens of others.

In companies that are analytics led, analytics capabilities are spread throughout the company. They are not siloed off to some group in IT that does “analytics stuff”. Such organizations, knowing that analytics has to be a core competency of the company, invest in people - data scientists, data engineers, data savvy analysts and developers, and free them to use whatever tools and techniques are required in order to generate business results.

The next category in the continuum are analytics aware companies. These organizations see the competitive threat. Many may be piloting technologies or starting to do some discovery work in small areas. They see the value, but have not yet integrated analytics into the DNA of the company and made analytics something that would be considered business as usual. These organizations often have a siloed group doing experimentation, and this siloed group often has ties, or is directly part of, the traditional IT department.

 

Image

Further down the spectrum are analytics ignorant companies. When a company simply does not see the value of predictive analytics, and rather seeks to gain competitive advantage through other means. Finally, at the other end of the spectrum, are analytics hostile companies. They may have sought to use analytics and failed – and then soured on the idea. They may have a technology hostile culture in general. Regardless of reason, they make very good targets for analytics led companies that seek to steal marketshare.

From Analytics Ignorant to Analytics Aware

Most industries, though not all, have had the emergence of at least one new competitor who has used analytics to achieve some sort of competitive advantage. Whether it is organizations like Progressive Insurance who use analytics of how you drive via it’s Snapshot tool to allow for better underwriting, or its one of the many online and offline retailers who are using analytics to understand or predict customer behavior, if you are the CEO of any industry where one of these upstarts have emerged, you have likely at least made your executive team aware of the threat.

That said, in industries that tend to be less competitive, due to either higher barriers for entry or presence of a monopoly – the urgency for analytics is much less. These types of companies, utilities, some telecoms, and a few others, means that even if the potential for additional profit is there, the lack of urgent need tends to move analytics to the back burner. It is only when a competitive threat from a related industry emerges (i.e. Google cutting into the Yellow Pages revenue) that such organizations move from Ignorant to Aware.

Moving From Analytics Aware to Analytics Led

In analytics led companies, the approach towards data science will generally be to build the capability in house. Leaders of such companies understand implicitly that analytics is deeply business relevant. They know that predicting customer behavior and anticipating customer needs – and most importantly – connecting those insights to the rest of the business – drives profit margin, customer loyalty, and numerous other outcomes that are core to mission.

Analytics aware companies, on the other hand, will tend to know they need those outcomes, but do not have the capability to achieve them. They often try to achieve analytics by purchasing technology – usually applications that have some analytics capability. While this approach can help the company at least get to level compared to their peers, they do not allow a company to exceed very far beyond their peers, as if one company can purchase a product that does analytics, so can competitors. There may be a short term advantage, but it isn’t sustainable.

Some analytics aware companies may seek to purchase the capability either through acquisition – buying a company that is analytics led and hoping that the new company unit will enable the entire organization to also be analytics led. While such moves have a better chance of providing competitive advantage than buying a product, it is risky, as this pattern tends to lead to siloed analytics capabilities within a business unit that used to be the old acquired company, unless the acquisition is properly integrated (which seldom happens).

The Opportunity at “Analytics Aware”

Data science will obviously be more valued in organizations that are analytics led. However, the most interesting opportunities for change tend to be in the organizations that are analytics aware. The analytics aware organization is the class where the value is understood, but a brand new culture about how to leverage data in new and interesting ways can be fostered. In analytics led organizations, especially ones that have been analytics led for quite some time, certain conventional wisdom may already be in place about what is possible and what isn’t. Often, such “wisdom” constrains the idea-space, causing the most ambitious ideas to sound too big, audacious, or disruptive to be viable investments.

On the other hand, analytics aware companies have experience spending large amounts of money on product and acquisitions. Such costs tend to dwarf what the cost of a competent data science team would be. One can take the budget that is spent on tools and acquisitions, redirect it towards an innovation lab that serves business line leaders, and get a far superior return on the investment.

What is the takeaway of all this? Do not despair if you are not analytics led…. yet. Use it as an opportunity to redefine the kind of analytics that your organization will use, an opportunity to chase more audacious ideas than than people with an abundance of conventional wisdom would ever consider.

On (not) Being Post-Technical

In ThoughtWorks, one of the most poignant insults one can throw at you is “so-and-so has gone post-technical”. This usually means one has entered the land of management, that place where you give back your brain in exchange for money (or prestige.. or nothing, as it turns out).

Lately, as I have taken on additional roles at ThoughtWorks, the temptation to go “post technical” has put itself forward. Imagine not having to think anymore. Imagine being able to just focus on “strategy” and “people issues”, without all that hard technology stuff.

I could take that path, but I’d rather not…

I remain technical. My day-to-day job may involve things like Statements of Work and such, and I do not write code 100% of the time, but I am making a decision to at least remain somewhat involved in the technical communities in which I have interest.

Of course, my time is more limited, given I have taken on some management responsibility lately. So I can’t pursue everything. And I do have to admit that with my reduced time, I am likely never to be the most “technical person” in any given group of TWers. In fact, given that TWers are all generally really good at their jobs, it would be utter arrogance for me to assume I could keep up with them when I only act in a technical role for 40% of my time. So my bar isn’t TWers – they will most likely all be more technical than I am. But it is remaining competent enough to understand at least 40% of what they talk about, and more importantly, remain excited about technology.

So what am I excited about these days, here is my own, personal, “tech radar” (no fancy graphics required):

  • Functional Languages and Big Data

Someday, the world will catch up to where the F#/Clojure people are now. I think the tie between FP and Big Data is strong, and given that is where much of the value will be created in the next 5 years with corporate IT spend, the use of FP will only increase.

  • IaaS (note, I don’t say cloud… too overloaded)

I got the cloud bug this year, and I will admit, I am a terminal case. I saw an app where someone deployed a load balancer with an http request. And not an http request that converts into an email that goes to a tech that puts a physical one on a rack. Infrastructure as code is changing this business. Imagine the ability to specify, in human readable code, an organization’s entire server configuration. And realize that configuration by executing the DSL it is written in. That day is approaching, fast. Imagine the possibilities – from everything to devops to disaster recovery.

Why don’t I say cloud? The term is so overloaded that it is meaningless. Anything that runs on the internet is putting “cloud” in front of it’s name, which is why I have stopped using the term and do everything I can to use more descriptive terms.

  • Lean Startup

Though not a technology, it is the first thing from a project management standpoint I have been truly excited about in years. At least since Agile, maybe more so. Why? It finally closes the loop, bringing in the entire scientific method into the business of software development. It seems so obvious now, it never ceases to surprise me that it took our industry 50 years to adopt it. Lean Startup, to me, is the application of the scientific method to how you run business. I recently did a webinar that nicely encapsulates how I feel about it in much more detail, but my general sense is that this builds on CD and gives organizations that embrace it a much more repeatable, sustainable path to successfully delivering business results with software.

The three things above are the tools I believe will create most of the value in corporate software over the next 5 years. And I fully intend to remain competent enough to discuss these topics with both technical and business audiences, even if I don’t write code every single day anymore. The trick, not being a full time software developer anymore, will be to:

  • Make sure I don’t stop doing some technical work – I still intend to pair program with the team when I can, as well as keep up with a selection of OSS projects I am involved with.
  • Continue to read new technical material – I am on planes a lot, should not be too hard. For example, I am learning Python now, despite that I don’t have a good reason to personally code in python.
  • Be aware – ultra-aware – that I am not the most technical person in the room. My team-mates will likely know more than me, and I will defer to them on technical arguments more often than not, especially if they have decent data on why a given technical decision needs to be one way or another.

Will this work? We will see. I am only in the starting stages of this journey – will be interesting to see the degree to which my technical skills atrophy from not being a full time developer anymore!

The Link Between Continuous Delivery and Agile

Now that Agile has passed the 10-year mark, many people are starting to wonder what the next step should be in the evolution of Agile. As we start to think about what’s next, it doesn’t hurt to think for a moment about how we got here in the first place. As the saying goes, it’s hard to know where you’re going if you don’t know where you’ve been!

So let’s turn back the clock through the mists of time in the years leading to the Agile Manifesto in 2001. Back when this movement started, many of the “reasons for Agile” just seemed very intuitive. People over process? Sure. Responding to change versus following a predefined plan? Common sense. On the surface, few people would disagree with the assertions made in the Agile Manifesto. But is that enough? Can you following the Manifesto—do it all by the book—and be guaranteed to create software that delivers economic benefit? No. By itself, Agile doesn’t lead to business value!

How Can By-the-Book-Agile Fail?

Let’s be clear. With its increased collaboration with the customer, more frequent releases, and increased engineering and testing discipline, Agile makes delivering value more likely. It’s certainly a vast improvement over multi-year “too big to fail” Waterfall software projects. But even if you do everything right, even if you have the best practitioners in the world building your product, you can still create a product that fails to make money.

Agile—and here we mean the kind that includes the right engineering practices, such as test-driven development (TDD), pairing, SOLID principles, automated acceptance testing, and continuous integration—will ensure that you create a product that works…in the lab, at least. However, despite your best efforts, you might build a very functional eCommerce site that tries to sell something that nobody really wants. Or you might build an internal application that can’t go beyond the lab because the operations people can’t support it in production. These issues—and many other things outside direct control of the team practicing Agile—can thwart even your best efforts.

Article continues here

Everybody’s Doing Agile–Why Can’t We?

Have you gone Agile? What are you doing this year to become Agile? We must become Agile in the next three months! These days, it is not unusual to hear about executives wanting to do an “Agile Transformation” on the entire company. Who knew that a bunch of relatively obscure techies would create a movement that is now the lingua franca of executives who are attempting to turn around companies! Agile really has “come a long way, baby.”

It’s amazing how things change in ten years. Once considered a methodology preferred by software developers because it “helped them avoid having to do status reports,” Agile has now gone beyond its original remit as a software development method. The word Agile, in many places, has become nearly synonymous with the word Good. As flattering this must be to the original founders, it probably means it would be wise to think, very candidly, whether Agile—as in Agile Software Development, or a broader Agile Enterprise—is really something that your company can achieve.

Read the rest of this article at InformIT here.

Welcome to the Revenge of The Nerds Economy

Many of you will remember Revenge of The Nerds, that fine classic movie where a bunch of, well, nerds take over the campus of Adams college by outsmarting and outwitting the jocks. For people who work in computers of a certain age and disposition – say, a late 30s geek from a western culture like myself who might have fit the nerd stereotype at various points in his early upbringing – the movie was somewhat influential. It told a story that, translated into economist-speak, equates to “intellectual capital may someday trump other kinds in terms of economic value creation.”

As it seems to have turned out, we are now in the Revenge of The Nerds economy. Despite 9%+ unemployment in the general economy, overall unemployment for software engineers is a tad below 5%. But this data, which is compelling enough, does not tell the entire story.

The bigger story is around what kinds of things are seeing investment. There is talk of another bubble right now in technical startups. If you are a technology based startup that has reached “Ramen Profitability”, you will almost certainly attract capital. Things are now even getting to the point where we are seeing companies that lack profits going to the IPO market (think Pandora and Groupon) – something that has been out of vogue since at least 2001. One could make the case that we will soon cross the line where it is easier to get a startup funded than it is to get a jumbo mortgage.

If you work in tech, there is a good chance you are feeling this, at least if you are currently employed and working for an employer that has some level of visibility. If you work for Google, Facebook, or some other high tech company, you likely do not have to work that hard to get a new job offer. Notwithstanding the cruel irony that people who are unemployed are often being systemically discriminated against, the job market for really good, currently employed software developers is as robust has it has been in 10 years.

So if the nerds are all right, mostly, what about the jocks? What occupations did they end up in? While some of them may have made it to the NFL as professional football players, most others end up in spilling into the general job market. While the stereotype is that jocks end up in menial jobs, construction, or manufacturing; research being hard to find, my own experience of knowing several such folk points to careers tending to be sales, low-end finance (think mortgages), real estate, and personal training. Given, a sample size of a couple dozen doesn’t really prove anything. However, if one did extrapolate, one could come to a conjecture that while “jocks” for lack of a better word, do not do worse then average now, the nerd/jock investment and employment dynamic has changed.

Why the change? Now that simply taking big leveraged risks with a big pile of money isn’t in fashion (i.e., as it was before the global financial crisis), you need advantages from superior intellectual capital in order to sustain a higher than mean return on investment. Why not in fashion? From 2003-2008, it was accepted that financial engineering was the way to riches. If you only structured your collateralized debt obligation in the correct way, you could invest at 40x leverage and still retain a AAA rating on your debt. Financial engineering gave you higher profits under such a regime than traditional “engineering engineering” could provide. So money flowed into CDS structures and away from the nerdy parts of the economy that invents things.

So now we find ourselves in an economy where capital flocks to things like Pandora, Groupon, Facebook, Linkedin, and other things that, at their core, have interesting algorithms inside them. And we have a situation where if you are a developer capable of writing an interesting and valuable algorithm – or helping a company scale out a system that leverages one of these inventions, you are in high demand.

Good thing for the nerds. What this means for everyone else remains to be seen.

Upper Management Support the Key to Success? No.

You have heard this one before.  They key to project success is “Upper Management Support”.  I hear the phrase so much it is pretty much a cliche, right up there with “be aligned with the business”.  It ranks right up there with “brush your teeth in the morning” and “exercise if you want to be healthy”.

So I have a humble request.  First of all, I think we can just start assuming that if you have a goal that requires more than, say, the amount of money you spend annually on copiers in a small office annually, you are going to need upper management support.  Especially if it is going to change the business.  If you are engaging on a “change the company for the better initiative”, getting upper management support is basically the first, and one of the easier, steps.

  • The real hard stuff isn’t upper management, it’s middle management.  Upper management does not usually have their empires or jobs threatened by a significant IT initiative.  Middle management, on the other hand, often does.
  • The day to day impact of a large programme on the lives of upper management is comparatively low.  Most of the time, they can get on with their normal duties and continue to operate at the “strategic” level rather than hands on.  Middle management, on the other hand, often has to expend significant time, energy, and political capital in the programme in order to make sure it works.
  • The numbers of people in upper management are lower, well, because they are upper management.  You can more easily get a small number of people on the same page.  Middle management numbers are much higher, and making the politics of middle management engagement much more difficult.
  • Various groups in middle management that are impacted unevenly create opportunities for internecine politics to enter the scene.  Even if you get middle management engagement, keeping it is a much more difficult chore.

There are all sorts of things you need in order to make a large programme of transformational work successful.  Upper management support is just the “table stakes” – the ante for getting to the table.  Getting support of middle management, and getting past the many roadblocks they can put in your way, is much harder, frequently underestimated, and frankly, in my experience, much more of a project success factor.

F# Based Discriminated Union/Structural Similarity

Imagine you have a need to take one type, which may or may not be a discriminated union, and see if it “fits” inside of another type.  A typical case might be whether one discriminated union case would be a possible case for a different discriminated union.  That is, could the structure of type A fit into the structure of type B.  For lack of a better word, I am calling this “structural similarity”.

Lets start with some test cases:

module UnionTypeStructuralComparisonTest
open StructuralTypeSimilarity
open NUnit.Framework

type FooBar =
 | Salami of int
 | Foo of int * int
 | Bar of string

type FizzBuz =
 | Toast of int
 | Zap of int * int
 | Bang of string

type BigOption =
 | Crap of int * int
 | Bang of string
 | Kaboom of decimal

type Compound =
 | Frazzle of FizzBuz * FooBar
 | Crapola of double

[<TestFixture>]
type PersonalInsultTestCase() =

 [<Test>]
 member this.BangCanGoInFooBar() =
 let bang = Bang("I like cheese")
 Assert.IsTrue(bang =~= typeof<FizzBuz>)
 Assert.IsTrue(bang =~= typeof<FooBar>)
 Assert.IsTrue(bang =~= typeof<BigOption>)

 [<Test>]
 member this.KaboomDecimalDoesNotFitInFizzBuz() =
 let kaboom = Kaboom(45m)
 Assert.IsFalse(kaboom =~= typeof<FizzBuz>)

 [<Test>]
 member this.SomeStringCanBeFooBar() =
 let someString = "I like beer"
 Assert.IsTrue(someString =~= typeof<FooBar>)

 [<Test>]
 member this.SomeFoobarCanBeString() =
 let someFoobar = Bar("I like beer")
 Assert.IsTrue(someFoobar =~= typeof<string>)

 [<Test>]
 member this.SomeFoobarTypeCanBeString() =
 Assert.IsTrue(typeof<FooBar> =~= typeof<string>)

 [<Test>]
 member this.CompoundUnionTest() =
 let someCompound = Frazzle(Toast(4),Salami(2))
 Assert.IsTrue(someCompound =~= typeof<FooBar>)

To make this work, we are going to need to implement our =~= operator, and then do some FSharp type-fu in order to compare the structure:

module StructuralTypeSimilarity

open System
open Microsoft.FSharp.Reflection
open NLPParserCore

let isACase (testUnionType:Type) =
 testUnionType
 |> FSharpType.GetUnionCases
 |> Array.exists(fun u -> u.Name = testUnionType.Name)
let caseToTuple (case:UnionCaseInfo) =
 let fields = case.GetFields()
 if fields.Length > 1 then
 fields
 |> Array.map( fun pi -> pi.PropertyType )
 |> FSharpType.MakeTupleType
 else
 fields.[0].PropertyType 

let rec UnionTypeSourceSimilarToTargetSimpleType (testUnionType:Type) (targetType:Type) =
 if (testUnionType |> FSharpType.IsUnion)
   && (not (targetType |> FSharpType.IsUnion)) then
 if testUnionType |> isACase then
 let unionType = testUnionType
  |> FSharpType.GetUnionCases
  |> Array.find(fun u -> u.Name = testUnionType.Name)
 let myCaseType = caseToTuple unionType
 myCaseType =~= targetType
 else
 testUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun case -> (case |> caseToTuple) =~= targetType )
 |> Array.exists( fun result -> result )
 else
 raise( new InvalidOperationException() )

and UnionTypeSourceSimilarToUnionTypeTarget (testUnionType:Type) (targetUnionType:Type) =
 if (testUnionType |> FSharpType.IsUnion)
  && (targetUnionType |> FSharpType.IsUnion) then
 if testUnionType |> isACase then
 targetUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun u -> u |> caseToTuple )
 |> Array.map( fun targetTuple -> testUnionType =~= targetTuple )
 |> Array.exists( fun result -> result )
 else
 testUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun case -> (case |> caseToTuple) =~= targetUnionType )
 |> Array.exists( fun result -> result )
 else
 raise( new InvalidOperationException() )

and SimpleTypeSourceSimilarToUnionTypeTarget (testSimpleType:Type) (targetUnionType:Type) =
 if (not (testSimpleType |> FSharpType.IsUnion))
  && (targetUnionType |> FSharpType.IsUnion) then
 targetUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun u -> u |> caseToTuple )
 |> Array.map( fun targetTuple -> testSimpleType =~= targetTuple )
 |> Array.exists( fun result -> result )
 else
 raise( new InvalidOperationException() )

and SimpleTypeSourceSimilarToSimpleTypeTarget (testSimpleType:Type) (targetSimpleType:Type) =
 if (testSimpleType |> FSharpType.IsTuple) && (targetSimpleType |> FSharpType.IsTuple) then
 let testTupleTypes = testSimpleType |> FSharpType.GetTupleElements
 let targetTupleTypes = targetSimpleType |> FSharpType.GetTupleElements
 if testTupleTypes.Length = targetTupleTypes.Length then
 let matches = Array.zip testTupleTypes targetTupleTypes
 |> Array.map( fun(test,target) -> test =~= target )
 not (matches |> Array.exists( fun result -> not result ))
 else
 false
 else
 testSimpleType = targetSimpleType

and (=~=) (testObject:obj) (targetType:Type) =
 let objIsType (o:obj) =
 match o with
 | :? Type -> true
 | _ -> false

 let resolveToType (o:obj) =
 match objIsType o with
 | true -> o :?> Type
 | false -> o.GetType()
 let testObjectIsAType = testObject |> objIsType
 let testObjectTypeIsUnion =
 match testObjectIsAType with
 | true -> testObject |> resolveToType |> FSharpType.IsUnion
 | false -> false
 let targetTypeIsAUnion = targetType |> FSharpType.IsUnion 

 let resolvedType = testObject |> resolveToType

 match testObjectIsAType,testObjectTypeIsUnion,targetTypeIsAUnion with
 | false, _, _ -> resolvedType =~= targetType
 | true,true,false -> UnionTypeSourceSimilarToTargetSimpleType resolvedType targetType
 | true,false,false -> SimpleTypeSourceSimilarToSimpleTypeTarget resolvedType targetType
 | true,true,true -> UnionTypeSourceSimilarToUnionTypeTarget resolvedType targetType
 | true,false,true -> SimpleTypeSourceSimilarToUnionTypeTarget resolvedType targetType

Getting this to work seemed harder than it should.  While my tests pass, I am sure there are both cases I have not yet covered, and probably some simpler ways I could accomplish some of the same goals.

While this is a work in progress, if anyone has any thoughts for simpler ways to do something like this, I am all ears.

Just Make Me Think! The Best Technologies Force Hard Choices.

In thinking about what is so compelling about certain new technologies that have emerged in recent years, a common theme is starting to emerge.  The best technologies don’t just do something useful, but they make the user think about the right things that lead to better designs and more robust software.  Lets start by thinking about some of the most compelling technologies or techniques that have had a lot of buzz in the last couple years:

Dependency Injection

Dependency injection is a great technique for being able to manage coupling.  At least it is in practice.  But there is nothing that would stop you from using dependency injection to, say, create a giant class and inject thirtyteen-hundred dependencies in it and giving yourself a maintenance nightmare.

What is important about dependency injection, is that it makes you think about dependencies. When I am writing code, I want creating a dependency from one class to another to hurt.  Not a lot, but enough that it makes me put an entry in a file somewhere – be it an xml config, or a module, or something.  A DI tool that wires everything up for me without me having to explicitly think about it each time – well, that is to me like an HR management tool that does not have an “are you sure” prompt on the “fire employee” button.

Continuous Integration

Continuous Integration tools do some nifty things, one of the most important being providing some visibility to the state of the code.  When properly implemented, the benefits are pretty staggering.  However, in my experience, one of the most important benefits is that Continuous Integration forces you to think about how to automate the deployment process. You can’t continuously integrate if some person has to flip the bozo bit in order for the build to work.  CI promotes a model that makes tools that require human intervention to install seem obsolete.  I can’t see this as a bad thing.

Functional Programming

Most anyone who knows me in a professional context knows I am a big fan of functional programming.  I have grown to like the syntax and expressibility of languages like F#, and there are a great many reasons why the language is important.  But to me, the most striking is that functional languages make you think long and hard about state.  You can do state in F# (through the mutable keyword) – even in pure functional programming languages like Haskell if you implement a state monad.  But the important thing here is that you have to do significant work to create state in these languages.  That leads to choices about state that tend to be more mindful than in languages where state is the default.

I could talk through more examples, but I think you get the picture.  The opposite tends to hold true as well – my main issue with a technology like ASP.NET Webforms is that it makes certain things easy (ViewState, notably) that it should not, in order to help you avoid having to think about the fact that you are running an application over a stateless medium.  When you are considering a new technology that is emerging – don’t think features, think “What choices is this technology forcing me to make?”

Why IT Matters More Than Ever

In 2003, Harvard Business Review published Nick Carr’s seminal essay, “IT Doesn’t Matter.” I remember that month well. The previous years of the PC boom, followed by the dotcom boom, had seen a tidal wave of money spent on technology. Much money was wasted on heavy investment in systems that either sat unused on a shelf, or ultimately were scrapped. To top it all off, the big “emergency” of the time, the millennium bug, turned out not to be as bad as everyone had feared. The time was rife for someone to declare the strategic irrelevancy of technology, and Mr. Carr stepped in and made the case. Because many executives desperately wanted to reduce technology spending at the time (in the aftermath of all that gluttony), reading Carr’s article was like receiving manna from heaven.

As a technology practitioner myself, however, it should surprise no one that I believe Mr. Carr to be wrong. Regardless of any biases I may have, the reality is that his argument contains several holes that have become ever more glaring with the passage of time. My intent with this article is to shine a light on what’s wrong with the “IT doesn’t matter” argument. I’ll even go further: I’d like to demonstrate why, now more than ever, investing—not just in technology, but in the intersection of technology and people—is the most important action that a company or organization can take.

The Company That Couldn’t Run a Second Shift

In my years as a technology consultant, I’ve certainly seen what happens when you don’t invest in technology. One client I vividly remember—we’ll call it Company X—had quite a conundrum. An amalgamation of nine different manufacturing organizations built up over time, Company X spent very conservatively on technology. When making an acquisition, Company X would do as little as possible on integration; for example, only enough to get the accounting systems and the order-entry systems sending orders to a central mainframe.

Over time, this management behavior at Company X resulted in a “Rube Goldberg” system requiring the work of hordes of COBOL programmers just to keep running. Overnight order processing required more than 200 manual steps. The maintenance cost of this Frankenstein’s monster of a codebase included at least 40 full-time COBOL programmers, a couple of dozen system operators, and who knows how much management hierarchy on top of all that. Company X was spending an estimated $15 million annually just to keep the system at its current level of functionality.

Unfortunately, that $15 million wasn’t even the most significant problem. When demand increased, Company X decided to run a second shift. The issue was that the system literally could not process orders in greater than about a 12-hour window. Moving to a 16-hour window, and eventually to a round-the-clock business, would require either radical changes to the old system or building an entirely new system—and it would have to match the quirks of the old system, in order to maintain compatibility with the nine other satellite systems!

Business analysts estimated that adding a second shift would increase gross margin in this low-margin business by around 3%, while increasing top-line revenue by over 20%. Moving to round-the-clock processing was also a precursor to being able to sell into new global markets, which would have increased top-line revenue even further.

Sadly, none of these happy improvements could come to pass for Company X.

The problems at this company were many, of which technology was merely one aspect. The deeper issue was that the operators and programmers who understood that mess of a codebase had a vested interest in keeping the current technology set running. But even if all those people were replaced, technical debt in Company X had built up over a long period of time, to the point that the company would need to invest around 2–3 times its annual profit in order to get out from under the load of technical debt.

In this culture of hubris, fear, and inertia, any new technology initiative to pay off the technical debt would almost certainly be killed. It was literally a recipe for company bankruptcy. When competitors are blowing you out of the water with 3% higher margins and 20% higher top-line revenue, taking that increased profitability and investing it into further productivity-enhancing technologies, it’s hard to see why “IT doesn’t matter.” If you’re a CEO in a company that can’t compete because of technical debt, you almost certainly will understand just how much IT does matter.

The rest of this article is available at Pearson Education’s InformIT website here.

Follow

Get every new post delivered to your Inbox.

Join 29 other followers