Another good article, thanks!
Many things related to “over-head” (over-designed, over-engineered) I can agree with. Not sure, why so much space is devoted to bashing UML (fortunately, I never needed to use it seriously and fully, so I can’t understand).
One moment thought caught my attention. Unlike in the previous article (in the part about OOP), it’s said here in the clear, that ontologies are evil. Well, I not that versed in linguistics and probably it comes from one of competing schools of thought there how words do get their meanings (through the context or somehow more permanently). However, I see ontologies as very important and high-quality (and high-cost) declarative content, which can serve as a base for software development in specific domain as well as a basis for meaningful data exchange (the primary purpose of semantic web). To the point I’d started next green-field project by taking good ontology and skip a lot of trials and errors to get the first iteration. Of course, ontology is not Turing-complete description (and for practical reasons it can’t even be — see Description logic, eg in wikipedia). So in my opinion good ontology solves a lot of problems. And semantic tools can make tedious integrations and other transformations tens of times easier. This actually does not contradict the general idea of the article, so not sure why ontologies went there together with UML. I’d even argued, that when we code, we create an ad hoc ontology. So it’s better to be aware of that from the start and even for small projects it makes sense to have unified terms for things with the same meanings. Unlike in a fiction novel, using different synonyms for same things (like “created at”) will unnecessarily increase the complexity of the code. Standardization helps understanding.
I agree linguistic laws and concepts are applicable in software design, and even said design being a language activity. However, natural languages necessarily (because otherwise the can’t be used to describe new concepts) have redundancies, while formal languages are much stricter and limited. Having Ubiquitous language with unique terms per bounded context (as in DDD) can be hardly argued against, as even language in the scientific articles should avoid ambiguities.
So basically a lot of those language activities is nothing else but building common controlled vocabulary —taxonomy — thesauri — tada! …ontology.
Of course, using declarative programs for the online clothing shop is perhaps overkill, but on the part of product descriptions decent ontology of all those sizes, materials, washing instructions (and their translations to several natural languages) would make a lot more sense than handling all that with bunch of IFs and SWITCHes. Ontology can’t help you with morph algorithm, but it can help you with more intelligent, semantic search. Same is true for auxiliary domains such as payments: Without proper ontology you will need to use 3rd party service, which will abstract all that away. Or if you take Delivery. There are some entrenched ontologies there like EDI. It hardly makes sense to invent something new there just for a clothing venue. And ontologies are really out there, in every API, format, protocol, software, even if we do not think of them. They come into play when you have to abstract away many similar vendors. Then usually some middle-ground ontology is the best way to align them. It’s the only way to preserve and be in control of semantics.
One thing however, which linguistics and “ordinary people” can’t help with: More often than not, the domain we design in contains constraints, which aren’t directly intuitive for end-users, and natural language does not provide good support. One such example is multi-criteria Boolean search. It does not matter how much you invest in user experience, search will still be complex for the end user, and unless you are proficient in logic, language will not help you. Back to choosing clothes, if a shopper has some specific dress in mind (with ANDs and ORs in it’s description), making search helpful will be tremendous tasks. Ordinary language fails here…
Looking forward for more articles!
