in

dotnet.org.za

South African .NET Developer Portal

Delphiza

KillChildren() - A sign of a bad programmer or a serial killer

A comment by a colleague on my last post on 'relations' - chuckling at the question "What on earth is a 'parent-child relation'?" prompted a post on one of my other naming pet hates - namely the mis-used concept of Parent-Child to denote hierarchy.

Over ten years ago I wrote a tree handling routine that needed to delete sub-nodes of a particular node and the method started off being called Node.DestroyChildNodes() which, at the time, I thought would be pretty cool to rename to Node.KillChildren() to reflect the concept of eliminating the children.  Over the years I became more pedantic about naming, primarily inspired by my mentor who was and is extremely particular about naming.  This person had an interesting academic background and his degrees in Theology, Psychology and Electrical Engineering made him interesting to deal with.  He was working as an architect on a project and I overheard a discussion he was having with a developer that went something like this...

Architect - "Did this account fall pregnant?"

Developer - "Er... no" (I don't understand the question look on his face)

Architect - "Did this account go into labour?"

Developer - "Er... " <long pause> "No"

Architect - "Was this account inseminated by another account"

Developer - "I don't think so" (some language barrier here)

Architect - "Did this account go to hospital and, after a long labour, give birth to this (other) account?"

Developer - "No.  What on earth are you talking about?"

Architect - "If this account didn't physically give birth, or contribute is sperm to that account, WHY THE <expletive removed> DO YOU CALL IT THE 'PARENT' ACCOUNT?"

Since then, the developer made sure that he only used parent and child when referring to real people, as parents, and their children.

So if it is not correct to use parent-child except in cases where there are actual people involved who have a legal and physical association, what should be used to denote hierarchies?  The simplest and most generic would be to use subordinate which the dictionary defines as 'One who stands in order or rank below another'.  The shorthand of subordinate is sub and is something we use often in English as in subtitle, sub-paragraph and so on.  If sub is the 'child', what is the 'parent'?  From a rank perspective, a choice could be 'principal' but more generically I prefer to use 'superordinate', which the dictionary defines as 'Of higher rank, status, or value'. Although superordinate may be a little bit obscure it is used in English (superscript) and has a convenient shorthand - namely sup (which if misinterpreted to be 'superior' is not to bad.

Using this naming, a table that stores a hierarchical structure may have the fields 'Id', 'Name' and 'SupId' (instead of ParentId).  My tree routines would also read better - instead of DestroyChildNodes() I would have DestroySubNodes(), which reads well; I would also have a property called SupNode, that would return the superordinate node.

Using sub and sup is the easy, generic solution, but if you think about it more there are other names that can be used in different circumstances such as...

SuperordinateSubordinate
PredecessorSuccessorUsed if the time dependency is critical
ProviderDependantUsed in true dependency relationships

Can you think of any more to add to this list?

It is important in both design and implementation that we name things well and that they make sense.  All too often business hands something over to IT and by the time it comes back it has been abstracted, generalized renamed and confused. 

Imagine the scenario when dealing with a user talking about a medical aid system where a person has dependants...

Developer : "When you click here the child nodes are removed"

User:  "Why not the spouse node as well?"

Developer: "There is no 'spouse' node"

User: "There is, two children and one spouse"

 

Simon Munro

Comments

 

Ernst Kuschke said:

Interesting that a language like JavaScript refers to the "parent" of an "element", as well as the "children" of an element in the DOM :-)
August 24, 2006 12:24 AM
 

MitchellGeere said:

I completely understand this blog, but there is one issue I have. That architect isn't a very nice guy and has no clue how to handle people. There is no reason to be like that. Most of the time he would end up with a foot up the pooper. I find that in our industry we are either too theoretical i.e. worry too much about etymology and epistemology etc. and not enough about what actually needs to happen. In other cases we worry too much about semaphores and singletons etc. and again not about the bigger picture. People as much as we think what we do is to be honoured and rivers should bleed and mountains should bow to us we are workers that simply need to put a system in place for people to get their work done quicker. There is no other point to what we do! Without business we have no purpose, they fund and feed us. So lets not worry too much about what we name our tree leafs and focus on getting a well designed product to client so that they can get their work done quicker and more efficient. By the way dont get me wrong naming is still important as long as it makes sense to common language and is justifiable it is valid. Example calling a sup a parent or a sub a child is not a big deal everyone will understand. So please dont loose anymore sleep and tell that architect to become a decent human that treats people with respect, even more so if that person is a subordonate because then he will receive respect. Sorry I am ranting that architect guys dialogue was just very disgusting.
August 24, 2006 12:02 PM
 

Delphiza said:

While I agree that maybe the metioned architect could have been more diplomatic, I disagree that naming should be glossed over in exchange for speed of delivery.  Data and object models represent much of the semantics of the business and taking the time to name things correctly is imperative if we are to deliver quality systems.

The classic example in data modelling is the naming of the supplier to part associative entity. 95% of the time developers name it SupplierPart which is meaningless to the business when it could actually be Quote(ed)Item, ShippedPart or something, depending on the usage within the business.

I can relate to the mentioned architect's frustration as I encounter bad naming every day.  Recently, when developing some multi-dimensional classes the developer had a fairly fundamental class called 'ColumnRow'...  after about an hour of arguing and discussion he finally conceded that 'ColumnRow' is more commonly known as a 'Cell'.

While I don't expect us to change the JavaScript usage of parent-child I think that we have to be considerate of business when developing our systems.  Whether that be the ability to train users, ease at which external report writers can use our system or even the next developer on the team.  I gaurantee you that in the above example the next developer would have been far more confused reading ColumnRow.Value than Cell.Value

August 24, 2006 2:16 PM
 

MitchellGeere said:

Hey Simon, like I said in my comment "By the way dont get me wrong naming is still important as long as it makes sense to common language and is justifiable it is valid." I would have had an issue with ColumnRow as well that is a cell point end of story there is no two ways about it. Yes also I do agree business entities/concepts/items called what we may should be descriptive of its purpose of existance. I would maybe even go as far as saying that yes maybe Liguistics should for a minor part in a Info Sci Degre or a Comp Sci degree to get developers thinking in terms of meaning as apposed to simple semantics so a phrase an architect could ask the developer is "It might look right to you, but what exactly are you trying to say about the class. Is ColumnRow not the intersection of a column and a row, there by forming a cell where the data will be stored? So would you agree that the class should rather be cell?". I think a big problem out there is that there is no phase of discovery for most developers they all just start coding blindly making it up as they need it. Essentially we need to find a happy mean, a common ground where we dont over design and under code and vice versa.
August 24, 2006 9:13 PM
 

Armand du Plessis said:

There's a really good book by Eric Evans on DDD called "Domain Driven Design - Tackling Complexity in the Heart of Software" [1]. One of the key concepts addressed in the book is having an "Ubiquitous Language" - making sure everyone on the team is speaking the same language and using that language throughout code, diagrams, discussions etc etc. I have my doubts whether referring to entities in the domain model as "superordinate" or"subordinate" would really make sense in many domains. I would have look at what the business refers to these relationships as and try and get the language used in design and development to match that.

[1] - http://www.amazon.com/exec/obidos/tg/detail/-/0321125215?v=glance

[2] - http://patternshare.org/default.aspx/Home.DDD.UbiquitousLanguage

August 25, 2006 9:31 AM
 

Delphiza said:

Thanks for the references.

I suppose my bias is to more generic naming if the real business name is not clear or understood.  At least sub and sup is sufficiently meaningless (particularly in a business sense) that it does not create confusion - unlike parent-child which does have a well defined and existing meaning outside IT.

I must agree that the first objective is to find the name that business refers to any attribute.

August 25, 2006 11:31 AM
 

Ernst Kuschke said:

The point of referring to JavaScript wasn't to change its naming convention, but to illustrate how embedded the "parent/child" terminology is in our industry - it's part of an ubiquitous language spoken in the software world ;o)
August 28, 2006 3:37 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Powered by Community Server (Commercial Edition), by Telligent Systems