###X% of Configuration is Never Used

I once worked on a system with in excess of six hundred different configuration points. In reality all but a handful of these would ever actually need changing. Most configuration is added to enable anyone to make the change. Ironically if these configuration points do need changing, developers need to do it. The business or non technical individuals will never change settings. In this scenario you would need to actually test all six hundred different combinations of configuration. 1 on, 599 off, 2 on, 598 off and so on - this is not ideal nor realistic.

600 seems really high to me. I always start off with a hard coded value and if there’s a reason to add a configuration option we’ll add it but never before. I’ve actually had situations where we’ve removed options because they we’re being used.

###Never Use null

When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.

Let’s go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.

I’ve created solutions that return null and I see them as a positive and a negative. It’s nice to have it return a null because then you know it failed but then you have to add an extra check.

###The Bug in the Physical Building

I heard a story on the way to work this morning. This story starts out like many stories about software projects start out: with a weird specification. Of course, I’m talking about 601 Lexington Avenue, also known as Citigroup Center, in New York City. And it’s a true story.

###csvdiff In one of my project we needed to know the differences between two CSV files. This was very helpful for checking out work.

###Today I accept that Rails is yesterday’s software.

###Immutable objects

In this short article we will see what immutable objects are and why we should consider to use them.

I’m a fan already but this is good explanation.

###Long Live jQuery

The reports of jQuery’s death are greatly exaggerated.

jQuery, which reacently announced its first 3.0 release candidate, has been an important tool for web development since its inception. The library provides a rock solid API for interacting with the DOM and other critical browser functions while hiding ugly syntax and awful browser quirks. For all that the ubiquitous library has offered the web, it still gets a bad reputation. It seems to me that people have been calling for its demise for some time, to be replaced with “modern” paradigms like React or Ember or Vue or Angular or your own crappy framework. These frameworks are great, but I believe they do not “replace” jQuery at all. They compliment jQuery and have fundamentally different use cases.

###How PHP 7 & TDD helped me sleep better

###The Quiet Crisis unfolding in Software Development

This article is a very long-winded way to help you learn how to care for your software development employees with best results. If you properly care for your employees they will take care of you, leading to better product outcomes and higher career satisfaction for both you and them.

###Podcast: Full Stack Radio - 42: Justin Jackson - Marketing for Developers This is a really good overview on finding a market for your product and picking what to work on.