Programming The Sierras

Insights to high quality software development

Page 2 of 3

Cut & Paste Programming

It is nigh impossible to resist the urge to copy a file or a block of code to repurpose it. This is a good thing to reuse working code. Just Ctrl-C, Ctrl-V, rename what needs renaming and you’re done.

Right?

Wrong!

All too often this ‘easy’ task goes off the rails and your code gets broken in the process. It is too easy to miss something in your rename process, to miss a required change.

All too often the least that goes wrong is the error messages and comments talk about the old version.

So… the rule to make Cut & Paste Programming work is: always rewrite the whole the whole thing from top to bottom. As if you’ve never seen it before, line by line, clean it up.

Or if you are really good just refactor the module to a more generic form and call it with appropriate parameters, that is the right solution. 

Time

Once upon a time I had an epiphany, an epiphany about time. My recollection of the event, of letting go of my slavish dependence to time, is crystal clear.

2008, November, my sister in-law was moving from a remote location in Washington state to an even more remote location in the heart of Tennessee and was down in Tampa to pick up a load of household goods we had acquired. We loaded up a cargo trailer, my Dodge Ram pickup, my sister in-law’s huge Dodge van and an S-10 pickup and headed out.

It should have taken a long day to get to Deer Lodge.

We couldn’t get out of the front yard without a minor disaster: the trailer hitch jammed itself into the dirt but thanks to a landscaping crew passing by at that exact moment we were quickly unstuck and on our way.

Then the trailer’s left tire shredded itself up where I-275 and I-75 merge. I was all zen about having to take the tire off to go replace it. I first stopped at Sam’s Club but they didn’t have trailer tires and that I needed to go to the next exit off of I-75 for a real tire store where they did put a new tire on the wheel. I then went back south, well past where the girls were waiting, loop around and meet back up with them. I quickly replaced the tire and we headed to the tire store to replace the other one.

But it turns out the S-10 was not up to the job of pulling the trailer so we switched it to the Van which easily handled it but it didn’t have the proper electrical connection for the trailer’s turn indicators and tail lights so we found an auto parts store where they fashioned an electrical adaptor and send us on our way. Also I took the helm of the S-10 at this time and Chris, my wife, drove the Ram pickup.

We made it to Lake City and found a hotel by sun-down. A friend who was tracking our progress reported we were making an average speed of nine miles-per-hour; wow.

The next morning we made an easy-going start but hit bad traffic and very heavy rains in Atlanta. We made the mistake of taking the bypass route which was jammed with road-raging truck drivers one of which tried to run me off the road. I’d like to point out the S-10 was in a rough condition: bad windshield wipers, no music, loud muffler, and a uncomfortable seat but I was being all zen about it. We made it to north Georgia that night.

The next morning we took off and checked out a job site in Knoxville and got new wipers for the S-10 (yay) before continuing on to her new property in Deer Lodge. Let me put it this way: you get off the interstate and on to a state road, you then get off the state road and on a county road, take a turn off the county road and onto a local road which leads to a country road then a dirt road and then to a steep gravel private driveway to her place.

It was a wood tent in the middle of nowhere. And there were no leaves on the trees and it was gray and rainy and it was cold and I was miserable.

As soon as we pulled in I sized up the situation and was all ready to unload the cargo and head home, right away.

Chris saw my discomfort and got us a room at a LaQuinta twenty miles away where we had hot water (none at the property and no water and no toilet) and electricity and wi-fi and soft beds.

So we got Cailin settled into her place and spent a day there. Monday, we gassed up the van so Cailin and Chris could drive back to Washington to get more stuff and I gassed up the Ram so I could drive home. I mapped the route and committed it memory (pre-smartphone era) before taking off.

I headed south on state road 127, down the Sequatchie Valley. I reset the trip odometer and noted the time and in my head calculated my ETA.

“NO!” I told myself (this is the epiphany).

Just drive, it doesn’t matter when I should get there. I’ll get there when I get there. Tampa will be there at the end of the trip no matter what, it isn’t going anywhere. Time didn’t matter. I took my watch off and stashed it so I couldn’t habitually refer to it or robotically check it. Time didn’t matter.

I relaxed. I relaxed because time didn’t matter.

And I drove down the Sequatchie Valley. The road is a lazy left-right left-right, little up, little down though overall it was downhill for 100 miles so the drive was easy. And the valley was beautiful, trees were in color, some bright orange. I got in behind a Jaguar doing 85 and cruised down the road. I was at peace with the world.

Early Agile

I was just reminded about my first experience on just how agile (lower case ‘a’, not the Agile methodology) software development can be.

It was in the late 80s when I was Lead Developer at Practical Software and we had a dozen representatives come in from MindScape to take some product training. We had a big monitor up front of the room and I think Chip ran the sessions while David Gale (it was his company) and I sat at the back of the room watching.

Early on there was a moment  of visible confusion amongst the trainees at some screen; they weren’t sure what to do, it wasn’t clear. They moved past that point and on with the training but David and I conferred and I had a suggestion for a redesign which he approved and I implemented so while they were on their lunch break I updated all their computers.

When they came back they had a better program waiting for them.

Today with the internet and even just good old networks the updates can be instantaneous but this example shows how, even in the good-old-days software development was fast.

Formatting

I’m a stickler for formatting. Code should look elegant and it should be easy on the eyes.

When I see how some code is formatted I think ‘Why do you even bother? What are you trying to accomplish?’ Which brings me to a good point: what are we trying to accomplish with formatting our code?

Back around 1985 a bunch of us COBOL coders were let loose with C, we were like ‘Oh, wow, now I can do ___’ and we wrote a dozens of tools, games and toys. Steve, my co-worker, wrote a tool that would strip out all unnecessary whitespace from a C source code file, that included Line Feeds and Carriage Returns, and produce a very compact and nearly unreadable but valid and compilable program file. This was mostly an exercise in programming but brings up a good point: ‘Why format code?’ What is the purpose?

Later in the 80’s we hired a new C programmer and he sent samples of his code. He used the format where an opening curly brace was below the block’s keyword (e.g. if, while, for, struct) instead of at the end of the line with the keyword (AKA “K&R style”). We looked at this and instantly and inarguably realized it was better and changed our standard. I wrote an editing macro and updated all of our source code files within minutes of seeing this better style.

Our old (“K&R style”):
for (i = 0; i < max; ++i) {
    printf ("%d\n", i);
}
The new style:
for (i = 0; i < max; ++i) 
{
    printf ("%d\n", i);
}

This all leads to the answer: better communication. The new style makes it easier to match the start and end braces, especially when you have many nested levels of blocks within blocks. It makes it clear what is going on.

Today when I see bad formatting I get the idea the Programmer writing it didn’t care about making it readable. It is a mark against them.

Over the years I’ve developed some rules for my code style/formatting:

  • Never more than one blank line. When you start using more than one blank line the question comes up ‘When do you use two?’, ‘When do you use three?’ A blank line is used to separate one section from another and two blank lines doesn’t separate the two sections any more clearly than one. Let me make this clear: NEVER MORE THAN ONE BLANK LINE AT A TIME, and give careful consideration to using even one.
  • My comments are sparse and important so I include a blank line before most comments.
  • I always use braces to specify a block even when it isn’t absolutely required. Some modern languages (Swift?) require braces for all code blocks and others rely on just indention to demarke blocks.
  • End braces do the job of separating code very well so I never have blank lines before or after an ending brace.
  • Use tabs for indents, not spaces, this keeps blocks that are indented aligned. There are pro’s and con’s for using both spaces and tabs but tags make it quicker to un-indent a block or line of code.
  • Keep the rules uniform. No ‘double tab for sections that aren’t likely to execute’ type rules.
  • Good rules fit all situations.
  • I tend to spread things out vertically. I don’t want to miss something just because the line of code extends beyond the right edge of the window. In the old days the window was 40 rows of 80 columns, and that was all, that was it but now with high resolution monitors a sub-window is often well over 150 characters wide, and still lines run off the right edge.
  • At the very least don’t do whacky indents/outdents that screw up the readability of otherwise good code.

This is just my opinion. My opinion and 36 years of experience working in dozens of different software development shops exposing me millions of lines of code written by hundreds of Programmers. Still, just my opinion.

Career Planning

1973, my best friend Jed Smith showed me his latest achievement: an extra wide strip of adding machine tape with funny printings on it. “This is a computer program – it does this, then it does this, then it does this and it does all this over and over again until this is zero.” I responded with “Oh. I know how to do that. I can do that. I’m going to be a Programmer when I grow up.”

That sums up the entirety of my career planning. I drifted off plan over the years, I was distracted, I was a kid, I didn’t realize it was my destiny and I certainly didn’t realize the value it would have.


That summer I rode the bus down to the University Bookstore in Seattle and bought the college textbook on Fortran programming and read it from cover to cover – I knew how to program in Fortran.

Once i was in high school I had access to the Wang 600 Desktop Programmable Calculator and the school’s mainframe for Fortran programming.

As a Freshman at the University of Washington I took Engineering 123 – Fortran and aced it: 4.0.

1982 I was hired on at Micro Business Software Inc (MBSI) as a Programmer Trainee and I’ve been developing software ever since.

The National Bulletin

Back in July of 1989 I was approached by a friend (boss’ ex-wife) who was running a small newspaper. She asked me to write an article comparing the Apple Macintosh to an IBM PC which I did. She also asked a Mac fanatic to write his side of the story and the two, side by side were the front page stories. I recently found a torn up copy of the paper and want to transcribe the copy here:

Viewpoint by Brian Roys

THE VIRTUES OF IBM + compatable (sic) PERSONAL COMPUTERS

Hi. My name is Brian Roys and I am a Programmer. I work all day long on computers and I’m in favor of the ‘PC’ family of computers. This includes the IBM and all the “clones” it has spawned.

I can really get down to business and produce like crazy with my PC (I have a ‘PCs Limited 286-12’), whereas the Macintosh’s User Interface and operating system would “insulate” me too much from the power of the computer. A PC can be customized to the nth degree with the operating system and accessory programs to the point where I’m only a keystroke from any of my usual duties.

A computer’s power is only valuable when you can access it without strain. Now this applies to programming a computer as much as it does to the average user. With a PC I can make it do what I want without any “overhead”. PCs don’t require you to do things a specific way or use specific tools unless you want to. The programs can be run on a PC do require you to run things specific ways but this can be tailored to the user and the job at hand. That’s the job of Programmers. The PCs interface is not all lumped into one black and white kind of interface.

The interface of PC programs has what is needed to get the job done without built in bells and whistles. The power of a PC is accessibility.

Thank you for listening to my opinion.

(Brian Roys is a full-time award winning professional programmer working at Practical Software, Inc. in Clearwater, Fl)

Troubleshooting/Debugging

Troubleshooting physical world problems is pretty much the same process as debugging a program. That is why learning to debug software is so valuable.

Simply put, you have to pick the process apart, see where it is working and where it isn’t then finding where it goes wrong. When you ‘fix’ it you have to make sure you don’t ‘break’ it for other situations.

If you’re looking and looking and looking at your code, your module, a function, whatever and it looks like it should be working, that it doesn’t seem to be the source of your problems — the trouble is somewhere else.

Kind of obvious but I know I beat my head against the wall, trying to find my bug, way too many times before this occurred to me.


My renters called with the bathroom faucet now flowing well. They had cleaned the aerator screens but still had a problem. I checked the valves – not the problem. I checked the supply from under the sink – good flow. I then checked the screens and, yes, they are clear of grit but the water at the spigot without the screens was fine. The problem was that the aerator itself was choked with lime deposits; trip to Home Depot and $5 later and it was flowing just fine.

Track down the problem until you find the source, then the solution is evident.

The Cost of Engineering

My sister in-law needed the gas tank on her Camry replaced and my wife found a compatible Lexus tank from a junk yard. Lexus is the luxury brand of Toyota so it made sense they would share components but I never thought about a fuel tank. It is just the gas tank. On the other hand there is an expense connected with the engineering of things as mundane as gas tanks and that expense is non-zero, greater than zero. It took time to design it, insure the safety aspects of it, design how it connects to everything else and design how to build it reliably and economically. That adds up.

Modern cars are complex and lots of engineering have gone into them. There has been just over one hundred years of know-how put into getting cars to where they are today.

Rocket engines are more complex. They are some of the most complex things made today and most all the engineering has been done. Over with. The Germans in World War II did the calculations and design work and really there isn’t much that could be said bad about their work. The Russians poured tons of engineering into the design and manufacturing of the RS-180; decades of R&D have culminated in what is arguably the best rocket engine design. They are so good the US uses them in the Atlas rockets. Other rocket engines can be optimized for one aspect or another but for the job they do the design has been tweaked to death. We’ve figured this stuff out.

I love autogyros; helicopter like aircraft that are on the far end of the spectrum from helicopters in safety, ease of flying and cost. Anyway, I was looking at all the different ones at a fly-in. Some were home-made others on an assembly line. None of them hit me as ‘that is exactly what I want” but they were all very close. I now realize, when taking into account the work it takes to get from idea to paper to plane, they were all close enough.

Same with software; there is an expense associated with the building of components.

<to be continued>

Global Variables

The ability to maintain and service a software system is inversely proportional to the number of global variables.

This is a rule/maxim/axiom (whatever) I have gained a conceptual understanding of through years of working on a number of different systems.

The more global variables in use the more difficult it will be to debug or modify it. The fewer — the easier it will be to debug or modify. Not to mention that fewer globals will lead to fewer bugs.

I’m amazed how many Programmers don’t understand or practice this.

And Session variables in ASP.NET count too. Though if done properly (wrap it in a property with a get/set pair) this doesn’t have to be a violation.

Conversely, the scope of a variable should be as tight as possible. A variable should be accessible to a block of code is the best, a single method is normal, a module is OK but anything beyond that is a NO-NO.

I feel I shouldn’t have to explain this one. Just don’t.

Attire

I used to silently rail against dressing up or even dressing well. “It shouldn’t matter what I wear – people should respect me for who I am and not what I wear. People who put so much attention on what they wear or how they look, they- they are shallow.”

Right?

Wrong!

Dressing sharp is important and worthwhile.

For the first thirty years of my career as a software developer I wore jeans and t-shirts mostly. For the decade plus years spent working at home often it was robe-and-slippers. But then things changed after I started going into an office and I dressed sharp; black slacks and suspenders, solid colored dress shirt and a tie and sometimes a bow-tie (!). It wasn’t all the sudden like that but the change did happen over only a few months.

Surprise-surprise but people treated me differently, with respect. Clerks in stores, waitresses, cops (!), co-workers, etc. They all sat up a little and took notice.

It became problematic at some work sites as I intimated some people dressing like an exec or someone important so I’ve had to tone it back a bit (just slacks or jeans, suspenders and solid colored dress shirts). But still, just the suspenders set me apart and qualify as ‘dressing sharp’.

It pays to wear signature attire. For one thing I’m known as ‘that guy that wears suspenders’. I’m also the guy that wears all those different Hawaiian shirts but that is a different thing.

Even nice jeans. suspenders, and a dress shirt (no tie), which I consider daily wear will garner a ‘you always dress sharp’ from friends.

There is nothing to be gained by dressing down and looking plain. It might be to your advantage to not be eye catching – if you’re committing a crime. Otherwise it never hurts to stand out.

« Older posts Newer posts »