What Does Your Code Say About You?
ArcherPoint as a company has been learning a new method of management called Tribal Leadership. It’s not really a management style as much as it’s a method of leading. It is based on aligning the business culture with the business core values. Part of this alignment is self-awareness, identifying your own core values, and identifying your “stage”. One activity we recently participated in was to go to a public place and watch people and notice the stereotypes we assign to people as we see them. I went to a mall, and for once instead of shopping (well, at least for a short while), I sat on a bench and watched people.
What I found is that I am a VERY opinionated person! If she is wearing three inch heels in the mall, I presume she either works there, just got off work and is shopping in a hurry, or is about to learn that one-time lesson we ladies have to learn about wearing heels when we’re shopping. If she’s wearing a baseball cap, she didn’t wash her hair that day. If she is walking strides ahead of her toddler, I assume she’s not an attentive mom. If he’s sitting on the bench with a bunch of packages he’s probably there with his wife, who is still shopping, and bored. If he has his pants dragging below his boxer shorts, he’s too lazy to pull up his own pants, and probably can’t find a job where only one hand is needed because the other is busy holding up his pants. (Frankly, I think it should be perfectly legal for me to assist these young men with their underwear-sharing endeavor by running through the mall and pulling their pants to their knees!)
Stereotypes are just one of three ways we have of “knowing” people. We know them by reputation, by their core values, or by the stereotypes we assign. Stereotyping is something we all do. But what I did notice about the stereotypes I would attach to perfect strangers is that some of them were harmless. They didn’t stick with me, they didn’t cause me to think more or less of the person, they were just an assumption made based on the very little information I was given. Others, like the one I still find myself assigning to Mr. Boxer Bottoms, are harmful, because they immediately create a negative energy in me toward that person. That’s not good for me, or for the person I’ve attached the labels to. When you build a wall between yourself and any person you deny yourself the right to benefit from what they can bring to your life – big or small – long term or short term. Now I’m not saying the Mr. B would care what I think, but perhaps if he knew how his attire was being read, he most likely would not dress the same going to a job interview or to pick up a date. And perhaps if I knew the stereotype he might assign to me, I might do things a bit differently too!
As a NAV developer, we should to be cognizant of the fact that our code is a reflection on us. Unlike some careers where your work is unattached, ours is documented with our initials or name, and tied to us for as long as the code shall live! A total stranger may one day read our code and determine who we are based on how we’ve written our code.
Is it unprofessional?
Is it sloppy?
Is it hard to follow?
Is it inefficient?
Did it grow to be the Seymour’s Venus Flytrap from “The Little Shop of Horrors”, making you more and more anemic with each modification you have to add?
There are many ways to accomplish the same end result in code. That’s the beauty of development – it’s very creative. But some ways are good, some are okay, and some are detrimental to the entire database. How do you think your code reflects on you? Here are a few examples of reflections I’ve made on my own code, and other developers.
There’s a time and a place for everything, but “playing” with a client’s database code reflects unprofessionally on the developer. For example:
Winder.OPEN(‘No. of records modified #1##################’); Mosquitos := Mosquitos +1; Winder.Update(1,Mosquitos);
“Winder”? “Mosquitos”? Really? Now I have to admit, when I first saw Piknik.com’s opening statements of “Laying out a blanket”, “Picking Flowers”, “Planting Trees”, I thought it was cute. But that was in creative software for photo editing (now part of Google+) and not a business ERP.
Standards are created for a reason. One of the standards employed by Microsoft Dynamics NAV is that tables have set variable names, such as the Customer Ledger Entry table is called CustLedgEntry in code. But the rebel will decide to give it their own name:
CLE.SETCURRENTKEY(“Customer No.”,”Posting Date”,”Currency Code”);
This forces the secondary developer to go look up the variable to see what table is being used. If it were named “CustLedgEntry” there would be no need to investigate this line of code. (To learn more about record variable naming conventions, refer to the MS Dynamics NAV C/AL Programming Guide).
The Short-Sighted Developer
This type of developer is often task-only focused. It’s an approach to development that disregards code already written and code that will be added in the future. It’s down and dirty – just getting the current task done and moving on. Here’s an example from a single function:
Item.GET(SalesLine."No."); (…additional code lines…) Item2.GET(SalesLine."No."); (…additional code lines…) Item3.GET(SalesLine."No.");
In this example, the three records being pulled in are all the same. The second and third versions were added most likely to assure that the variable the developer was adding and using was not being changed by the code already present.
Having three variables define the same record could be detrimental. Which is modified by the code? What if modifications are added that update the wrong variable?
Additionally, there’s no test to assure that the SalesLine is for an “ITEM” type line, and no handling of what would occur if the record could not be retrieved. That means that the first time a “RESOURCE” type line is read from the SalesLine, NAV gets to air this developer’s dirty laundry in the shape of an unhandled error.
The Web Weaver
I’m not talking about web sites – I’m talking about spider webs! This is the developer that creates branches and loops of code that require you to mind map the code to understand what was intended. Here’s a brief example of this kind of code.
IF Color = 'Blue' THEN ColorCode := 'BLU' ELSE IF (Color = 'Red') OR (Color = 'Scarlet') THEN ColorCode := 'RED' ELSE IF (Color <> 'Red') AND (Color <> 'Scarlet') AND (Color <> 'Blue') THEN IF (Color <> 'GREEN') OR (Color <> 'Green') THEN IF (Color = 'Yellow') OR (Color = 'YELLOW') THEN ColorCode := 'YEL' ELSE CASE TRUE OF Color = '1' : ColorCode := 'YEL'; Color = '2' : ColorCode := 'RED'; Color = '3' : ColorCode := 'BLU'; Color = '4' : ColorCode := 'GRE'; ELSE ColorCode := 'BLK'; END; IF ColorCode = '' THEN BEGIN I :=0; REPEAT I := I + 1; IF Color = ColorArray[I] THEN ColorCode := ColorName[I]; UNTIL (I=24) OR (ColorCode <> ''); END;
I know I said “brief example”, and it’s not. That’s the point! Any time you find yourself reading through code with this many branches and iterations, consider if this would be a good time to clean the code up. One of my fellow developers at ArcherPoint recently said “I like to leave the code better than I find it.” Now that’s the kind of developer I want to follow – not the web weaver.
The Careful Coder
Not all stereotypes are bad, as I said earlier. But they all are revealing of the developer. The Careful Coder assures that the secondary developer understands the code written. I recently opened a table to add fields and noticed a statement in the Documentation trigger stating
“NOTE: IF YOU MODIFY THIS TABLE YOU MUST ALSO MODIFY TABLE 50011! OTHERWISE THE WEB ORDERS MAY NOT CREATE PROPERLY!”
If the statement had not been there, I’d never have known to look for it. This developer thought ahead to the day that I’d be in the object. Much thanks to that developer for helping to ensure quality in my code!
The Tour Guide
This is the developer that assures the secondary developer is following the code and understands where he or she is at. Here’s an example:
// GET QTY PER THE GIVEN QUANTITYTOCONVERT TO CONVERT TO BASE UOM (…additional code lines…) // GET QTY PER BASE TO CONVERT TO CASES (…additional code lines…) // CORRECT FOR ANY MISSING UOM RECORDS (…additional code lines…) // CONVERT QUANTITYTOCONVERT TO CASES (…additional code lines…)
Again, I’m not a hater! I like a tour guide on my development adventures, or safari guide when the code becomes a jungle! Any assistance you can add to give a future developer better understanding of what your code accomplishes will help ensure that the code stays stable.
As I said earlier, stereotypes aren’t always bad – only the ones that build walls between us and others. When working in a multiple developer environment it’s important to understand that we ALL fall into stereotypes with our code. When we find things we can improve on, we should do so. Leaving the code better than you found it is always a good reflection on you.