﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>jdn commented on Beyond mere software design</title><description>"A lot of the problem in software occur when a scheduled job hasn't been running for three months straight."
  
  
Oh, goodness, yes.  Imagine the panic that comes from the top when the new system isn't generating a certain report correctly.  This can't be, maybe we should scratch the entire system and roll back!!!!
  
  
Uh, that report hasn't been generated properly in three years.
  
  
Ouch.
</description><link>http://ayende.com/3493/beyond-mere-software-design#comment5</link><guid>http://ayende.com/3493/beyond-mere-software-design#comment5</guid><pubDate>Wed, 06 Aug 2008 13:42:25 GMT</pubDate></item><item><title>Ayende Rahien commented on Beyond mere software design</title><description>Yeah, and grepping is OK solution for short things.
  
Or you can generate a log file for each client / order
</description><link>http://ayende.com/3493/beyond-mere-software-design#comment4</link><guid>http://ayende.com/3493/beyond-mere-software-design#comment4</guid><pubDate>Wed, 06 Aug 2008 12:21:48 GMT</pubDate></item><item><title>Rik Hemsley commented on Beyond mere software design</title><description>Filtering would be easy and quick if the log was going to stay in a database table, but I'm going to have to move it to log files as the database is too large for MSDE (and possibly SQL Server Express) which is what our customers are using.
  
  
So that would mean grepping...
  
</description><link>http://ayende.com/3493/beyond-mere-software-design#comment3</link><guid>http://ayende.com/3493/beyond-mere-software-design#comment3</guid><pubDate>Wed, 06 Aug 2008 12:19:35 GMT</pubDate></item><item><title>Ayende Rahien commented on Beyond mere software design</title><description>This is something that you can solve easily with just filtering, no?
</description><link>http://ayende.com/3493/beyond-mere-software-design#comment2</link><guid>http://ayende.com/3493/beyond-mere-software-design#comment2</guid><pubDate>Wed, 06 Aug 2008 12:09:09 GMT</pubDate></item><item><title>Rik Hemsley commented on Beyond mere software design</title><description>I recently developed a system which takes orders for documents as input and, depending on a large number of rules, may or may not send out document(s) to fulfil that order.
  
  
Logs are kept which state why decisions are being made, but they have a problem: Processing correctly and efficiently requires several stages. When information is written to the log, it ends up like this:
  
  
Order X: Something happened.
  
Order Y: Something happened.
  
...
  
Order X: Something else happened.
  
Order Y: Something else happened.
  
... etc.
  
  
The real log has many more entries than this example - so for our customers, viewing the full list of decisions made about Order X is painful.
  
  
Having the ability to find out what decisions were made about individual orders isn't something that's vital to the product, but it's certainly annoying for me (and some customers) that it's not as easy as it should be to extract this information.
  
  
Perhaps some day I'll get the chance to work on the system again and will come up with a better way to log - or to present the logged information.
  
</description><link>http://ayende.com/3493/beyond-mere-software-design#comment1</link><guid>http://ayende.com/3493/beyond-mere-software-design#comment1</guid><pubDate>Wed, 06 Aug 2008 12:07:25 GMT</pubDate></item></channel></rss>