What is involved in understanding a problem domain so well that you not only deliver a software product, but you can actually re-imagine the entire domain under the light of virtuality and all its categories - if necessary?
In this series of writings I want to talk a bit more philosophically about development. I say this at the start because I know the vast majority of programmers do not care for a deep understanding on how to model a business domain, preferring to trust that entirely for other roles in a company structure. If you happen to enjoy a more philosophical take on software development, I hope you'll feel like in a fireside casual chat. Plus, I'd love to know more about your ideas (seriously).
If I can quickly resume all I want to talk about (forever): I think programmers take the task of designing models of reality (a.k.a "business model") in a very disinterested way. We loosely classify nouns from user stories and methodise them with verbs. We have amazing documents (books, blog posts, etc.) on domain modelling, but the ones I had access to were very shallow (or didn't touch at all) on reflections about whether or not those models match the concrete domain. The most daring ones asked you to reflect on whether or not that belongs to the core context, or maybe it was on the wrong context. And not really whether or not it is modelled correctly. My readings were not at all exhaustive, and if you know some texts that touch on this more deeply, I would love to know about them. In the meantime, I will do some free(ish)-associations here around the topic.
I've been a developer in a way or another for the last 20 years or so. I started because I am very interested in programming and all we can do with it; this newfound knowledge continues to amaze me to no end. It has been my leisure, my graduation, and it was only obvious to work with it - something I was good at and wanted to keep improving and doing. I don't regret it for a second, but I must say: I was completely wrong about what does it mean to be a professional developer. Or a professional anything, for that matter.
I've been a Fool (amongst others, for sure) - and plan on continuing to be, if my current understandings of what does it mean to sell your workforce as a developer means. But where before there was frustration and confusion, now I see a gradual shift into a light-hearted witnessing of the way things are in our particular historical moment. Which opens a bit more space for reflection.
You see, building software professionally has always been frustrating. Things mysteriously go wrong, and is very often not clear why. And, please note: I don't mean to say there wasn't someone there with an explanation and a plan so concrete (I'll avoid the word "pragmatic" for the time being; it is excuse for so much self-deceiving attitudes that we might as well give it some focus later on) that it seemed to ridicule the necessity of thinking deeper just by being stated. They are always there, ready for action. Action on top of action; each time, a workaround, a new abstraction.
I thought what I was getting into was this: I'd receive problems from the world and I had to model them in software. That happens to be exactly what I enjoy doing. You go to a store, you see the way they work and you think "I could make an app to model this flow". You observe the dynamics of people in their work and you extract the knowledge of that process and translate that to a code: you have just taken a snapshot of human life doing something that interests it and saved it into a language that machines can understand. Algorithms are descriptions of human work in a very "precise" way.
Or at least, that's what I think it should be.
But that's not why we're being hired by companies, is it? Is this their goal? To correctly grasp human action and provide means of improving and progressing our activities by means of understanding it and enhancing it, equipped with said understanding? At first, it may seem it is. But if you look at it just right, you'll find barriers to correctly understanding the world. Namely: the profit problem. They are not fundamentally interested in getting anything right or improving anything necessarily; they'll do it to the extent that it is profitable. Profit is the driving goal; not understanding or progress.
(And a quick note: I'm not being moralistic here. This is not a problem of individuals that lack a more acceptable moral or ethical behaviour. The aim of business is one and one only: to profit. Everything else it pledges in their product or service is only listed there insofar as profit is achieved.)
I was consumed by one thought: if I understand it, I can then guide the team towards a better modelling. If I find in any of them resistance to it, it means the Model is wrong: "it has to be fluid! Does a tree have to ponder about where is the right place for the next branch? Does water flow to the wrong place?", I thought.
It's a new day for the Fool today. So he kicked off with old habits of complaining and protesting, and started to draw a plan on how to improve my understanding of Models. He wants a big ol' slice of heaven, but he can't see past the pie.
Watch me try.
(In the next post, the Fool finds the Alchemist, who claims to have a cure for all these disturbances: a sip on a cocktail of agile, sprint, scrum, product people - and other ingredients - that will solve all the Fool's problems in coping with the sad state we're in)
Top comments (0)