Jos de Jong

When developing a new application, your code base starts small and simple. Over time, your code grows and becomes more complex. It can be hard to fight complexity and keep a code base maintainable in the long run. Here some principles that help me with that. Recon with the cost of maintaining code, not just the cost of development When buying a car, it’s quite easy to reckon with both the cost of the one-time purchase as well as ongoing costs like fuel, taxes, and maintenance. You can calculate the impact of choosing this bad-ass, inefficient car over a small, efficient car in the long run. For some reason, in software development we mostly calculate the costs of developing a new feature only, and tend to forget that every new feature has an impact on the complexity and maintainability of the code, resulting in a “tax” on all future changes in this code base.

A while ago I read the blog post Ranging Near and Far by Scott Sauyet. On Echo JS, Scott titled a link to this blog “Choosing simple APIs over flexible ones”. This title suggests that you have to choose between either simple or flexible APIs, which is a false dilemma. This got me thinking: What makes a good API? Flexibility Scott discusses the API of the range function of Ramda compared to that of Underscore. Where Underscores range supports optional start (defaulting to zero), custom step size, and a negative step, Ramda’s range “only” supports a step size of 1 and does not allow to omit the start value. While Underscores implementation is more flexible, Scott argues that Ramda’s more limited implementation may be the better choice because of its simplicity. Scott suggests that it is way more complicated to use Underscores range because of it being more flexible. Scott has an argument here, but there are more factors determining how easy it is to use an API.