First, A Story

Years ago I managed an ETL Team at Unisys. When I became manager, we had about 24 team members. The team grew to 40 members.

I was initially hired to build an SSIS framework to replace functionality built-in to a competing product. The maintenance cost for the competing product was $1,000,000USD per year, and the plan was to install the product at two sites for 10 years each. That’s $20,000,000USD if you’re playing along at home.

I wish I’d known this at the interview… but I digress…

I built the first version of the framework and shared it with the team. Most team members were experienced data engineers who had used more than one vendor’s product, and they immediately grasped the usefulness of the solution. The junior members of the team were being mentored by the more experienced members, so junior team members were quickly made aware of the benefits of the framework to a common problem taming enterprise data engineering.

There’s Always One…

There was this one guy who reverse-engineered the solution on his laptop. I could tell he was reverse-engineering the framework because he asked the occasional question about why the code was designed the way it was. You don’t think about these sorts of questions unless you are deep in the ones and zeroes and thinking about why things work the way that they do.

While this particular data engineer was engaged in his quest to comprehend the SSIS framework, he was most thorough. Later an architecture team organically grew from our shared team experiences. This team shepherded the framework (and still does). These were the days when deploying SSIS was… “handsy” (props to Mike Rogers).

This same reverse-engineering data engineer had previous experience – and passion – for automating deployments.

He automated a method for deploying SSIS projects.
And he used the SSIS framework as his deployment engine.

I did not consider using the framework to support deployment. And yet, here it was. The data engineer went on to automate a method for generating most of the metadata his solution required. He then created a Visual Studio plugin and labeled the button to execute said plugin using the Microsoft “smiley” icon:

This happened because the SSIS framework was (and is) designed to be an elegant solution.

Regarding Personas

I had a Blink moment when I first learned about personas. Oddly enough, I first saw personas during a presentation from the Microsoft SSIS Team. I cannot recall whether the presentation was public or not, it was back in my MVP days (I am no longer an MVP).

Something inside me recoiled. I may have physically shuddered. It was – as described in the book Blink by Malcolm Gladwell – an  almost-instant “something is not right” reaction that I was unable to articulate. I now believe I know at least some of the reason for my reaction, and I welcome your thoughts, comments, and fisticuffs.

In itself, elegant software is thing that supports its users, but elegant software is designed to address an impersonal business problem as a first principle.

If you read that and recoiled – perhaps you had a blink moment – I get it. I’ll elaborate.

AI is Software

Over at our podcast, Data Driven, Frank La Vigne (LinkedIn)and I are honored to speak with many professionals working with AI, Machine Learning, and Data Engineering. AI is software. I can hear some of you thinking, “Well duh, Andy.” You are not wrong to think that.

One thing I occasionally bring up in interviews is: “Why would anyone want a machine to think like a person?” People and machines are different, I (data-) philosophize. Machines should “think” – if you want to call what machines do “thinking” – like machines, and people should think like people. The goal should be building (machine) software that facilitates and complements human thinking and effort. It turns out the most widely-used AI applications do that exact thing. They are accelerators that automate the automate-able, freeing human mental bandwidth for other things… hopefully more useful things; at least things more suited for humans to perform.

Machine-empathetic

I abuse consider publication to be a license to spell and so I regularly invent words and phrases. I use the term machine-empathetic to describe an ability to sort tasks into two categories:

1. Machine-friendly (machine-empathetic) – tasks best suited for machine automation
2. Human-friendly (human-empathetic)- task best suited for performance by humans

I consider machine-friendly and human-friendly separate and distinct domains.

Applied to Software

I’ve never liked personas because – in my opinion – they muddy the waters between domains. Build the software to automate machine-automate-able stuff, to think like machines think. You don’t need to make up a persona. Making up a persona might lead a developer away from useful functionality in order to fit the software into a “persona-driven box” – thinking like a person – some place the software may not fit; or fit well.

Conclusion

I could be wrong. I’m certain I haven’t completely articulated what I mean, at least not yet.
As I stated earlier, I welcome your thoughts.

Peace.