Sometimes when you talk about application software, you find that the technicians and the customer are agreeing but don’t realize it. This happens when each party says something that is essentially the same semantically, but they don’t derive the same meaning from it. I have been in that situation many times, because of misunderstandings of the domain semantics or ambiguities in domain semantics.
Other times you have the opposite effect, where the technicians and the customer appear to be in agreement, but have different understandings of the problem or solution, so while all are smiling and nodding – there will be some time when, subsequently, they all realize that they missed something.
One of the reasons that these kinds of miscommunication happen is when the same term has meaning in multiple domains, and different people assume that they know which domain is in play without qualifying or clarifying it. These collisions, where a term has meaning in multiple distinct domains that are relevant in a conversation are sometimes very hard to detect. It feels like a wormhole opened in the conversation and we jumped from one domain to another without realizing it.Continue Reading
I spend a lot of time with software developers. Most of the time I spend is clarifying semantics between business domain and technical domain. Semantics have to do with the meanings of words or terms. In the business domain, when semantics are ambiguous it is often context that allows us to clarify. I work hard to clarify terms that users posit to describe the entities and operations we are modeling in the software we use.
When words are “overloaded” it is hard to avoid being confused because we use the same word to describe multiple distinct entities or operations or operational states. Much of the overloading occurs because “qualifiers” are embedded in business context, so to the business staff, the qualifiers are unnecessary.
Sometimes, though business people actually use the same word differently in the same context and you end up with a buffalo.Continue Reading
Just Good Enough. That is what we need.
I need code just good enough to work, then you can make it beautiful, after its working.
I need requirements just good enough to start a conversation, then we can refine and revise.
I need architecture and design just good enough to ensure feasibility for a delivery cycle, then we can harden, and make it more robust.
I need plans just good enough to get started, then we can add detail and revise ad nauseum.
If you want to go fast, you need just good enough. Sure just good enough may not be good enough for ever. Just good enough to start may not be good enough to finish. That is the point.
In order to work using the Just Good Enough principle, I need people who are willing and able to deal with the emergence of information, who can adapt to new information without having a nervous breakdown. Continue Reading