Space, Time, and Imagination Have No Boundaries, But Your unsigned char Does

When you order a new refrigerator, you:

a) measure the space it will occupy and you walk the delivery path to check the width and height of doorways, hallways, and entry ways.

b) OMG! Take the front door off its hinges!!

c) disassemble the refrigerator outside, and reassemble it inside.

Any answer other than "a" would suggest that you are possibly an overworked programmer who doesn't check boundary conditions.

It would also put you in the same company as the programmers who allowed a killer wallpaper to brick certain Android phones. When installed, this wallpaper would send the phone into an infinite loop, causing it to crash, restart, and then crash again. Even safe mode could not break the cycle.

YouTube tech reviewer, Mrwhosetheboss, played detective in this video, pursuing what he first suspected as malware, but then realizing it to be something more mysterious. He even bricked his own phone in the process.

In the end, it came down to one faulty pixel where the calcu…

Pointers Don't Create Memory Bugs, Programmers Do

After parking your car, you:

a) engage the parking brake
b) engage the parking brake only if you are on a hill
c) what’s a parking brake?

Any answer other than "a" suggests that you, as a programmer, don't park your pointers after you free them.

ZDNet recently published a couple of articles about Chrome and Microsoft, reporting that 70% of all their security bugs were memory safety issues. That weighty number was made heavier coming from companies where resources are abundant and developers are first class citizens. I can only imagine the bug count is higher in companies where budgets are tight and developers are support staff.

The article continued, describing C and C++ as "memory unsafe" languages, and attributing hackers with increasingly sophisticated attacks.  I even found myself reconsidering my Symmetry post, where I insisted memory can be managed if you cared enough:

common mistakes such as memory leaks and buffer overruns . . . are overstated, and can …

A Conversation With A Short Order Cook

Lunch time. It was raining, and the company cafeteria was crowded. Waiting in line at the short order station, I overheard the cook remark how busy the place was.  "It's because of the rain," I interjected.

She looked at me wryly, and said "You're not supposed to say that." She added, "You're supposed to say how wonderful the food smells, and how good it looks."

She was right.  I smiled and offered my only defense: "But I'm a computer guy."

This was little better than the rude waiter who defended his behavior as just being "French."  And yet, if you think French waiters are rude, try talking to a sysadmin.

Computer folk are notorious for being blunt. That's partly because when working with computers, we know we can't coax the machines to run faster by offering compliments and blueberry muffins.  Clever managers, however, know they can use compliments and blueberry muffins to coax developers into working late, b…

Post Processing: 2020 Hindsight

When I posted 2020 And The Year of the Rat, it was a twofer of optimism, welcoming both the 2020 New Year and the Chinese New Year. With the year nearly half over, much of the optimism has been drained, and we find ourselves in a pandemic.

The second half of the year could be worse. Dr. Rick Bright warns that without a consistent and coordinated plan to contain Covid-19, 2020 could be the darkest winter in modern history.

Regarding The Hidden Costs of Efficiency, the NYT examines How the World's Richest Country Ran Out of a 75-cent Face Mask. Farhad Manjoo recounts what we learned the hard way, that just in time supply chains ... are built to optimize efficiency, not resiliency.

When we eventually emerge from this pandemic, will we take this, and the many related lessons, to heart?

Edit 06/10/2020 - "The second half of the year could be worse." It got worse. R.I.P. George Floyd.

The Hidden Cost Of Efficiency

When it comes to coding, we developers take pride in writing programs that run fast and aren't bloated. Taken to the extreme, the cost would be readability, scalability, and maintainability.

We also take pride in writing software that is robust. Programs that recover gracefully when the unexpected happens are not just ideal, but real world requirements. Add security and privacy, and the cost here would be extensive testing, longer periods between roll outs, and a hit to performance.

This tension between efficiency and robustness is something developers wrestle with all the time, and a popular saying among programmers (and engineers) is  "Good, fast, or cheap. Pick two."¹

The impact of Covid-19 has prompted a bit of soul searching regarding efficiency and resiliency in the economy, supply chains, and manufacturing. Evidently, the world has tilted too far toward efficiency, and now finds itself vulnerable to shocks.

For example, Will Oremus explains on Medium that there …

Bookshelf Classic: The Art of UNIX Programming

Rules are made to be broken, so the saying goes.
The Art of UNIX Programming isn't exactly a rule book.  Rather, it explores the philosophy and culture behind UNIX -- its strengths, weaknesses, patterns, and associated tools.  First published in 2004, it is still relevant today and essential reading for server side developers.
As for rules, in my career writing software, I may have broken two.  The first was using threads. I felt a little panic when I read the section titled Threads -- threat or menace?

It was in the early days of threads, and I had already implemented a threaded server. Did I make a mistake? Could I have done a better job with UNIX processes and IPC?  Raymond argued that the complexity of threads outweighed their advantages.  Performance gains were lost to data locking and synchronization.  Abstraction was compromised because you needed to know the internals to prevent deadlock.  Threads were not portable.

These were all valid arguments, but today, threads are gen…

Post Processing: Facebook Reacts

In my post Swift vs Kotlin, I wrote how the pursuit of "one codebase to rule them all" sometimes doesn't end well. Experience has shown me this, and DropBox also shared the same hard won lesson.  Now it's Facebook's turn.

Facebook's framework -- React Native -- allows you to create native apps for Android and iOS, and proudly carries the catch phrase Learn once, write anywhere. The hidden costs, however, were code bloat, low performance, and increasing maintenance.

When I first heard of React Native, it was from positive press that declared it, without any sense of irony, "one of the best things to come out of Facebook."  But in 2018, AirBnb wrote in Medium that it was retiring its use of React Native:

Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.

Other developers began to wonder if they should drop React Native as well, and Braus Blog tried to …