I see a lot of development advice that assumes the developer is working on a green field application. Many of the tools that “make a developer’s life easier” are also designed mostly for use in creating new applications. Most of my experience as a professional developer (or whichever title you prefer) has been improving and fixing code that has already been in existence for a number of years. Much of this advice and many of these tools result in more work for the people who will maintain the code.
As I have been working on Ruby on Rails for the last few years, I see a lot of this as a result of the professed optimizing for developer happiness goal. Rails, for example, has several features that optimize for ease of writing an initial application. The whole Convention over Configuration mantra makes initial creation easy if you are willing to follow the conventions. You can save writing a bunch of boilerplate code, because “all of Rails works this way”. You can easily spin up a new application that has similar functionality to other applications, because we all follow the same conventions.
When you are building a green field application, that’s great. It helps you get things up and running faster. But, what does it look like when you are maintaining a production application years later. The first thing to know is that the conventions have likely changed. (Hopefully we are all learning new ways to do development and improving our processes. Therefore, the conventions that seemed reasonable 10 years ago, may not match today’s conventions.) If you were developing a new application from scratch today, you’d obviously work within the new conventions. But, this is older code.
For instance, preferred JavaScript variant, front-end framework, templating language, web app server, etc. have all changed over the lifetimes of several applications I have worked on. This is in addition to changes to the Ruby language itself. Each of these changes (and Rails version upgrades) requires significant development work to incorporate into the running application. Obviously, if the application is in production and important (why would you be updating it otherwise?), making major changes would be risky. Understanding the differences resulting from these changes is required to mitigate any risks of the changes.
Some of the changes I’ve seen have impacted the way the application works in ways that are not always obvious. After all, these changes may have been the result of convention only. That makes it very difficult to search the code for things that have changed.
Conclusion
Features that make initial development simple often have the opposite effect on maintenance work later in the lifetime of the project. Like most decisions in software, this is just another of the many trade-offs you have to make.
The important issue to keep in mind is that the “easier initial development” is likely adding a cost to maintenance, often known as technical debt. Technical debt is not always the result of bad design (as some are wont to claim). It’s often the result of deferring hard or annoying work.