Programming The Sierras

Insights to high quality software development

Page 2 of 3

Stories from My Dad

On our last visit to my dad, Frank A Roys, I scribbled down an evening’s worth of storytelling. I’m transcribing it here for posterity. 

1930, Winfield Kansas

Dad worked for Jack Lane Chevrolet. Networking, until summer of ’35.

Keith born 1930, March 25th.

Frame house, first lived in an apartment. Remember two bedroom house but it must have been three because Aunt Emma, Lidia’s kid sister, came to live with us.

Hary Longfeffer — quiet the joker – “Over the fence the cow some hay throw.”

FRANKIE HALBERT – kid next door works himself up into frenzy, hit Frank in the nose give him a nose bleed and run home to tell his mother he was in a fight. After five or six times I saw him winding up, blocked his punch, caught him as he ran away, use wasteband on the ground where I found a rock from garden and hit him in the back of the head – put an end to that. 6 years old. His mother came over screaming , my mother and Aunt Emma were laughing about the “I’m dying…”

Dad worked for a Chevy dealership so every year or two we would have a new car.

Aunt Helena (Lena) married Longfeffer (Longhoffer?), had Clifford one month younger than Frank. 

John Litke, born in Warsaw Poland, in the German Ghetto. Moved to Russia looking for a better life- wound up in Manitoba, Canada. At German club he met Flaie Slochim, she was born in Warsaw also – never met there, got a homestead (had to improve property – then it was your). They lived in a doug out in side of hill.

They had to wrap up baby Lidia in a shirt.

There is a picture of grandpa with his pet bear.

Logged property for 3-4 years.

Lidia was born 1900 (1899-1901 records were burned in court house fire)

1911 they moved to TX for less than a year then moved to OK.

Roys Family:

  • Marco – oldest
  • ?
  • Rhubin
  • Phillip Allen Jr, hated “Al”
  • Luciel
  • Cousin Phil,
  • George Pat Roys

Lots of “Pat & Mike” jokes – Irish.

The 4 older brothers made up a quartet, they would sing during the Amature Hour between movies to get in free. They would pay for their dates, see a movie, excuse themselves , go up on stage to sing. Marco was the best singer. All were base. He would sing “Asleep in the deep” and win 1st place all the time.

Lidia and her brothers and sisters would kid each other about being Polacks or ‘hangaks’ They were Germans born in Warsaw but never really Polish.

We had a dog part german shepard part big dog. The dog would sit on the running boards as we drove around. once dad made a tight turn and the dog went straight – yelping. We had to slow down while the dog caught up and got back on the running boards.

Reuben graduated from Eastman school, top bookkeeper. Rich kids paid him to do their books.

Aunt Emma lived with Lidia and family. When Keith was born he had colic and would start crying in the middle of the night, and the only thing she could do was pick him up and rock him. It worked, they developed quite a bond.

Vocation Class Seaside OR 38. Mom taught girls to sew and I learned woodcrafts. Wakefield family taught crafts. 

He was a retired missionary, he had malaria had to move to Seaside OR. Wednesday night social that is where I learned “winkum”

Dad worked for Weyerhaeuser, logging – one log per truck. It took at least two days per tree. Most was Fir, some Hemlock, some Cedar. The trucks would come down to the office and get ‘scaled’ before heading to the mill.

After Weyerhaeuser logged it out he went to work for Corverse & Hitchmen and for bunkhouses and office in Elsie OR, wide spot in road. Lived in stree6t car used them for offices bunkhouses, mess hall, etcv.

Less than a year,m moved back to.

Started freshman year in Seaside then moved back to Arkansas. First dad told me Father needed help. Truth was the company wanted him to cook the books. He called parents and moved back home, quit the job. He won’t admit it, make a scandle. Turned out Father wasn’t feeling too good. Needed help with hardware store. Russellville, Arkansas. Frank had to graduate Jr. High School twice. Arkansas had a high school system that Seaside didn’t.

After I graduated from 8th in AR went back to Seaside for the summer. House had an alley running behind it. One day a truck dropped off a snag – a 20 foot piece without any limbs. A man with a gas powered cross cut saw and sliced it into 16″ sections. It was my job to use axe, wedges and sledge hammer – bust it up into firewood big pieces for fireplace and heater and some for kitchen stove and kindling. 3 sizes. In winter place we would block off fireplace with plywood p,ae a stove heater with pipe through hole.

Lived in basement apartment of a hotel at ground level. When it rained we had to walk planks.

I was a pinsetter at bowling alley. half dozen of us. We went to beach and got cracked crab.

Tarter Sauce:

  • 4 Mayo
  • 3 Ketchup
  • 1 Relish
  • Dash lemon juice.

Went to my place to eat it as it was closest. 13-14 years old. We worked 7-11 when they closed. Had to guess what it was made with

Brittle Software

Some months ago a manager referred to an existing method as ‘brittle’. I knew the standard definition to the word and inferred the meaning in this context but only afterwards have I settled on what it really means for software to be brittle.

Software becomes ‘brittle’ if too many assumptions have been made; “It will never be run on anything less than 1024×768 resolution”, “The user knows to enter the numeric serial number here”, “The quantity is never zero”, “We expect no more than ten users at any given time” and so forth.

Brittle software usually works just fine, or at least it does in the beginning or without too much extensive/excessive use. The load piles up, the users try unusual stuff, sometimes then the cracks start to show.

Robust software, on the other hand, makes the opposite assumptions; “We have to check the resolution of the display”, “The users may enter the date incorrectly”, “The database can contain anything (or nothing) in any column”, “The connection may drop at any time”, “The user may run the process for days on end”, etc. Hard coded values and factors are a common source of brittleness.

You have to actually pay attention to the stated requirements and look for actual real-world shortcomings. And that is how you make resilient software.

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.



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. 


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.


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


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 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>

« Older posts Newer posts »