January 19, 2010 at 9:50 am
That the proposed solution meets the requirements of the client/user is simply a given (assuming of course they don't violate the laws of physics or of the state).
I think goodness is defined in terms of craftsmanship: reliability, performance, maintainability.
January 19, 2010 at 12:58 pm
The reality is there is never enough time, however the bigger reality is there will never be a time where you get to come back and fix it later and these bandaid solutions will sit in place for years.
January 19, 2010 at 3:17 pm
This reminds me of a programmer I knew who could not finish a project because it was never good enough. She was a perfectionist and found flaws that no one else saw.
Perfection can never be reached.
January 19, 2010 at 8:49 pm
roger.plowman (1/19/2010)
GOC-481399 (1/19/2010)
Be good to see an alternative article on how to maintain your standards when thrown into a (purely hypothetical of course) BI/Reporting team where:- Nothing is documented and the bulk of the TSQL is totally uncommented
- DDL is done on the fly, on the production dbs, from the SSMS gui instead of with scripts via dev>test>prod
- Management's default setting is "I just want something quick and dirty. Don't spend too much time on it."
- Backups are sporadic at best
- The lead "DBA's" qualifications consist of being is best mates with the boss.
- The lead DBA's idea of getting around security headaches is "That's OK, I'll just give them admin rights."
- Radical constructs such as primary and foreign keys are generally an unnecessary luxury
- Reporting must never include any audit trail describing how the final numbers were arrived at.
- Nobody knows what anybody else is working on, and more to the point management actively discourages it because "We're too busy."
- Management thinks Boyce-Codd is a type of fish
Obviously such a team could never exist in reality, or could it? If you've worked in an environment like this how did you survive?
Find a new job. QUICKLY. 🙂
Heh... sounds like a lot of the places I've had to work. Notice the word "had". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2010 at 9:32 pm
I agree that "perfect" is sometimes the enemy of the "good"...
...but that's usually just some garbage excuse by people who don't really care to begin with. Think about it... the leading factor towards such excuses is poorly planned schedules that are agreed upon by moroffs in the elevator or boardroom that simply don't have a clue as to what their promises actually contain because they're not willing to spend the time to actually find out. Now, compound a poorly constructed schedule with other folks who rightly fear for their job because they don't actually know what "good" is (never mind "perfect") and what you end up with is a pot wad of crappy code that WILL break (never mind be performant or scalable), WILL give the company a black eye in front of the customer, and WILL cost the company somewhere between 1 and 20 times more in rework. And make no doubt about it... most rework is NOT paid for by the customer unless they're totally stupid and didn't build accuracy and performance SLA's into their contracts with you. "Agile" programming should never be used as a synonym for "stupid" programming... that's NOT in the manifesto but it seems a lot of people think so. 😉
It doesn't take THAT much time to do things "better than good" even in the face of a ridiculous schedule especially if you know what you're doing. Yes, yes... there are tradeoffs that you CAN make but there are many more that you cannot or they will come back to haunt you when you really want that vacation or day off for your kid's first birthday. You want time off when you need it? Stop making excuses and do the best job possible to begin with. It's just not that hard.
What I've found in most companies is that "perfect" is NOT the enemy of "good" because "perfect" is never even considered. Idiotically conceived schedules, lackadaisical attitudes towards one's job (from Developer to CEO), a lack of knowledge because few actually practice their trades just for the sake of practice, and the ease of using excuses to justify a bad job are the norm rather than the exception and are the true enemy of the "good".
All you Developers and DBA's out there... remember that "good enough" usually isn't and it's YOU that will pay for it if it isn't. All you managers and "C-Level" managers out there... remember... if you want it real bad, that's the way you'll get it and it's you who WILL answer to the board and your customers. Poor planning on your part DOES constitute an emergency on my part... SO PLAN BETTER!
Stop making and justifying excuses... whether you're "just" a Developer or you're the CEO, you're in business. Act like it!
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2010 at 9:47 pm
p.s. Andy, that's not directed at you or anyone in particular. You just happened to hit a "sweet" spot (or is that "sweat" spot :-P) with me. It all boils down to P7 and it seems that everyone uses the excuse of not having the time...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2010 at 7:47 am
See signature... 🙂
Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
January 20, 2010 at 7:21 pm
GabyYYZ (1/20/2010)
See signature... 🙂
Heh... see previous post. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2010 at 9:01 am
roger.plowman (1/19/2010)
GOC-481399 (1/19/2010)
Be good to see an alternative article on how to maintain your standards when thrown into a (purely hypothetical of course) BI/Reporting team where:- Nothing is documented and the bulk of the TSQL is totally uncommented
- DDL is done on the fly, on the production dbs, from the SSMS gui instead of with scripts via dev>test>prod
- Management's default setting is "I just want something quick and dirty. Don't spend too much time on it."
- Backups are sporadic at best
- The lead "DBA's" qualifications consist of being is best mates with the boss.
- The lead DBA's idea of getting around security headaches is "That's OK, I'll just give them admin rights."
- Radical constructs such as primary and foreign keys are generally an unnecessary luxury
- Reporting must never include any audit trail describing how the final numbers were arrived at.
- Nobody knows what anybody else is working on, and more to the point management actively discourages it because "We're too busy."
- Management thinks Boyce-Codd is a type of fish
Obviously such a team could never exist in reality, or could it? If you've worked in an environment like this how did you survive?
Find a new job. QUICKLY. 🙂
This is pretty much every job I have had. Sometimes I did not have the option to leave, and I am pig-headed enough to believe I can change the world. Here is my strategy:
Find partners. If you are lucky, the company has at least figured out that they need technical people helping sales and business translate what the geeks are saying. These might be called team leaders or business analysts. Find one that you can work with. If they don't have that, go to the end-user, the ones who know the business because they are doing it every day. If you remember Radar O'Reilly from the MASH TV show, find someone like him. If you can't find either of these, then the business won't last long anyway.
Create value for these partners. Be friendly with them so they understand that you asking them annoying detailed questions about what they do will result in a system that saves them time and increases revenue. They then become your advocates.
The next level would be to develop partnerships with people who really have the power to make changes, but I have never made it that far, at least not successfully enough to want to stay with the firm. This strategy has helped me survive in places like this for about 2 years. I spend another year or so trying to explain why "better" is better than "good" while I am polishing my resume and sneaking out for interviews. Perhaps my impatience has something to do with it.
Instead of listening to my ideas I usually just get rewarded with more work, more difficult clients, etc. I recently learned the term "technical debt" so maybe next time I will be better able to explain to the higher ups that I can no longer do "perfect", because I spent too much time doing "good" and now only have time to fix all the little problems that creates.
To the topic itself, I have only heard it phrased like that twice. Both times it was by people who were nowhere near a discussion of creating a perfect system. They were using it to suppress the slightest suggestion of doing any documenting or error reporting or using the simplest waterfall type project management. Basically I agree, as long as everyone has some concept of what "good" is and the ability to have a civil discussion about when you are slipping into trying to be "perfect".
January 26, 2010 at 4:05 pm
WolforthJ (1/26/2010)
The next level would be to develop partnerships with people who really have the power to make changes, but I have never made it that far, at least not successfully enough to want to stay with the firm.
I've found that most SQL Developers and DBAs don't play that card early enough. Developers should develop such a relationship with the DBA as soon as they can provided that it's not the DBA who is the problem.
DBAs should always be in touch with folks who can make the decision to order changes with justification, of course.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2010 at 1:34 pm
GOC-481399 (1/19/2010)
Be good to see an alternative article on how to maintain your standards when thrown into a (purely hypothetical of course) BI/Reporting team where:
It can be much worse than what you descriobe, see below
- Nothing is documented and the bulk of the TSQL is totally uncommented
Or there's a lot of documentation but it's documentation of a version that was thrown away three years ago because it could never have been made to work, and the only thing it had in common with the current system is that it too can probably never be made to work.
- DDL is done on the fly, on the production dbs, from the SSMS gui instead of with scripts via dev>test>prod
- Management's default setting is "I just want something quick and dirty. Don't spend too much time on it."
- Backups are sporadic at best
there are no backups at all, none of the DBs has ever been backed up.
- The lead "DBA's" qualifications consist of being is best mates with the boss.
The "lead DBA's" qualifications consisted of having been the one who was stuck with the DBA job which nobody wanted because they knew it wasn't what real engineers do, but he left a few months ago and hasn't been replaced.
- The lead DBA's idea of getting around security headaches is "That's OK, I'll just give them admin rights."
The only logins in the system are those that ship with SqlsServer; the only one used by developers is SA, which is also the one used by all apps; the SA password is blank, and the PTB don't want it changed in case this breaks the apps or incoveniences the developers.
- Radical constructs such as primary and foreign keys are generally an unnecessary luxury
As are indexes, regular database consistency checks, examination of error logs, and checks on db sizes and growth rates.
- Reporting must never include any audit trail describing how the final numbers were arrived at.
Reporting???? What Reporting????
- Nobody knows what anybody else is working on, and more to the point management actively discourages it because "We're too busy."
- Management thinks Boyce-Codd is a type of fish
Management have heard of Boyce-Codd? Surely not!
Obviously such a team could never exist in reality, or could it? If you've worked in an environment like this how did you survive?
I've survived by changing the environment - generally I've been able to do that because that has been my job. Sometimes it is hard work and it takes time because of people's entrenched attitudes, sometime when you explain the problem to top management (you have to go to top management or nothing will happen) it is immediately clear to them and the culture changes very rapidly indeed.
The outfit I joined in 2002 was just like that (if anything, it was worse: all the comments I added to your description fit it perfectly - that's where those comments came from - and all the same ideas applied to the handling of the customers' databases on the servers that the company installed on customer sites as applied to the databases back at the ranch). In addition, much of the app code written in C++ was nearly as flakey as the database side, and all the T-SQL for property management, activity logging, everything except the GUI was embedded in it (a lot of it generated on the fly by really awful C++ routines). And worst of all, the development team thought that nothing was wrong. The Creative Director wouldn't let the development team anywhere near his media description databases and the Ops Director too knew it was all wrong (that's why he'd invited me to come in and sort it), but they couldn't persuade the development team that there was any need to learn anything about databases or about security and the CEO (an accountant) tended, since he saw it as a development issue, to support the head of development about this (including the idea that a professional DBA was an unwanted overhead - I went in as a system architect not as a DBA because even the CEO knew that a company whose product was largely based on IT needed a system architect, not as a DBA and not in development). That was one of the slow and difficult ones.
Back in 1999 I joined a little startup who were planning a big development. The CEO had done a quick sizing of the database side and concluded the DB could be handled by a single desktop machine using its internal discs. I looked at the sizing, did a little simulation, and suggested it actually needed a server farm with 42 big servers (168 CPUs, 168GB of RAM) and something over 40Tbytes of data spread over 84 RAID controllers (with a further 42 RAID controllers to handle the servers' internal discs). The CEO checked my calculations, got the lead developer also to check them, and since they both decided that my rough sizing was roughly right - and that a database server farm of that size would need a very different approach to administration than a little desktop machine would - the company's view of database administration changed overnight. That was one of the easy ones.
Tom
February 13, 2010 at 1:43 pm
I don't like the cliche. Best practise is to consider the tradeoffs and choose the course of action that will deliver the most favorable outcome. That is no enemy of the good - it is the good's best friend. Following the book without care or thought for consequences is of course an enemy of the good, but it is not best practise. I am appalled when some book or blog or technical article tells me that some particular thing (like always using join hints in every inner join, or never using join hints in any inner join, or always considering using join hints no matter how sure you are the optimiser will get it right) is best practise, rather than making a reasonable decision whether to do that thing or not, because it's turning engineers into trained monkeys.
Tom
February 13, 2010 at 6:01 pm
A best practice does not mean that's what you always do. But in the absence of a reason to do something differently, you follow the best practice. That only makes you a trained monkey if you don't learn why the best practice exists and understand when you should change it.
February 13, 2010 at 8:36 pm
"Best Practices"... heh... all I'm going to say about that subject is "It Depends". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2010 at 7:48 am
Tom.Thom said: sometime when you explain the problem to top management (you have to go to top management or nothing will happen)
This is kind of a depressing statement. It leaves you with no choice but to join a company with top management that thinks like you. Until you are interviewing for a job that includes talking to top management, that can be difficult to determine. I once almost had the ear of Bill McGuire, former CEO of United Healthcare, but all he did was talk to the people directing my division and ask why I was bothering him. I was bothering him because those were the people causing the problems.
I look for management that is willing to change and listens to everyone below them. A couple simple questions about project management during an interview usually reveal that. If there are two interviewers in the room, the sideways glances will tell you a lot. I had one interviewer who I could tell was pretty stressed from the chaotic environment, I asked about project management and she said, "oh, you want the perfect job." No, but I didn't want that job.
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply