Sponsored Link •
|
Summary
It's been long enough and I don't seem to be much better off following the advice of these guys.
Advertisement
|
I got to work the other day and an email was in my inbox. It came from someone in the field in the process of getting our system deployed at a customers site. Here's the bit that struck me most (reposted with permission). It's a little long but worth reading I think:
Every day the applications lead and the claims lead spend a couple hours going through every transaction entered the day before, reading through 917-byte records to identify the cause of any upload errors. Tensions are high. Nerves are fraying.
Transaction upload testing is probably the last major hurdle we face before going live. To get an appreciation for what this is like, here's one example. Imagine a Reserve event fires and hands you a $500 reserve decrease. This one event has to be handled in one of several different ways, depending on what fired the event and what else has happened on the claim..
* If it was automatically generated along with a final payment transaction, you have to throw it away and not give it to the mainframe.
* If it leaves open reserves behind, you send an RC transaction with two amounts: the PAID-RESV-AMOUNT is the amount of the new open reserves, and the ORIGINAL-RESERVE is the amount of the change (yes, that's completely counter-intuitive). Since the amount of the change is negative, you have to send the following string, which means -$500: "0000005000}" (that last brace is part of the string and means that the last digit is zero, and the sign is negative; there are nine other symbols for the other nine digits).
* If it leaves no open reserves behind, and there have been payments made on this reserve line , you send a CL transaction, with the amount 0.
* If it leaves no open reserves behind, but there never were any payments on this reserve line , you send an NC transaction, with an amount of 0.
Oh, and all of that only applies to indemnity payments; for other cost types, the rules are different (luckily, they are simpler). And all of that only covers 22 bytes out of a 917-byte record. (They're not all as hard as those 22.) And you have to protect it in front with a battery of transaction validation rules to prevent the user from entering a transaction that will break the upload - like changing a reserve twice in one day (but a new reserve and a change are OK), or entering a final payment the same day as a reserve change.
Then imagine that the client gave you incomplete requirements in the data mapping several months ago, and you don't find that out until your 917-byte fixed-width record errors out on the mainframe upload, and the only way to find out the right requirements is to look at the records that the current claims system is producing.
My initial reaction was to be sort of offended. I mean really, who built such a thing? Mustn't they be embarrassed? A little while later I got over myself and started to think a little more rationally. I realized that it doesn't matter. This is the reality of the world I live in. In some small way I even helped create it. It's a filthy place, filled with exceptions, caveats and halfways.
When I got home I started looking at my bookshelf. It's filled with books on how to write software. Old stuff from Yourdon, some Booch, Fowler, GoF and lots more. I came to the conclusion that these books were written in or for a world that doesn't really exist. To be sure they help me strive for a less disgusting place to live. But they don't spend a lot of time talking about my house, metaphorically speaking.
I think that those who propose to set out to tell me how to develop systems actually live someplace else. Periodically they drop in, they show me some pretty pictures about someplace over the hill that I've only imagined and hoped for. And I look wistfully at those pictures, and listen to their arguments. If I'm chaste enough, if only I have discipline and faith, I too will enter this wonderful place where things always moving forward, where systems flow with the consistency of oil, and everyone is dedicated to the crafting of something right and beautiful.
I think it's a myth. I think I'm very, very far from this place. I think I'm going to stop listening to these guys. I think I'm going to start looking for people who live in my world, who tell me how they slay their dragons and hope I can use what I learn to help slay mine.
Wow, I'm entirely depressed. I'm going outside now.
Have an opinion? Readers have already posted 37 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Rick Kitts adds a new entry to his weblog, subscribe to his RSS feed.
Rick Kitts has been making a living writing software for a little while. He's started a company or two, worked at bigger companies, but mostly at startups. Constantly on the look out for things to help him build better systems he's a bit of a tool and process slut, though he can't bring himself to try C# or get serious about UML. Go figure. He's convinced being invited to have a weblog on Artima is the result of some glitch in the matrix. He's keeping quiet about it though. |
Sponsored Links
|