One of the things that I'm coming to realize is that sometimes it's much more important to get things done than waiting until you have time to "do it right". Sub-optimal, but done, is better than not done, but with plans on doing it totally "right". Of course this sub-optimal solution has to be weighed against not doing anything at all. You don't want your half-assed solution to actually cause more work.
Examples work best for me. For one of the COTS apps that I help take care of, it comes with logging configured to create a new file each day and never clears out the old logs. And it logs a lot - somewhere in the range of 1 G + / week. The "right" solution would be to look into changing the logging level and how the files are created. The sub-optimal solution I did was write a cron that finds all files older than the last 5 days and delete them. Not ideal, but it's done.
Done half-assed is better than done no-assed, as I always say. Well, that was the first time, but I'm sure that I'll say it some other time too...
"Get 'r done!"
ReplyDeleteOne thing that you have to watch out for is that you have to make sure you go back and fix it later the right way. I find this happens a lot in software development. You do something quick and dirty to get it out the door, but you don't take the time to refactor so that the code is easy to maintain. This can have really bad effects, especially if you aren't careful. Therefore whenever possible, I try to do things as correctly as I can the first time, so as to avoid the problem completely.
ReplyDeleteBut that's my point Kibbee, you *don't* always have to do it the "most correct" way. The "mostly correct", if it works and has a similar maintenance cost, is just as valid.
ReplyDeleteGetting things done *now* and allowing you to focus on other tasks can negate any costs that you might incur maintaining the non-optimal solution.
I guess it's more along the lines of "Do The Simplest Thing That Could Possibly Work"
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
I agree, so long as your solution is "good enough". Is your solution only kind of gets things done, but doesn't really, than you will probably regret it. To compare it to your original example, If (hypothetically) you cron job left an extra 10% each time so that over months it would build up and eat all your space, then it wouldn't be a good enough solution. You would reduce the frequency with which you would have to do it manually, but it still wouldn't really work.
ReplyDeleteAnyway, I think your cron job is actually a better solution than reducing the logging, because even if you reduce the logging, you still have to delete it every once in a while. Also, you can look into the logs if you ever need to, so long as you don't need to look too far back.
You can configure loggers to "roll". e.g. keep up to 4 files, 25mb each. You'd never have to manually delete anything.
ReplyDeleteAgreed Jim -- and I'll go further: I'm a fan of doing the simplest (and quickest) thing possible to get the job done and move on. That's the agile way.
ReplyDeleteElegance has no place in real-world software, it's masturbation. When you bill clients by the hour on an agile project, it becomes that much more REAL. There's no time to fart around making things look pretty.
XP (extreme programming, 10+ years old now) says to refactor code before you write a new feature in that area of code, not refactor after. I've always tried to follow that advice.
That doesn't mean you sacrifice readability - readability is critical for agile development. You sacrifice a little code/architecture elegance for speed of development.