Tuesday, June 03, 2008 #

Nomenclature - A Barrier to Learning

“What's in a name? That which we call a rose
By any other name would smell as sweet."

 

Smells wonderful, but what if no one plants it, no one waters it and even the gardener can't remember what the heck the flower that smelled so nice was called.

 

I’ve been somewhat absent in the Microsoft events and hooplah in the past.  These meetings and events used to be mostly about technology previews and the next cool tool or language that will revolutionalize software development (in recent while, I’ve noticed things are changing however for the better with the community initiatives). What really interests me is platform agnostic design principles and best practices.  I cringe when I attended a Microsoft event this year and saw yet again that CSS class called ‘MenuLeft’ where the presenter showed how easy it was to change the implementation to have it float right.  You see, to me a name is important.

 

The goal

 

Closer to my point now… I feel a part of our responsibility in our goal of moulding new developers into star programmers/designers lies in realizing their roadblocks to learning and in making adjustments to our teachings to compensate.  Do not spend time teaching them technology, they will get drawn into that as long as they have a curious nature, teach them design and good coding practices… and find the right names to make them remember.   

 

For example, when I held some database design reviews some time back, I didn’t even bother using industry accepted words like ‘normalization’ at first.  I found myself making up the term ‘row-based design’ and teaching how ‘column-based design’ had problems.  Seemed liked they got it and future database additions were in good form without me being involved.  New team members are since then being taught about how ‘row-based design’ is better. 

 

A new goal of mine is to focus on teaching object oriented principles in order to have it applied correctly and to leverage the benefits in new development.  Before working where I’m at, I was in the Java camp and spent some time decompiling Java class libraries in order to learn how they were implemented (Sun developers are awesome by the way in their implementation of the Java packages).  Along with an experienced OO mentor for a few months some time ago and a lot of self-learning and trial and error, I have found some ways to do things that make future maintenance/refactoring much smoother.

 

Horror

 

So I talk to people in the .Net camp that know what they’re doing and find out the latest and greatest in OO talk.  What do I hear about? Stuff like Liskov Substitution Principle.  I wonder – what is this great thing, I never heard of it, it must be past my current knowledge base.  I look up the definition: “In class hierarchies, it should be possible to treat a specialized object as if it were a base class object.”

 

I’m like wow… what a bad name.  This is like intro to OO type of stuff and we try to teach people this way? A few weeks later, I hear that term again. I want to appear knowledgeable, so look it up.  Oh yeah, I forgot, it’s polymorphism by inheritance.  Gotta remember that… I have a decent amount of OO experience (not an expert, but I’ve thought about how best to do things quite a bit) and yet I need a reference or search engine at my side.  This is bad, I can tell you I will need to take some time to come up with my own new vocabulary in order to spread the word.   While I’m at it, I might look for an alternative for Inversion of Control (lovingly shortened by the community to IoC). 

 

The ideal

 

It makes me think – what is the best protocol for naming?  I want to avoid pushing theory and constantly re-inforcing/reminding people the definitions; I want them to just intuitively get it.   Object oriented development is a relatively new field of study (especially in the MS world). As with most areas, I would predict an evolution, how about:

 

Phase 1 - Scientific Naming

Phase 2 – Layman Descriptive Naming

Phase 3 – Intent-Based Naming

 

Phase 1 (Scientific Naming) is the talk of academics and ‘smart’ people.  We are not at the point where we can benefit from our full pool of young potential and community.  We lack the naming that will get old school management on board with new ideas. Scientifically named concepts will yield slow adoption and recognition.

 

Phase 2 (Layman Descriptive Naming).  Here we are getting somewhere, we haven’t encoded why we are doing things, but we are now making some good patterns easier to remember.  This is the difference between saying you have conjunctivitis and getting a lot of blank looks from everyone, or just saying ‘pink eye’ with nodding heads all around.  We need names even non-technical people can relate to – this ensures that our university students can get hopping with good principles starting from day one.  I even find myself avoiding the widely accepted word ‘polymorphism’ in favor of something like ‘plug and play’.  My advice: pick up the grade 6 dictionary for teaching IT, throw away the university textbook.  Refer to the official name as a sidebar (there may be multiple official names), but use the layman name to really get an understanding across.

 

Phase 3 (Intent-Based Naming) is an idea for a utopian naming convention.  Imaging the software engineering field to be mature at a point where we have a deep understanding of why we use the principles we learn.  How many times have we seen a good concept mis-applied or used in the wrong context?  Junior developers are passionate to try out every advanced trick in the book yet lack the experience to answer “It depends…”.  What if we actually put our experience in the nomenclature?   Easier said than done and I’m not sure if it is possible to come to such a place for everything, but names like ‘Seperation of Concerns’ kindof hits the mark for me.

posted @ Tuesday, June 03, 2008 12:07 AM | Feedback (0)

Copyright © Remi Sabourin

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski