I'm re-creating a web app (Google Apps Script) that i made a couple months ago, and decided that I wanted to make it fully configurable this time around. So that I don't have to go in any change any code or settings to adapt to new changes in the data it manipulates, queries, and displays. I've also worked to make some optimizations that have increased the responsiveness of the app by nearly an order of magnitude (From 2-10 seconds down to 1 second or less) through caching.

I'm almost complete, and after taking a step back I've noticed my codebase is nearly 3x the size and feels much more complex than it did earlier. I no longer hard code any values or settings, I can swap, add, or remove columns from spreadsheets or databases without breaking the programs behavior.

However, I am not sure if it's "worth" it. I may not have to go in and make changes to avoid breakage, but if I need to jump in a few months from now I doubt I'll understand how my code works right off the bat.

  • 2
    Only you know the answer to this, based on your personal experience with your new web app. Creating generalized libraries and frameworks often causes code increases similar to the one you described, so if it's worth it for those libraries, maybe it's worth it in your web app. If your issue is that you don't think you'll remember how it works in three months, then write yourself a manual. You should do that anyway. – Robert Harvey Jan 19 '16 at 2:39
  • 1
    I am a bit confused. Can you explain how this relates to dynamic-programming? – Jörg W Mittag Jan 19 '16 at 7:39
  • 1
    I took the freedom to replace the term "dynamic" by "configurable". The term "dynamic programming" has a specific meaning, very different from what you obviously want to know. – Doc Brown Jan 19 '16 at 15:53

There is no hard-and-fast rule. But this question should always be considered carefully when thinking of redesigning a system.

In general, it is very bad practice to hard-code any settings into your program. Configuration settings and large external values should always come from files. This separation of data and code (or logic) should, for any reasonably sized application, make your code more readable and manageable.

Generally, this should be a goal from the start. If you find yourself, as in this case, with a messy code-base with hard-coded values strewn around, then you need to carefully consider if refactoring it the "correct" way is worth the cost. Refactoring an existing application is both time-consuming and provides no immediate benefit to end-users (or your employer).

While it may feel bad to have ugly code like this around, in a real-life situation, you often do not have the luxury to polish code to the degree you'd personally be comfortable with. Only once the maintainability of the code becomes a hindrance to further development efforts is a refactor often worth it.

In this case, it is your app, so you are in complete control. Besides, you have already put in the work for the rewrite, so congratulations! However, your code should not be more complex than it was before:

I've noticed my codebase is nearly 3x the size and feels much more complex than it did earlier.

The size increase is expected, but what you mean by "complex" is important there. Do you find the code harder to reason about and navigate? If so, this is a big red-flag, as you wrote all of the code yourself! Imagine if you came in as a new developer to a company and were expected to start working on this codebase. Do you think you'd find it easy or difficult?

On the other hand, if by "complex" you just mean that there's more logic going on, but you still understand it well, then that's less of a worry. If you add more functionality to an application, there's going to be more moving parts. But the overall quality of code throughout the application should remain roughly the same.

  • Thank you for your thoughtful answer. It feels complex in that there is more logic happening, and I have to search through the code to find a method I want to modify. I also need to keep in consideration that I cannot break my model logic apart into classes and files like I would in C# (apps script). So all of the logic is in a single, fairly large file. – Douglas Gaskell Jan 19 '16 at 2:59
  • In regards to navigating the code, this can be largely mitigated with a choice of development environment. I use Sublime which indexes all symbols (functions, classes, etc). IDEs for specific languages (such as IntelliJ) offer even more advanced code navigation features. I've never written a Google Apps Script (not even really sure what it is), but I am extremely surprised that all code has to be contained in one file. I don't think any developer could handle a large amount of code with that restriction. – gardenhead Jan 19 '16 at 3:03
  • Yeah, I'm pretty used to Visual Studio, so I've gotten used to a clean and organized environment (especially "minimizing" sections of code so they are not in your view any more). Apps script is essentially google flavored javascript with it's own little online IDE. It doesn't offer much for code separation, so larger projects get a bit hard to manage. – Douglas Gaskell Jan 19 '16 at 3:07

It sounds like you're weighing the cost of code that's a little more difficult to understand than the original code against the benefit of being able to "swap, add, or remove columns from spreadsheets or databases without breaking the programs behavior", as well as optimizations that speed things up by (up to) a factor of 10 (and maybe more?). Only you can truly answer if it was worth it, but if the improved performance and functionality is something you enjoy more than easy-to-read code (but time consuming to maintain), then it was worth it.

And if you're worried that your fancier code base is harder to understand, then you really want to start documenting it NOW, before you forget how it works.


Did you make the changes based on any specific end user requirements?

  • If yes, it is worthy to users to have that change.
  • If no, did you consider "fully configurable behavior" is really desirable for any foreseeable future requirements that you will definitely implement?
    • If yes, it "maybe" worthy for future changes. I said "maybe" because you can only say whether it is worthy by then, considering the added complexity.
    • If no, did you enjoy or learn something new while implementing the changes?
      • If yes, only you can tell if it is worthy or not.
      • If no, it may worth some reputation points on stackexchange :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.