Programmer as Modeler
Programmer as Modeler
A vision for programmers at the heart of the business
One of the reasons I like consulting is that I am treated as a partner and collaborator, not as an untouchable engineer. At some companies where I have been employed, engineers were treated as expensive idiot savants who should never get near a customer. Just give them work to do but don’t trust their opinions. It’s a stereotype that we often live into.
However, I have found that if I break through that stereotype and can talk shop with the business folks, I can gain their favor. They start to trust that I do have a business sense and can see past the engineering tasks that other programmers content themselves with. I have gained influence with several of my clients and employers. Consulting is better than employment for this because as a consultant, you are starting the relationship as peers.
Bridging the business direction with engineering can give you some great insights. One thing that I pride myself on is domain modeling. I find that programmers often understand the domain better than anyone else in the company (though they can also be obtuse). They understand it better than the sales people, better than the CEO, and better than marketing. They see corner cases others don’t.
Let me give you an excerpt of a story from Kenny Tilton (a boon to the Clojure community, and god bless him) (emphasis mine):
Tilton was contracted to automate accounting transactions for a bank in Canada. He read the well-written spec, saw the model, and wrote the code. After handling the initial bugs, everything was smooth sailing. Until . . .
Then well into the test when the IRs [Incident Responses, how testers log bugs] had slowed to a drip I got a call from Canada. I had blown a transaction. Lemme see it... OK, sorry, that is what the spec says. No, these have to be handled this way, the debit goes over here and credit goes over there when X is Y.
Now as usually happens in these deals I still did not know anything about accounting but some of the words had taken on glimmers of meaning and I asked, But isn't this the same as whatever? And then I threw around some terms and said that from my poor understanding what they were suggesting seemed wrong. Nope, that is how we do it. OK. Bye. Bye.
…
"Marcia, Kenny. My code does not want to do what you want, eh? Your spec is pretty clear on all these things and just from the sound of it it seems the way I am handling it now is right anyway. I can kludge things up to get what you want, but I will hate myself in the morning."
Marcia said she would talk to Bernie, her VP, and get back to me. She did not do so for so long that I forgot about it and to her credit she did not even have to make the call but she did.
"Kenny, Marcia. I spoke to Bernie. The way you are handling that transaction will be OK. We can live with the way you are doing it."
Tilton's Lemma lived on. Somehow clean design (starting I freely acknowledge with a great spec) had flushed out a faulty business practice. The users had indeed offered an RFE discontinuous with all their other stated requirements, but it turned out to be such an egregious error that they agreed to fix it. (To their credit again!)
Why does this war story give me goose bumps? Yes, I need to get out more. And OK, maybe it is not such a big deal. The careful architecture forced on us by having to program these godawful machines makes it easy for programmers to see inconsistencies the business experts miss.
Let me excerpt those two statements again:
Somehow clean design had flushed out a faulty business practice.
and
The careful architecture forced on us by having to program these godawful machines makes it easy for programmers to see inconsistencies the business experts miss.
This idea is reminiscent of a talk by Gerald Sussman I had the pleasure of attending live. In the talk, Sussman shows how programming can clarify the poor notation mathematicians and physicists use. As I watched that talk, I felt like we had a superpower. By learning a domain then encoding it in a programming language, we could find the deeper model that existed behind the notation.
I’ve had this experience before. At Scrive, I was unsatisfied with our model of contracts after learning about the legal history of contracts and their uses. Storing Person A signed Contract X as a rows in the database was just not going to cut it, legally. I stayed up late for a few days drafting a proposal for a model of contracts that was drastically different from what we or any competitor had. The PDF of a contract became an evidence gathering vehicle.
Just a brief explanation: If an agreement is disputed and goes to court, any contracts are used as evidence. But evidence of what? Here are some things that might be argued:
That’s not the contract I signed. Then why are your fingerprints on it?
That page was added later. Then why did you initial it?
I was compelled to sign it without my agreement. What does the witness say?
Because ours was digital and often signed remotely, we had other issues:
It wasn’t me who signed that. It was sent to bob@company.com, is that not your email? And it was accessed by this IP address which was assigned to you at the time.
I didn’t understand it was a contract. Here is a screenshot from your browser of the UI showing the button labeled “Sign here” and a message saying “This is a legally binding contract.”
I didn’t read it. You spent 27 minutes on this page.
The proposal I wrote incorporated the technical model of “contract as evidence vehicle,” as well as the business case for it (our PDFs are still useful even if the business closes and the database is lost). After refining it with the CEO, that proposal was the seed of marketing (including the slogan “better than paper”), sales, business strategy, and engineering efforts. This wasn’t just catching a bug in a business process. This was finding a deep well of competitive advantage. I talk more about this on my office hours last week.
There’s a related failure mode that I’ve talked about before. Sometimes engineering gets so mired in the programming details that they rarely think about the domain.
Consulting
If you’d like to talk about how I can help your company discover its core abstraction to gain competitive advantage, please reply to this email.
Office hours
I’ve got office hours coming up this Thursday. Please come and ask your questions. Live stream link. Zoom link in the description.