Grok The Problem Domain

Grok is a word that everyone here seems to think they know the meaning of. In a number of years as a teacher and a number of years in Universities and research establishments and in 42 years of life, the number of people I have met with a natural desire to grok things and the mental persistence to achieve this aim can be counted on the left hand of a carpenter. (They usually have less than 5 fingers.)

Thus, Grok the problem Domain is something that most people need significant encouragement to achieve. It does not just happen.

Sorry if I have just insulted you, and if I have then I am sorrier than you can imagine because if I have insulted the majority of you then I have finally found my home.

When refactored, this page will be less confrontational on this issue, but in the time I can afford at the moment, being blunt is the only way to not be misunderstood.

-- AlanChristiansen

BigDesignUpFront has a benefit: The coders now all GTPD. This is better than not.

BigDesignUpFront has a problem: The people qualified & empowered to analyze the problem space & prioritize features should not be the ones empowered to code them. To put this bleakly & confrontationally, programmers are superior people and should not be called upon to do menial things that mere knowledge workers are trained to do. So let them GTPD too, and they will deliver a perfectly prioritized stream of UserStories for you.

-- PCP

Are you saying you want users to write user stories, and programmers to write programs?

Call me a radical...

Generaly, if a programmer needs to GTPD, it means the project is not well designed, which XP sees as a good thing.

I often have no desire to GrokTheProblemDomain at work. Actually, it's worse than that, some workplaces led me to a significant desire to not fully GrokTheProblemDomain (well, certain parts of it). This aversion is usually due to my always ending up as the indispensable programmer, which is a position I don't enjoy, and any further knowledge just makes the problem worse.

Aside from the cases that I'm punished for the knowledge, I'd say that I have a natural desire to grok things, and often even have the mental persistence to achieve it. For instance, it really bugs me that I don't grok my car. I'd go buy a book and start tinkering to fix this problem, but I've got a new car that was designed to not be understood by anyone without the special terminal to plug into its little computer. I've actually taken to riding my bike, and I'm working towards getting rid of my car. I grok my bike.

I've met numerous people that have that natural desire too, but I have to agree, they're few and far between.

The JargonFile entry for "grok" reads, "1. To understand, usually in a global sense. Connotes intimate and exhaustive knowledge.... 2. Used of programs, may connote merely sufficient understanding." HaveSufficientUnderstandingOfProblemDomain doesn't sound like much of a principle....

The nature of the evolution of thought during a scientific evaluation tends to be one of progressive refinement with occasional radical steps. The problem with HaveSufficientUnderstandingOfProblemDomain is the ability of people to misunderstand "sufficient." Grok is close to what I mean but probably not actually what I mean.

I think that what I mean is that as you progressively refine your ideas and consider the possible models that still provide a sufficiently accurate model of the reality that your software will have to deal with, there can be observed at some level of abstraction a certain sameness about it all. This sameness is often expressible as a collection of well-definable objects (ala OO) or algorithms (ala STL) that are common to all of them. It is now a low risk exercise to build these things.

In building them, there is both (?) sufficient time elapsed for the rest of the design to sort itself out. This sorting itself out is a euphemism for the unconscious process that happens while I am asleep, driving, or even working on other things.

This step is distinctly unlike XP in that in this phase I am not addressing any user needs and produce nothing directly useful to the customer. This is a risk. At the end of the stick where I have worked in recent years (R&D) tackling the less well defined parts of the problem to get something functional immediately is actually in my view riskier. What do I mean by R&D? At times we have faced problems where the initial definition of the problem could be characterized as follows.

Problem: We have lots of data (poorly described error prone data) that seems like it should contain information that would be useful to diagnose faults in things. Can you help?
Method: Start trying to Grok things. Build what you think you Grok, it helps clarify that you do and achieve the level of abstraction needed to solve the problem in terms of those bits.
: When you finally see where you are going, design a system and build path that provides incremental testable construction to reach the other end. Go back to your compass, the users and verify your system when you have concrete examples to show them.

I wonder if this has the makings of a pattern that would be called "YouCantGetThereFromHere"?

WARNING Note: while I believe what I say above, I also believe strictly in WorstThingsFirst, and thus muddling around building the easy bits you already understand is strictly to be used only as a way to work out how to build WorstThingsFirst and to solve the problem of CantGetThereFromHere which is in some sense the worst possible thing.

SEE ALSO: AtsSpikeSolution for other things that can be done first that do not match the strict paradigm of building functionality one bit at a time and progressively adding functionality.

I disagree with your initial sentiment. Yes, a lot of people have no natural desire to grok things but a lot of people do. Maybe 10% of programmers have this desire. I simply cannot understand the other 90% ;) But many programmers simply have the natural desire to get it out the door!

12 years to GrokTheProblemDomain is a long time. Unfortunately, it's probably true. Which implies, surely, that you can never really GrokTheProblemDomain, because problem domains change way faster than every 12 years.

Did I miss an anecdote about the 12 years? I worked at a company you've heard of (it's in the Dow Jones Industrial Average and it makes things that fly), where another programmer had spent more than a decade on a project. At the end of that time, he didn't grok the project domain, but then he was also incompetent at programming so I guess it averaged out.

Given your tight requirements, you ask the impossible ... don't you?

[There is also the natural human ability to say, "I grok the problem; you don't" ... are you sure you are not falling into this trap? Being blunt is one thing; being deliberately blunt because it is the only way to "educate" people is something else ... but I digress.]

-- EddieEdwards

See also: ModelFirst

Perhaps part of the problem is that "the spirit is willing but the <process> is <not well defined>". I certainly wish to fully Grok the problem domains I purport to have solutions for, and yet descriptions on how to do this methodically and efficiently are not easy to come by (at least in this web-realm). Were one to aspire to Grok, and to do so to the exclusion of proposing any elements of a solution, what process would you suggest? I ask because many of the discussions I have seen about the problem domain seem to speak more to BusinessModeling (Sue passes form X-12 to black-ops accounting) rather than real problems (Sue forgets to hand over the X-12 form most weeks and the Aliens are starting to get hungry).

-- JamesWhite

Drink Deeply

I suspect this annecdote ree Sue and Form X-12 epitomises Grok the Problem Domain. Sue passes form X-12 to black-ops accounting, is a statment of supposed fact. Sue forgets to hand over the X-12 form most weeks and the Aliens are starting to get hungry. I also a statement of facts and describes a problem but I would be starting to grok things if I broke this down in afundamental way to universal constants that I can expect in all users stories. There are Forms. With ID's that are unique and meningful. These forms change owners/locations states, and occur on a timely basis. Their arrival or otherwise has consequences that we wish to manage. I see objects, this problem domain is normal business like and simple. I have a set of fully functioning organisms with genomes proteomes and expression levels I have various medical conditions that categoriese them. I need to find various measurable parameters that can be measured that allow me to make predictions about a subjects categorisation. How? Much groking to be done.

CategoryAddress