THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is an author and engineer who enjoys building and automating data integration solutions. Andy is co-host of the Data Driven podcast. Andy is no longer updating this blog. His current blog is AndyLeonard.blog.

I Don't Work On My Car

This blog has moved! You can find this content at the following new location:

http://andyleonard.blog/2010/02/26/i-dont-work-on-my-car/

Published Friday, February 26, 2010 8:00 AM by andyleonard

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

David L. Penton said:

You realize the Odyssey just has more plastic on it? It probably has some simplified electronics on it too. Perhaps a few other abstractions, but it is for all practical purposes  just an internal combustion engine.

Software development isn't much different in that respect either. There are simplifications, other abstractions, but at its core the similarities to C or other languages is still there.

February 26, 2010 9:39 AM
 

Daniel Cawlfield said:

Far too many who practice the art of data modelling, don't know a bit from a byte and do not understand that designing for efficient storage is tightly coupled to designing for performance.  These people use nvarchar  for all string/character data, and bigint for all integers, because they don't want to ask questions about the business need, and don't know how to profile existing data.  When I explain to a data modeller that a smallint or tinyit was a better choice than the bigint they installed, the comeback is "it doesn't really make much difference, and besides, storage is cheap".  And my unspoken response is: Go back to school.  You just don't get it.  I guess my point is, both education and depth of experience are valuable and relevant across the broad area of IT practice.  Too often managers hire the person right out of tech school, or fresh off the boat, because he/she comes with fresh experience in exactly the right xyz technology, and a low end price tag.  And then the entire user-community suffers with a sluggish database.  Add up the cost in manhours of the whole team waiting on the database.  Did you really save money with that hiring decision?

February 28, 2010 2:33 PM
 

Jorge Gomes said:

Os carros novos realmente têm uma sofistificação aparente fantástica! Coisa que os velhinhos carros não apresentam. A tecnologia cresce e permite disfarçar alguns pormenores que aos olhos de outros parecem milagres! Mas nem tudo é o que aparenta e a velha tecnologia, o velho saber está lá.

Isto é válido também para a informática. Vejo tantos "técnicos" a consertarem computadores..."hum, o windows não arranca? Ok, vamos formatar!"...chamam a isto técnico?

A nossa experiência, o nosso saber fazer está acima de tudo. Quando trabalhamos há anos numa arte não temos medo de tocar em qualquer coisa moderna, temos a experiência e o bom senso para conhecer falsos conhecimentos e falsos técnicos.

A questão dos dados da DB, por ex., é típica. Tenho colaboradores que colocam qualquer número como sendo real ou int. Mesmo sabendo que o nº em questão não passará dos 5000!!! "É tudo o mesmo, que interessa isso? Quero é programar" - dizem eles.

A performance não é preocupação...

...para resolver esses problemas temos cá os velhinhos que conduzem o velho Jeep. Esses asseguram sempre a estabilidade e calma necessárias ao bom funcionamento de todo o circuito.

Cumprimentos,

JG

March 1, 2010 7:36 AM
 

jay said:

The problem is, automobiles are falling into the software trap. More and more control is taken from visible mechanical systems and handed over to inscrutable algorithms (including the infamous throttle controls). I find this dependency and needless complexity very troubling. We are seeing more and more cases where failures of computers, algorithms or sensors have serious (occasionaly dangerous) effects on the car. What happens as these complex systems get older?

Think about it: your Jeep is 20 years old and still viable. How viable is a 20 year old computer?

[I have an 89 Jeep, my wife an 87 MB; blessedly computer free]

March 1, 2010 10:04 AM
 

sb said:

I disagree. Technologies change, but someone equipped with solid programming concepts can quickly digest new technologies, even if it's been 18 months or more.  When I look at hiring someone, I look at the foundation more than the specific technologies used.  Education and experience mean a lot.

March 2, 2010 7:34 AM
 

Tim said:

I disagree with Daniel above (to a degree). Build the program first, then optimize. While yes, I also cringe at nvarchar(4000) everywhere, however bigint -- ya know, 64 bit OS's and databases -- assuming that the os and database developers didn't totally screw their apps by not leveraging the hardware correctly, use that 64 bit bus.

That's not to say use it everytime. But use it if there is doubt. No need to ask billy businessman how long that field needs to be -- he won't know anyway.

July 8, 2010 1:17 AM
 

Caleb said:

Tim, this series is addressed at helping people like YOU!

July 9, 2010 6:42 PM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

News

My Latest Book:

Community Awards



Friend of Red Gate

Contact Me

Archives

Privacy Statement