This is feloneouscat's Typepad Profile.
Join Typepad and start following feloneouscat's activity
Join Now!
Already a member? Sign In
Recent Activity
We have a ball of mud. We never seriously tested it (our customer did, but their management was seriously whacked about what results were important). A few rollouts turned into several hundred. New management came in (customer side) who had two pennies to rub together and said "these numbers are whacked - make it work accurately" (fortunately they didn't say perfectly). The major problem is that this is an open looped design that attempts to track queued up customers using two points. However, at any time a customer can leave the queue. We get a mostly unique key from the first point, but only "customer here/isn't here" from the second point. The rest is guesswork, innuendo, and "what if's". I've tried to point out that without a way to resync our internal queue with real life, we can only have an EPIC FAIL. I've been told (in so many words) I'm depressing and we can do it... we just have to figure out how. The text in this blog MOSTLY is a result of poor planning or design. It doesn't even address the case where the initial idea was flawed from the start. Many times I have seen clean, elegant code turn into balls of mud because people at the last minute have decided to a) make huge changes in the project or b) keep tacking on more and more crap that exceeds the original design goals. Chernobyl was NOT an EPIC FAIL because of design - it was best practices AT THE TIME. It was an EPIC FAIL because even when it was determined it was a bad design they continued to use it (much like the reactors we have on fault lines in the U.S. or the Fukushima Daiichi reactors). When we set the parameters to meet the device or the code, not the other way around, THEN you are set for disaster.