Nothing Like Riding the Beast at Night – At Work
I love King's Island's roller coasters, and The Beast is the best. If you ride it at night - right before the park closes it's chilling and thrilling, and no matter how many times I ride it, it's always a new thrill for me. Today was kinda like that - but at work.
So we had 'Launch Day' on Monday, and so as you might expect, there were a bunch of "little things" from the users that needed to be attended to. Certainly understandable, and I've done this enough to know that this is just the way things are… still, like riding The Beast, it's something that certainly gets your heart racing.
First and foremost - it's about time. You have a day to get as many of the "bad" problems fixed, tested and into production as possible. This is because the first impression you gave the users today is going to be supported by the changes you can give them tomorrow. Speed of fixes is crucial in the first days of a project.
Then it's about quality. You can't introduce problems with the fixes, so you have to be careful. This is most often where I have seen a lot of folks stumble. They fix one thing and then break another, and the result is that the users think the development staff is asleep at the wheel. Not good.
So today has been a lot of very fast, very careful work highlighted by the fact that we're really doing the vast majority of the work do deal with crummy sources and sinks of data. I was thinking about this a few days ago, and wondering why this seemingly simple project had so many developers on it and was taking so much time. True, we're ahead of schedule, but that just reinforces my concern.
In Finance, this would have been a few weeks of one or two people - tops. Here's it's much more than that. Why? Well… I came to the realization that about 90% of the code we've written is about dealing with bad sources and sinks of the data. I know the purported benefits of SOA… it's supposed to be great. But that's only true for little things. There's a reason that databases are useful and valuable.
We read a lot of merchant data from an unreliable source. If this were in a database in the data center, then this would be trivial. Likewise for reading the demand data. Updating data would be super easy as we'd have some stored procedure or something to update it.
Yet due to SOA, all this is taking tons of time, and then there's the SSL layer on top due to the fact that a database offers security, but a web service doesn't. It's a mess. But I understand why they are doing it - it's "the way". Still doesn't make it efficient.
I'd love to trade in the sources and sinks for a few databases. The code would be 100x faster, far more reliable, and far less complicated. When I write stuff, I'm not going to let the Kool-Aid get in the way of making a good system.