Whilst reading through some of the other SQL Server forums, I am always struck but the strange air of unreality of the advice given by some of the experts. Their advice is not always tempered by the necessary compromises of the rough-and-tumble of real life. They argue for planning, getting the data schema right before starting, insisting on uniformity of data being imported. They seem to be able to dictate their terms to their users. They seem to live in a harmonious rational universe so far removed from real life I imagine them in cloistered communities, sitting there in peace with nature as dappled sunset flickers through the gothic windows.

Am I the only one who gets impossible deadlines, bosses who behave like extras in a Typhoo Tea commercial, and users who haven't a clue what they want but are certain that it is not what you are attempting to provide, even though it is what they asked for in the first place?

A few points:

A) Many of the "experts" are trainers who have not worked a day on a real project for years.  These people are totally out of touch with the realities we face on a day-to-day basis in the trenches.

B) That said, even though these experts are arguing for what may not be possible today or tomorrow, I think they make a good point -- push, push, and push some more until your clients/customers/managers start moving towards the right way of doing things.  Many of the headaches I deal with every day would never happen if people spent more time doing a little bit of upfront thinking and less time trying to hack things together with incomplete ideas of where they're actually headed.  The best project I've done in the last five years was a six-month development effort, but before we started development we took two months and had daily meetings during which we carefully architected the whole solution.  The end result was a truly great product and I believe that had we not planned in advance we would have spent over a year in development, rather than six months.

C) As an educated member of the community, it is your job to spread these ideals!  Teach your boneheaded bosses how to be proper bosses.  Teach your clients that specifications are necessary.  Refuse to work without them!  Come back later and get paid double to fix the problems that occurred because they didn't listen to you the first time.  I don't know about where you are, but here there are enough projects that I do have some flexibility when it comes to saying "no" to those that I foresee as nightmare scenarios.  Exercise your right to speak with your feet, and do so.  Eventually, these people will learn...

---

Looking for an advanced SQL Server 2005 book?

Expert SQL Server 2005 Development

Users aren't generally good at saying what they want, but they're usually pretty good at validating whether your design meets with their needs.  The trick is to take time to understand what they are really trying to achieve and take their ideas with a pinch of salt.  Test your ideas of a solution early before coding has started in earnest.

>>>They argue for planning, getting the data schema right before starting, insisting on uniformity of data >>>being imported. They seem to be able to dictate their terms to their users. They seem to live in a >>>harmonious rational universe so far removed from real life I imagine them in cloistered communities, >>>sitting there in peace with nature as dappled sunset flickers through the gothic windows.

 

Oh boy, you got me started.

 

1) You cannot say that being strict in designing things right the first time in accordance to business requirements isn't the right thing to do.  The problem with thinkers such as yourself is that you forget one of the most important rules of our profession:  You must think ahead.  You must think about your design now per the business requirements as in proper design correctly the first time.  Because 3 years down the road, if you don't you'll be fixing all those compromises you gave to the users about not cleansing the data well, not designing the tables and UI correctly per rigid standards on the technical side, and will be wondering why your users are still complaining about a UI that looks pretty but still doesn't   SERVER THE BUSINESS NEEDS

 

2) I'm sick of hearing how programmers don't care about the business requirements and that we are being overly rigid on process and overly concerned about design...in that users don't care about how we do it.  The fact of the matter is, there has to be a compromise on the USER SIDE, not just US PROGRAMMERS.  Too many managers who are non-technical shoot us down and do not compromise and wonder why we fight for certain standards that they have no clue about because they are non-technical.  What we are attempting to do is to ensure we meet those business requirements outlined in the meetings without creating a piece of SH%% for you so stop crying if you can't enter every field as a textbox and instead we are FORCING you to use drop downs for example.  (Actually that was a real fight I had to go through, which about drove me to hang myself).

 

3) I have heard so many times from managers "You are talking to the users about stuff they don't care about, all they care about is that you meet the goals".  Screw this.  Managers who talk like this don't deserve and are not qualified to be a manager.  Why?  They don't give a sh&& about process period.  If they did, they would support you and explain to the  users with you why or why not some items on the business requirements have to be done a different way, so that the technology design can work flawlessly for them now AND IN THE FUTURE

 

4) Speaking of future, isn't that what you programmers are supposed to be thinking about first and foremost in SQL or any application design?  Table design, whatever it is.  If you don't then you will run into problems later or run into the limitation that your entire application sucks and you should just purchase another sh&& third party solution and start the whole damn sh** process over again

 

5) I like to go home and spend time with my family.  Some people feel that us programmers (or DBAs, whatever, we're all in the same line of business) are too overbearing with our concerns.  Well, here's news for you buddy manager: I like to go home to eat my dinner, not sit here and fix poor design because I had no support or compromises from the business users on design on their part...because I was expected to put up, shut up, and design a sh** application.  I feel like the guy from Office Space, the nerd who tries to talk...what's his name?  The guy in the basement.

 

6) Managers who do not let themselves or their developers devote a significant amount of time planning before "whipping the solution out" are managers who should be fired.  Now, in regards to Agile Devleopment, I'm not saying spending 1 week on planning.  But at least have some meetings, do some flowcharting, and if you're into Six Sigma, fine;  It all depends on the culture and business.  But in any business, size, type, whatever,  don't sit there and say you have a full SDLC process for your IT department programmers when you constantly hound them about getting it done in 2 days turnaround for projects that require a week or more!  Obviously you are full of BS, in that you support SDLC because if your expectations of your programmers are that ridiculous and you don't understand the complexity of programming what you think may be "extremely simple" then maybe you should think about another profession.

 

Getting stuff done in 2 days should not be the goal.  If it is, then you have to wonder how they became an IT, Marketing, or other type of manager...did they get promoted in a past job because someone left, not because they were highly intelligent or smart?  That's probably more likely the case in this situation.

 

7) If you treat us programmers like this, while we are truly following outlined business requirements that we have collected, then expect a crappy application in return.  No compromise by both sides means chaos in the end.

 

8) Why do I speak so bluntly and swear with a lot of anger inside?  Because I spend several years dealing with some really bad cultures in which I had to fight stupid managers about simple things as using drop down menus.  This has made my career very frustrating…due to the lack fo working for and with good managers.  Now I’m back to a good organization and to hear someone say that we have to compromise quality is a line of bs.  You may not like me for my words today, but they are true at heart.

 

--- OK, I am no longer numbering, it's just random thoughts at this point ----

 

Another thing, does this mean I have never compromised on design?  Absolutely not, of course I have...as long as it's still a good way to do it technically. 

 

Here's another stupid response from managers who don't know sh$$.  They have said a couple of times, why not provide a work around, not just saying NO.  Well, dumbass, I have, you just don't care to listen...listening skills are key to being a  manager.  Hmm, I just gave an example, what the hell were you doing, thinking about the hot secretary in the front?  I hate managers who sit there with these one liners to use programmers when we have done exactly what they have stated, but they don't know any better but to just say this because they don't want to deal with the whole thing.

 

Why did you hire us, to code crap applications?  Well, it may be swell for you but not for the person being slave driven into it who also wants to have a life.

 

You say I have a bad attitude?  No, I'm just tired of spending many years fighting doing things right the first time.  We should not have to fight for support on this, however more often or not, especially in smaller companies, that is the case.  Stay away from IT departments like this period if you have to fight just to use a drop down menu in a Web UI !!  ;)  Get out!

 

I didn't spend 30k on a college degree just so I can work in IT and let users dictate 100% how I design my apps or database tables.  Compromise must be on both sides...so that design can be done properly also, with regards to the BUSINESS REQUIREMENTS

---

C# ASP.NET Developer

...dang! bad day in the office? - but yes, you have some good points.

---

</David Christiansen>
Glasgow, UK

Phil Factor:

Am I the only one who gets impossible deadlines, bosses who behave like extras in a Typhoo Tea commercial, and users who haven't a clue what they want but are certain that it is not what you are attempting to provide, even though it is what they asked for in the first place?

Your not the only one.  Why do you think I keep asking crazy questions about DB2 in the forums =]

I need to find a web project to work on!

---

Damon Armstrong, Technology Consultant
[Blog] [Articles]

For the first phase of any project that I'm involved in, I put on my systems analyst hat and work alongside the people (workerbees) that will be using my product.  That's one advantage of being cross-qualified to hell, I can usually pick up things quickly.  Now here's the tough part.  It's not enough to get the business process analyzed, and possibly reengineered, you have to be part-time psychologist/anthropologist/sociologist as well.  I find out what parts of the job that people like and what parts they do not.  Those parts they do not are all candidates for as much automation as I can come up with.

I've only had one project go awry and by that I mean the users hated it.  I was expecting it from the outset which is why they had to drag me kicking and protesting all the way.  It was a trouble-log, ya'll call it help desk these days but this was back during the '80's, and I knew if I implemented it, not only would it be done on the computer, management would insist on keeping the dead-tree copies as well.  And that is precisely what happened, so you ended up filling out the paper copy and the on-screen copy just so management could get a pretty summary.  Stupid!

In any case, after the analysis phase, then and only then would I come up with the architecture and start coding the solution.  Actually by the time the testing phase came around, and I mean hands-on by the real user testing, there were at best slight modifications to the UI and that's dead easy if you've structured your application layers correctly.  Aside from that one help-desk app, all other apps I've created over the last twenty plus years are still in use even under modern (NT) OS'es.

There's an interesting reason for that.  I made the whole design, database to UI extensible and commented to a fare-the-well.  Heck the comments make up the documentation and every little item, especially work-arounds for compiler glitches, etc., was heavily documented.  When I left one job, they were adding a form print feature that no one thought to ask for as I walked out the door for the last time.

So my basic philosophy is "know thy users and their true desires"; "provision for the future"; and "document, document, document".

Just my $0.02.

---

~JoSh

Why do you think I started turning gray at 23?

---

~JoSh

Sometimes people tend to take themselves too serious. Chill a bit! Why is there always animosity between DBA's, Developers etc. I am a developer myself and I have great respect for the work DBA's do. They get a little overbearing sometimes but hey! they are just trying to protect their databases.

---

Manie Verster
Developer/DBA
Johannesburg
South Africa