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 »
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 »
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 »
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 »
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 »
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 »
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 »
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 »
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 »
When developing software, there are many different dimensions of risk you might consider. There is an enormous amount of information available on Risk Assessment, consider this to just quickly skimming over the topic. Depending on your understanding of risk (or your paranoia), trying to assess risk can be a difficult task. There are several approaches… Read More »