October 1, 2010 at 2:14 am
salman.samad (9/29/2010)
In today's fast paced environments, it is the Business that dictates technology, unfortunately! When that happens, best practices are normally thrown out the window and cutting costs and unrealistic timelines are what become priority, causing bad designs and software applications that can barely do what is required.
I couldn't agree more. These days, cost cutting is uppermost in the mind of management and as a result corners get cut. Over recent years I have noticed a trend for management - particularly in the business - to be very blinkered in their approach to software development, looking at the here and now of costs and not how much pain bad design will cause further down the line.
The other aspect to it is that tools like Excel and Access make it easy for users to create their own apps and think they are IT experts. Then when things start going wrong or they find the DB is not scalable they come running to IT expecting us to take what is there and make it right. So then, of course, it becomes IT's problem and IT people get the flak for badly designed DBs and apps!!! I agree with Steve's analogy with tiling and it should apply to the business as well - after all, isn't that why businesses have an IT department?
October 1, 2010 at 6:39 am
CirquedeSQLeil (9/30/2010)
Great points. That little attention to detail and taking just a little bit longer to do good design in the beginning will inevitably save time down the road.
Thanks, but you are thinking about it all wrong.
I don't take the time to document the database because "one day, down the road" it will save me time. That justificdation for action is the kiss of death for any methodology, and you can quote me on that. If a step in a methodology does not provide immediate value to the person doing the task, it won't get done by more than 1% of the developers.
I take the time to document the database because it's the fastest, safest way to do the database design right.
I have a very specific definition for the methodology I use to build systems. My methodology is the fastest, most efficient way I know to build the system at the desired level of quality. That's why I never abandon my methodology under time pressure, unlike most people in this profession, who abandon whatever methodology they use at the slightest amount of pressure.
If I can't quickly write a 1 to 10 sentence paragraph that explains what the table means, I don't understand how to use it. If that definition and the name of the table don't exactly agree in meaning, the design is wrong. There are other entities hiding in that table and I need to rethink the design until I winnow them out.
Ditto for the columns. Most columns only take a single sentence, and many of those sentences can be cut-and-pasted from one column to another. If the definition and the name for the column don't agree exactly, something is wrong with the model. If I can't write a definition easily, then something is wrong with the model.
Definitions are written so that they can be plugged directly into the help text for any application referencing the table or column or relationship. If the table is an abstract one, it includes several non-abstract examples of use in relevant business terms.
I ask a set of patterned, repetitive questions about each and every table to help me find the correct uniqueness set(s) of columns, relationships and their degree of permanence, and other commonly recurring business rules.
Think of this documentation as a thorough design review without the scheduling problems inherent in getting several others available.
Also, as I build the model, I explain portions of it to others. The act of explaining it helps crystalize my understanding of the problem domain and reveals inconsistencies and mistakes.
In effect, I write the table and column definitions in my head while I'm working on the draft versions of the model. I only write down those definitions when I'm fairly satisfied that the model is a keeper. That's because, until I think it's ready, I might trash a half a dozen table designs and start that portion of the model over. There's no point in having the definitions written down just to toss them.
October 1, 2010 at 7:24 am
david_wendelken (10/1/2010)
My methodology is the fastest, most efficient way I know to build the system at the desired level of quality. That's why I never abandon my methodology under time pressure, unlike most people in this profession, who abandon whatever methodology they use at the slightest amount of pressure.
Well, bully for you that you are not under any pressure to deliver according to set objectives that penalise you for not meeting timescales and will result in you being fired because you haven't met them!!! Unfortunately some of us are employees for companies that only care about how much it's costing them and we don't have the luxury of freedom of choice or time. All we can do is highight to our managers (in writing) the impact of not doing the job properly. And get fired when we go against what we are told to do... And while it might be easy to say "leave, then" - have you seen the job market recently?!? And unless you run your own company you will always have to work to the cost restraints of the company that employs you.
Think about what you are writing. Most of us who care enough about our work to contribute to forums like this DO want to do things properly and do not "abandon whatever methodology they use at the slightest amount of pressure" without fighting their corner. Unfortunately some of us live in the real world of business users in corporates not listening to us.
October 1, 2010 at 8:33 am
Lynchie (10/1/2010)
david_wendelken (10/1/2010)
My methodology is the fastest, most efficient way I know to build the system at the desired level of quality. That's why I never abandon my methodology under time pressure, unlike most people in this profession, who abandon whatever methodology they use at the slightest amount of pressure.Well, bully for you that you are not under any pressure to deliver according to set objectives that penalise you for not meeting timescales and will result in you being fired because you haven't met them!!! Unfortunately some of us are employees for companies that only care about how much it's costing them and we don't have the luxury of freedom of choice or time. All we can do is highight to our managers (in writing) the impact of not doing the job properly. And get fired when we go against what we are told to do... And while it might be easy to say "leave, then" - have you seen the job market recently?!? And unless you run your own company you will always have to work to the cost restraints of the company that employs you.
Think about what you are writing. Most of us who care enough about our work to contribute to forums like this DO want to do things properly and do not "abandon whatever methodology they use at the slightest amount of pressure" without fighting their corner. Unfortunately some of us live in the real world of business users in corporates not listening to us.
You did not understand my point. (That may be because I did not make it clear 🙂 or because of preconceptions on your part. 😉 )
I'll try to explain my point again. Maybe I'll do better this time. 🙂
I have to do a data model under time pressure. Always. I work in the real world also.
There is never enough time to do things perfectly. Ever.
Various managers over the years (but of course not the ones I have NOW) have insisted on my doing stupid things.
So, we've got the same experiences when building software.
As for your point about forum readers caring about their work, you are quite correct. Then again, MOST developers aren't regular forum readers, are they? MOST don't take part in user groups. MOST don't work at home on their own to master their craft. MOST don't take the time to write up what they learn and share it with others, via publication or presentation. And MOST will abandon whatever methodology they pretend to use at the slightest excuse.
You aren't one of them and most of the regular contributors and readers of this forum aren't either. We're a minority in our field.
No insult was intended or, to my mind, delivered to you. An insult was intended for MOST developers, but since they don't read this forum, it wasn't delivered to MOST of them. 😉
Here is where I believe the preconceptions may be at play.
Many people believe one has to choose between Fast or High Quality.
It has been my experience, and it's been documented by people like Capers Jones in his productivity studies, that Fast and High Quality usually occur together, not in opposition to one another. In general, the fastest programmers have the least errors.
I'll discount the possibility that a programmer intentionally does bad work in order to be fast because, although possible, it's not been my experience that that's a motivating factor at any statistical level of importance. Most who do bad work do so because they don't know how to do good work - at any speed.
I'm ignorant about a lot of things. That doesn't make me stupid, just ignorant on those things. For example, if we're flying on a plane and the pilot and co-pilot drop dead, and you put me in the cockpit to land the plane, start praying. Because I'm ignorant about how to fly a plane. The odds are overwhelming that the plane will crash. Given time, training, and a safe opportunity to practice, I could be a good pilot. But not in the first circumstances. Data modeling or application design is no different.
Someone who doesn't understand relationships between data, doesn't understand precisely what subset of relationships a foreign key constraint supports, doesn't understand how to determine what makes a record unique, puts the foreign key column in the wrong end of the many-to-many, doesn't understand when to use a many-to-many vs. a one-to-many or a one-to-one, doesn't understand orphans or normalization, doesn't know how to interview people or interrogate documents for clues, etc., will muddle and muddle through doing a data model. They can work on it until hell freezes over and they will still produce a bad model. But, given the time pressures they will be under, they won't. They'll stop before they think they are done, and blame it on not having enough time. I'm not saying that's what YOU do. I'm saying that's what all to many developers do - because they don't know how to do it right. Because they don't know how to do it right, they don't know how to do it quickly. They don't know what is essential to know and what is not. Or how to quickly learn what they need to know.
Most people think "following a methodology" is this paperwork, task-filled process where you do all kinds of extra steps. It's very top-heavy and all the benefits are to be experienced some fine day in the future.
That's why so few people do it at all, and why most who do abandon it at the slightest schedule pressure. Because they define it as a bunch of extra, nice-to-have steps.
I don't define my methodology that way at all. Any methodology created with that mindset will never be used except under constantly applied duress.
I figure out the best, fastest way I know how to get the job done at the level of quality desired. If the level of quality desired is "it needs to work most of the time right away", then that's the level of quality that I need to reach at a minimum. If the level of quality desired is "always works", then that's what I aim for. I clearly document the scenarios that I'm not handling correctly (that I'm not aware of), in business terms, and ask if the business benefit of handling those scenarios outweighs the extra time or expense of solving the problem. Since that's a business decision, not a technical one, business people can make a good decision about which choice to make.
The way I choose may not be the best, fastest way possible. But it's the best, fastest way I know.
I don't abandon my methodology under time pressure because, by definition, it's the best, fastest way I know how to get the job done at the level of quality I'm aiming at. Any other approach, by definition, is slower, so I would be a fool to use it when I'm in a hurry! 🙂
When I build systems, I constantly evaluate the approach I use. If I think of a way that might work better/faster, and time pressure allows, I'll experiment with it. If not, I'll stick with the tried and true. That is, unless the time pressure is so intense that the new way is the only way that might work. But my criteria for changing under time pressure is "faster and not worse", not "faster".
As for management giving bad instructions on how to do things, I studiously avoid ever discussing the technical or process details of my work with anyone who has the authority to order me to do things differently - unless they have a proven record of really knowing their stuff. Why? Because you never ask a question you do NOT want the answer to!
"Hey, boss! Can I do things the way I think will work, or do I have to do things the way that is doomed to fail and will make my life a living hell?"
Why would anyone ask such a question? I've seen it asked all the time, just not with those exact words. Don't ever ask a question like that!
October 1, 2010 at 9:28 am
Incidentally, the single best book I've ever found for learning how to think correctly as a data modeler can be found here:
I've found that once someone understands the true definitions of the entities being modeled, the model is very easy to do. Learning how to do that is not easy and this is the best book I've found that gives one example after another of how to think the right way and ask questions the right way. It's called the Socratic Method.
FYI, if you start learning the Socratic Method, brush up on your people skills at the same time. Socrates was executed for making important people feel and look stupid with his questions. It's important to balance those two issues our you'll know what needed to be modeled at your ex-job. 🙂
October 1, 2010 at 9:47 am
David,
Very interesting points. Interested in walking through an article or two with a real system? Maybe something like SSC or a blog site and do a data model?
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 1, 2010 at 9:58 am
Steve Jones - Editor (10/1/2010)
David,Very interesting points. Interested in walking through an article or two with a real system? Maybe something like SSC or a blog site and do a data model?
Sure. I've published papers on these topics before, but in the Oracle world.
I'll dig them up, convert them over to Sql Server examples, and send them to you.
March 10, 2015 at 10:37 pm
Biggest problem with the tile analogy is this: Ctrl+Z wont remove them
March 11, 2015 at 2:52 am
marcus.scholz (3/10/2015)
Biggest problem with the tile analogy is this: Ctrl+Z wont remove them
This comment and the editorial made me laugh.
At one client, we once were attempting to take on a contract expert/senior C# developer. We had to sift through hundreds of CVs from an agency. One was from someone who less that 12 months before was a bathroom and kitchen tiler. Nothing wrong with his career change but the agency expecting him to be considered an expert who can "hit the ground running" with no relevant education, little irrelevant education and less than a year in the industry was ridonkulous!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 11, 2015 at 2:54 am
Stephen Hirsch (9/29/2010)
How did "designing databases" get separated from "development" in the first place? DDL is as much "code" as C#, Java, T-SQL, whatever.<rant>
Please, please, please people, please stop using abbreviations! Please stop removing vowels! There used to be a reason to do that, but there isn't anymore. Physical names should be the same as logical names, at least 99% of the time. A reasonably intelligent native speaker should be able to read the physical names and understand what it's supposed to be/do.
</rant>
Yes. In most languages.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 11, 2015 at 3:00 am
David Data (9/29/2010)
Round about 1980, I set a design standard for my department, which started withDNT ABRV8
Surely you mean "Around about 1980". Those pesky missed vowels!!! 😛
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 11, 2015 at 3:00 am
A very interesting discussion and what's making it more interesting is it's 5 years old and things aren't getting any better.
I fancied the points about methodology. "Working people" are scared of methodology imposed from above - from people that aren't using it - in an attempt to streamline, control and manage what they don't understand.
Methodology is something that emerges from below, is an optimization of steps involved in a process that only the person actually performing the task can evolve and improve.
Over the years I've become a victim of bad database design myself. From stupid minor things like "micpeled" field names that find themselves into indexes, stored procedures and reports before they can be corrected to ugly additions of 10 integer fields into a 10.000.000 row table to hold fields that perhaps only 0.1% of the rows will need.
Be it bad database design or coding practice, it all boils down to people doing this for a living and not because they enjoy what they do and they try to excel in that.
March 11, 2015 at 5:55 am
Over the years, I've started and stopped my e-mail subscription to this site several times.
Inevitably, the stoppages have come whenever I've read an editorial like this one.
Maybe I'm missing the point, but I thought this newsletter was designed to educate ... not to shame. Rants like this one serve no useful purpose whatsoever. This particular rant smacks of elitism -- of the author looking down his nose and thinking that others' skills don't measure up to his own. Nobody is going to read this rant, see themselves in it, and think, "wow, I need to improve my skills right away!"
If you have a problem with somebody's design, it's probably best to take it up with that person directly. Better yet, maybe you should take that effort and redirect it toward improving your own skills.
There's a lot of good information in the daily newsletters. But once again, I have to determine whether the value of that information outweighs the smugness of the delivery in articles such as this one. I suspect I'm not the only reader in that boat.
March 11, 2015 at 6:34 am
jah 73246 (3/11/2015)
Over the years, I've started and stopped my e-mail subscription to this site several times.Inevitably, the stoppages have come whenever I've read an editorial like this one.
Maybe I'm missing the point, but I thought this newsletter was designed to educate ... not to shame. Rants like this one serve no useful purpose whatsoever. This particular rant smacks of elitism -- of the author looking down his nose and thinking that others' skills don't measure up to his own. Nobody is going to read this rant, see themselves in it, and think, "wow, I need to improve my skills right away!"
If you have a problem with somebody's design, it's probably best to take it up with that person directly. Better yet, maybe you should take that effort and redirect it toward improving your own skills.
There's a lot of good information in the daily newsletters. But once again, I have to determine whether the value of that information outweighs the smugness of the delivery in articles such as this one. I suspect I'm not the only reader in that boat.
You are, of course, entitled to your opinion but this was just a call to arms for database professionals to be just that: professional.
Editorials, by their very definition, are opinion pieces. Sometimes on technologies but sometimes on practices. Being opinion pieces they should be written to provoke discussion. You can always ignore the editorials if you don't like them. I would guess that many do just that.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 11, 2015 at 6:48 am
This is why in the old days the conventional wisdom was that the more experienced did more design while the less experienced did the maintenance. It is now reversed. Now, the neophytes create the messes and the experienced persons come in and navigate the treacherous waters they leave behind. This can be a rewarding niche if you are highly skilled(both technically and politically). But be warned. I do not use the term "treacherous waters" lightly.
Viewing 15 posts - 31 through 45 (of 63 total)
You must be logged in to reply to this topic. Login to reply