---
title: "Config Hell - continued"
url: "https://osherove.com/blog/2003/4/7/config-hell-continued.md"
canonical: "https://osherove.com/blog/2003/4/7/config-hell-continued.html"
published: "2003-04-07T19:21:00"
updated: "2003-04-07T19:21:00"
tags: []
author: "Roy Osherove"
description: "OK. I got several comments regarding the reasons for Config Files to be Read-Only. \" The main reason for having config files read only, IMHO, is due to permissions issues. Applications are typically installed to Program…"
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Config Hell - continued

By Roy Osherove April 7, 2003

**Historical article** · Originally published April 7, 2003; technical details may be outdated.

OK. I got several comments regarding the reasons for Config Files to be Read-Only.

_"__The main reason for having config files read only, IMHO, is due to permissions issues. Applications are typically installed to Program Files/\*. On a locked down system, its very possible for a user not to have rights to that directory.

http://staff.develop.com/candera/weblog/2003/02/06.html_
"

\[[Matt Berther](http://www.mattberther.com/)\]

That's a very good argument - for why you wouldnt want to implement read-write options in a **specific software you are building**. but definitely not for **all** software products. Since when should something like this not even give you the option to write to the file? let me worry about when i should write to it. hell, most of the stuff i write now uses config files in a very closed and specific environment - where read-write permissions are needed where these files reside. but now i have to implement more code, or serialize my own stuff. point is - you give us something - don't cripple it. 'Write' functionality on config files is just as logical as reading from them. If you want us to steer away from ini files, or registery values - give us something that replaces this functionality at the simplest level.

When i first saw the appSettings thing- i was pretty excited (even though its a small thing). "Yoohoo! No need to write plumbing to save and read simple settings anymore!" . **wrong**. you can read - but **not write**. c'mon! give me a break!


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/