Are Right A Lot – Page 9 – Making Of Things

User Error Isn’t

By Jud | June 1, 2017 | Comments 0 Comment

It happens to every developer at some point. You spend a bunch of time trying to determine the source of an urgent bug, only to find out the problem was caused by action or inaction of the user. It’s easy in that moment to be frustrated, but may I suggest a more circumspect path? It behooves a thoughtful developer in these moments to consider if the source of the user error was caused by poor design. Perhaps the button wasn’t in an obvious place, or the side effects of the command were not obvious, or the name of the feature didn’t describe the outcome. In many (even most) cases, user error is preventable with good design.

Yes it’s difficult, and perhaps impossible in some situations. But it is the high calling of the software engineer to design products in a way that a user almost subconsciously knows how to operate without error. Viewing design with this attitude saves a lot of frustration.

It might seem this is a counter argument to Not Even Mostly, but actually they go hand in hand. A user must be carefully listened to and considered, but sometimes they must also be guided into the features they really need, versus what they say they want. Do that hard work up front, and you’re more likely to have a system that minimizes the potential for mistakes.

Also, go read The Design Of Everyday Things.

Turn And Face The Strange

By Jud | May 22, 2017 | Comments 0 Comment

Writing requirements is hard. Rarely is enough thought put into them, and even when a lot of time is spent, gaps are inevitable. Thus the most important feature to build into a system’s architecture at the beginning is the ability to change. Without that, all other features will quickly become obsolete.

Every. Single. Time.

By Jud | May 11, 2017 | Comments 0 Comment

Want to know what happens if you don’t follow the Boy Scout Rule of software development? This.

That being said, it can be really easy to get into a vicious cycle of constant rewriting and never releasing. We’ll talk about that tomorrow.

Missing The Mark

By Jud | May 9, 2017 | Comments 0 Comment

Yesterday I made a broad claim about the applicability of various subjects to the task of software development. Today I want to give a specific example from the realm of theology.

The notion of sin is foundational to a number of world religions. Without belaboring the details or arguing the validity of any one definition, what cannot be disputed is that humans have been wrestling for a long time with their own limitations. Why is it that none of us are able to live up to our own ideals, let alone the ideals of a faith tradition? Why must it be that “nobody’s perfect”? To quote Saint Paul,

I do not understand my own actions. For I do not do what I want, but I do the very thing I hate . . . I have the desire to do what is right, but not the ability to carry it out.

Great stories confront us with the fickle imperfections of human nature as well. Is not human frailty and the conflict that arises from it the very foundation of an epic tale? Nothing proves this truth quite like “fiction”.

What does this have to do with software? Let me repeat myself: software is made by humans, and the results are subject to their constraints. That means you can expect both errors of omission and commission, and both unintentional mistakes (e.g. a developer fails to adequately review code) and deliberate laziness, cheating, pride, etc. One certainly hopes for few instances of the latter, but they do happen. It’s not just time you have to plan for.

A process must be designed to recover from its own imperfect implementation, else it is doomed to fail.

The Holy Grail

By Jud | September 2, 2015 | Comments 0 Comment

As of today, I do not think there is a better general purpose language in existence than Python. With few exceptions, it just feels “right”, and without fail writing it makes me happy. Here’s just a couple of my favorite features:

Clean syntax

Python eschews block delimiters in favor of strict indentation rules, which both keeps the code more readable, and forces good formatting. It also requires a minimum of special characters, enhancing readability even further. I work with Perl extensively in my day job, and just look at how much grosser it looks than the equivalent Python:

if ($enemy == 'klingon') {
   firePhasers();
}
else {
   openHailingFrequencies();
}

if enemy == 'klingon':
    firePhasers()
else:
    openHailingFrequencies()

Implementational flexibility

I’m not sure that’s actually a word, but what I mean to say is that Python is a solid choice no matter the design approach you want to take. Writing a simple procedural script? Python does that. Taking an object-oriented approach? Python does that too. Want to dabble with a functional style? Oh yeah, Python’s got your back.

While the purists might say Python isn’t the ideal choice for any of those scenarios, I say it’s probably good enough, and in the real world I’d rather be an expert in one language than a novice in three.

Extensive PACKAGE library

I’m continually amazed at how much functionality is included in Python’s standard library. It makes writing code so much quicker. And if a feature isn’t in a default package, there is a massive ecosystem of third party libraries.

In my next couple of posts I’ll share a few of my favorite of these packages.

To Be Fair

Python isn’t perfect, and there are a couple things I don’t care for. For example, take its ternary syntax:

action = 'punch' if captain == 'Kirk' else 'talk'

I’m generally a fan of ternary operators because of their concision (which is a word I just learned), but the ordering of this construction feels awkward. See, I can be unbiased!