May 20, 2008 at 2:43 am
A good article. 🙂
May 20, 2008 at 4:25 am
Cade Roux (5/19/2008)
I love this:I've learned that when business people tell me that getting to market is more important than running their business well, I'm only there to postpone the inevitable business failure. And when they tell me that they are the business people and I need to let them do what they are good at - they don't even deserve that life preserver.
But then again when they listen to you and sit developing enterprisey applications for the next 3 years, implementing massive infrastructure and spending stupid amount of money to satisfy your search for perfection prior to go live, the market opportunity has passed and you are redundant.
Instead they push it through and rely on their highly paid (or not) technical staff to fix it or work around the issues before it becomes a business killer.
May 20, 2008 at 6:28 am
RichardB (5/20/2008)
Cade Roux (5/19/2008)
I love this:I've learned that when business people tell me that getting to market is more important than running their business well, I'm only there to postpone the inevitable business failure. And when they tell me that they are the business people and I need to let them do what they are good at - they don't even deserve that life preserver.
But then again when they listen to you and sit developing enterprisey applications for the next 3 years, implementing massive infrastructure and spending stupid amount of money to satisfy your search for perfection prior to go live, the market opportunity has passed and you are redundant.
Instead they push it through and rely on their highly paid (or not) technical staff to fix it or work around the issues before it becomes a business killer.
Actually, the original suggested EAV design here is the enterprisey, over-built one and is typical of architecture astronauts.
A good business person recognizes when a project is a failure, cancels and starts over.
May 20, 2008 at 11:27 am
A good business person recognizes when a project is a failure, cancels and starts over.
A better business person recognizes that starting over is simply courting failure.
The "let's start over" is worse than the "let's accept the current issues and try to improve what we can" method. Instead of continual improvement, even perhaps to a flawed system, you're going to have a time-lag until the new system is in place, and this lag can be fatal to the business.
If we were talking about code, instead of databases, my advise would be to refactor instead of rewrite. When it comes to databases it's a little trickier, there are still options, one of which might be to just accept that the schema has flaws and live with them.
May 20, 2008 at 11:47 am
According to the article, the system is not in production. It shouldn't have been allowed to even get this far.
If a system is working, needs tweaks and performs acceptably (even if it takes a minute to do what a properly written system can do in a second), sure patch it up until you have time for a re-write. No system is perfect. Or use views, indexes, whatever you have to do to work around a bad model.
In this case, you aren't in production and you have a major design flaw - you've got to bite the bullet.
You will pay either way - just like with testing - every system is tested, whether by you or by users - either way you WILL pay. I'm not a fan of big up front design or waterfall, but all those people's studies show that defects grow by order of magnitude in cost to correct as you go from design to construction to testing.
It's not just the business' fault - sound like some "architect" went off on some tempting over-abstracted EAV model and never came back down to earth and no one called BS on it. But when the business ignores a truthsayer at an important late stage, it could be a sign of general blindness and self-deception in the business. In fact, it could have helped contribute to no one speaking up earlier. Identifying these things early through open communication is important for technical people to make the business aware of what it takes to meet requirements.
May 20, 2008 at 1:27 pm
I'm going to go out on a short limb here and say: XML is an even worse idea than EAV. EAV Creates a weak data type design while XML creates a non-normalized weak data type design. You would never design a table that had a field Person that contained this: "FirstName: John; LastName: Doe; BirthDate: 1/1/1980"
So why would you want a field that contained " "
If you have to have customizable fields for searching or reporting purposes, fine, create an EAV table or two for that purpose. But don't design major parts of your database that way.
--
JimFive
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply