Standalone Command Line Tools
The writing of standalone tools is an underappreciated part of software development.
Author Archives: G Wade Johnson
Object Oriented Programming Considered Harmful?
I realize that the title of this post is likely to generate a lot of noise, but it’s a subject I have been thinking about for much of the last two decades. Over ten years ago, I wrote a post questioning the everything is an object approach several languages seemed to be taking. That post… Read More »
Why Learn Complex Tools?
I recently ran across the article Why use Vim: Forget easy-to-use design. Choose something hard instead — Quartz. This article suggests that you should learn to use the vim editor because it’s hard. Although I do think most developers would benefit from using an editor like vim, I feel like the because it’s hard advice… Read More »
Proficiency Revisited
Long ago, I posted a short note On Proficiency where I noted four things I believed were needed to become proficient at an activity: aptitude, interest, knowledge, and skills. My experience learning software development took a different route than many developers today. I started development in very small teams (1-2 developers). I had actually been… Read More »
“Learning by Doing” is Not Enough
I’ve spent a fair portion of my career teaching and mentoring other programmers. Some of this training involves covering basic programming and design concepts that they may not have learned previously. When covering a fundamental concept, I often defer to books written by people much smarter than I am rather than explain the concept myself.… Read More »
Another Side of Good Naming
In previous posts, I’ve talked about the importance of naming to make it easier for whoever maintains the code. One thing I’ve left out is the importance of not misusing standard names. Naming Fail In a previous position, I was manipulating a collection of data, when I hit a bug. After running some new code,… Read More »
Incident Handling
No matter how careful your testing, no matter how complete your review, there is a non-zero probability that releasing your new code will expose a problem. The last phase of risk management is handling a risk that actually manifests. At the end of the last post, I mentioned the importance of post-release testing and an… Read More »
Mitigating Risk
You’ve carefully assessed the risks in your new system. You’ve considered the implementation and eliminated bad implementation decisions and removed unnecessary features that involved extra risk. Considering the result, you note that there is still risk. So, what do you do? You try to mitigate the remaining risk. Risk mitigation does not remove the risk… Read More »
Eliminating Some Risk
Many people doing risk management assert that you cannot eliminate risk. Those people are partly right. If you are willing to modify the functionality of a program or system, you can eliminate some kinds of risk, Obviously, this is much easier early in the design or implementation of a system. Trade-offs to Eliminate Risk Part… Read More »
Inherent Risk versus Accidental Risk
One way to think about risk is to decide if a feature is naturally risky, or if the risk is a result of the implementation of the feature. Stealing some terminology from the description of software complexity, I call these Inherent Risk and Accidental Risk. Risk Creep Sometimes unnecessary risk creeps into a system through… Read More »