Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
Not Even Mostly

Not Even Mostly

By | | Comments 0 Comment

Customers are a finicky bunch (they’re human, just like everyone else). That means they’re not always right, and any business practice that assumes they are is likely to fail in the long run.

Don’t hear me wrong, I’m not saying that software engineers shouldn’t listen to customers. Nor am I saying businesses shouldn’t careful consider their customers’ demands and in certain situations give in. I’m really speaking more to an attitude of continual acquiescence. That’s not helpful for a customer who may not have the skill to evaluate what he wants, and it’s not healthy for a developer when they see their professional opinions thrown to the wayside.

If a relationship isn’t a two-way street, it’s probably not worth having.

Turn And Face The Strange

Turn And Face The Strange

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

Trump Card

Trump Card

By | | Comments 0 Comment

I’ve had the opportunity to perform a bunch of job interviews in the past couple of years. It’s been a tremendous learning experience, and I’ve enjoyed contemplating the various psychological factors that go into both interviewing and being interviewed.

My quip from a few days ago was mostly tongue-in-cheek (sorry, dear wife), but if you do want to impress me in an interview, take some time to tell me everything you don’t know. Yes, you read correctly. I want to hear about your ignorance.

You see, there’s a well-documented psychological phenomenon called the Dunning-Kruger effect. It’s a cognitive bias where the incompetent person, due to their incompetence, lacks the skill to evaluate their own shortcomings, and hence overestimates his own capabilities (the opposite effect is known as Imposter Syndrome). I’ve seen these play out time and time again as I’ve evaluated job candidates; in fact, I know of no quicker way to get a general sense of a person’s skill. Besides, describing shortcomings demonstrates humility and self-awareness, two valuable personality traits in any field.

The domain of software development is immense; no single person can possibly know even one-tenth of one percent of what can be known (we’re all only human). The best developers know this, and can describe the boundaries of their own knowledge. Those who cannot probably have no idea what they’re doing.

On The Shoulders Of Giants

On The Shoulders Of Giants

By | | Comments 0 Comment

Last night I wrote my first Cordova Plugin (a little tool that allows an app to determine the local IP address on a Windows 10 device). I was proud of my success given limited documentation and a poor development environment (just a Surface 3 and command line tools).

What made me particularly excited, though, was that I could give my update back to the open source community via Github. Every developer on Earth has benefited greatly from the availability of high quality and easily modifiable free software, myself not the least. I enjoy every opportunity to give back in some small way, and I encourage all developers to do the same.

If nothing else, it makes your résumé significantly more attractive.

Finish

Finish

By | | Comments 0 Comment

Does anyone else have a hard time finishing a project? I suspect it’s a common theme among developers. At the beginning, a project is fresh and new, and it’s fun setting up new tools, cleaning the slate, and getting that first prototype up and running. But as time goes on and the needed features pile up, excitement wanes. Your clean initial bits of code have been cluttered by refactoring and redesign as requirements evolved and unexpected complexities emerged. What was once new is now routine when you’re adding feature 42 of 50, and by the time a task is 90% done, you’re tired of looking at it and desperate for something different.

You’re not alone in this feeling; it’s a well documented phenomenon across a variety of creative disciplines. But fight that tendency, my friends, and push through, because a finished imperfect project is better than a perfect unfinished one.

My theory is that the inability to finish is a combination of the 80/20 rule, unavoidable code rot, and the Creator’s Curse. Naming these issues is the first step to mitigating them, so don’t be afraid to call them out when you see them, both on your team and especially in your own work.

I know personally it was a barrier to getting this blog going again, and it’s a problem I still fight. Am I totally happy with this post? No, not really (writing it while trying to listen in on a teleconference doesn’t help). But I’m clicking publish anyways.

Every. Single. Time.

Every. Single. Time.

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

Scouts Honor

Scouts Honor

By | | Comments 0 Comment

Yesterday we looked at how theology can inform software development, today we consider physics. The second law of thermodynamics states:

The total entropy of an isolated system can only increase over time.

This statement has a specific technical meaning which is worth investigating on its own merits, but the general principle is that systems tend towards decay. Software systems are no exception to this rule, variously described as software entropy or code rot. Anyone who has worked with software for any length of time knows firsthand how clean code quickly devolves into spaghetti.

How can one combat this seeming inevitability? The key lies in the second law and the little phrase “of an isolated system”. Essentially entropy can be held steady or even reversed in a system if it is properly influenced from outside that system. In the world of software this means that every time a change is made, one should not just do the minimum required to implement the change, because any edit likely increases entropy. Instead the developer must go further to leave the code better than she found it (what Uncle Bob described as the Boy Scout Rule). The best developers work to make this second nature.

Yes this takes more time in the short run. But it’s essential to the long-term health of a software system.