August 19, 2014 at 8:04 am
astone-1154729 (8/19/2014)
It's not the artistic nature of people that leads to poor application development. It's just simple ignorance or lack of experience, maybe indifference.
For most forms of art, even a (trained) spectator can see the difference between a craftsman and a dabbler. The same is true about the 'art' of programming when you look at the source code. However, unskilled programmers are so much cheaper and easier to find (not unlike unskilled painters). True quality is hardly ever noticed in an application; did you ever notice the absence of the usual irregularities and annoying inconsistencies yourself, or the failure to fail when a user is either ignorant or impatient? How much are you willing to pay for these properties in an application that might be replaced in two, maybe three years?
It is not the lack of skills, or indifference, but the lack of money that drives program quality to the current all time lows. Doesn't every car looks bright and shiny when you buy it? Don't you pay a lot for what is under the hood without knowing exactly how it works? The COBOL application on the mainframe of your bank may have some flaws too, but it was build to last and so it does even up until today. But of course with quite a different price tag then the line-of-business software made today ...
August 19, 2014 at 8:12 am
hakim.ali (8/19/2014)
Thanks for the thought-provoking article Steve.
cheers
August 19, 2014 at 8:16 am
vliet (8/19/2014)
...It is not the lack of skills, or indifference, but the lack of money that drives program quality to the current all time lows...
I agree that is half of the story but I do think that some people go from place to place, project to project, delivering sub-standard work that doesn't last BECAUSE of the level of quality.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 19, 2014 at 8:57 am
The word "skill" is apt because it is developed over time (years). Experience certainly costs.
August 19, 2014 at 9:07 am
Hmm, I always say Technology runs in stages of evolution. The pioneers are the Computer Scientists. They understand deeply, without convention or standards yet developed. Everything is experimental. Then comes the Engineers. They apply the standard conventions. Then comes the Administrators. They develop much less, put they can put systems together and maintain them. The Administrator role only comes when better GUI's or engineered scripts and standards are developed. Finally, the technology becomes so ubiquitous that the Technician can handle the primary functions.
This evolution has always occured from the Scientist, Engineer, Administrator and Technician for all technologies, whether it was Mainframe servers, PC's, Networks, Databases, or Web Design. Unfortunately, while it sounds nice to call yourself a Scientist with your rigid structure, documentation, standards, you are at BEST a Database Engineer and most likely a Database Administrator, possibly even a Database Technician as the GUI gets more simplified. The Database Scientists who are pushing the boundaries are actually the "Artists".
August 19, 2014 at 9:59 am
jeast 83268 (8/19/2014)
Hmm, I always say Technology runs in stages of evolution. The pioneers are the Computer Scientists. They understand deeply, without convention or standards yet developed. Everything is experimental. Then comes the Engineers. They apply the standard conventions. Then comes the Administrators. They develop much less, put they can put systems together and maintain them. The Administrator role only comes when better GUI's or engineered scripts and standards are developed. Finally, the technology becomes so ubiquitous that the Technician can handle the primary functions.This evolution has always occured from the Scientist, Engineer, Administrator and Technician for all technologies, whether it was Mainframe servers, PC's, Networks, Databases, or Web Design. Unfortunately, while it sounds nice to call yourself a Scientist with your rigid structure, documentation, standards, you are at BEST a Database Engineer and most likely a Database Administrator, possibly even a Database Technician as the GUI gets more simplified. The Database Scientists who are pushing the boundaries are actually the "Artists".
Not being a DBA, I am a Database Jester at best 😉
With regards to development I have done the following (amongst many others):
etc.
I have a cupboard full of development hats.
You will find many with long careers here that have required them to be scientists. Most developers that started developing this millennium appear that they will not get the opportunity at work to do half the fascinating tasks that I have had the opportunity to do. So yes, that majority will not be scientists but should be engineers.
I possibly also have oversized shoes and an undersized car but that's a different story :crazy:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 19, 2014 at 10:22 am
What you've described is not a scientist, but an engineer. Not that there's anything wrong with that....
August 19, 2014 at 10:45 am
Most of it was engineering, I grant you, but some was computer science due to the time frame i.e. it was pushing boundaries where there was no accepted applicable theories a.k.a. advancing knowledge (mainly in the area of modeling and tooling). That is scientific exploration by most definitions.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 19, 2014 at 11:27 am
Steve, great thoughts, and insight on the different approaches. And when hiring staff, it is good to know they type of individual you are seeking. Still, I'd just like to suggest a minor adjustment in the terms used. IMHO, your description of scientist better fits with an engineer. Scientists are more like the artists in your description. Scientists push out in new areas, where there is not a known solution. After discovery, engineers come in and perfect, and productionize a solution.
The more you are prepared, the less you need it.
August 19, 2014 at 12:34 pm
Gary Varga (8/19/2014)
paul.knibbs (8/19/2014)
I probably count as both, too, but the distinction with me is that I'll take the "artist" approach for something that I know will only happen a few times--the extra effort of writing the automation doesn't make sense for something that isn't often going to be automated, IMHO!Makes total sense.
Experience can indicate when a "one off" will likely become a BAU (Business As Usual) process. We can all make the wrong call and it will happen at times. There must be a recognition, if only internally, that if we cater for BAU that remains a "one off" then we may have wasted effort and if the "one off" becomes BAU then we risk the outcome of technical debt.
As with most things, it depends.
Make the call. Deal with the consequences. Move on.
While I agree with what you are saying, I think Steve intended to convey the idea that you should still follow best practices. For example, all of my maintenance jobs email me status updates. Sometimes someone sets up a new SQL database without telling me. That means maintenance plans aren't configured, backups aren't being done. While it may not seem important to the person setting it up, as it is a small system, the guideline in our company is to go through me so they can be. It might seem that it doesn't need automation, but it clearly does.
I think this is a poor example to use, and I sincerely doubt Paul or Gary are referring to anything like this, but I couldn't think of something better.
Dave
August 19, 2014 at 12:36 pm
Gary Varga (8/19/2014)
vliet (8/19/2014)
...It is not the lack of skills, or indifference, but the lack of money that drives program quality to the current all time lows...I agree that is half of the story but I do think that some people go from place to place, project to project, delivering sub-standard work that doesn't last BECAUSE of the level of quality.
I think it's money, for sure, but it's also skill. Far, far too many people building software today haven't built skills, and many don't continue to build them.
August 19, 2014 at 12:41 pm
Scientist v engineer. I could see why some people prefer the latter, but that's a little pedantic. Plus it didn't flow off the tongue as well.
I think I got the point across that it's about inconsistency v consistency. It's about spur of the moment v tried, true, practiced, proven techniques.
The labels are less important.
August 19, 2014 at 3:22 pm
There's some distinction to be made between methodology as in how things get done and what you are trying to get done. As well as distinguising the difference between a proof of concept piece of development vs something that's going to be deployed in a production setting.
They require different skills and mentalities, some people are good at one and bad at the other. It's only bad when someone is bad at one and doesn't ask for or accept help with the other.
Being able to come up with a way to solve a problem is only part of the project if the deployment is sloppy and inversely being unable to come up with an original solution because there is no standard or accepted way to do what you need is just as bad.
August 19, 2014 at 4:42 pm
crussell-931424 (8/19/2014)
What drives me crazy are the programmers that always seem to want to make the code better, improve it, optimize it, when it is running just fine now. I say leave well enough alone. There is plenty of other work to do. If it isn't broke, don't fix it, because when they do fix it they invariably break something. There is usually some obscure logic, written poorly perhaps, that they miss and don't put into their re-written version.
Heh... "When it is running just fine now". A lot of people aren't actually qualified to decide what "isn't broke, don't fix it". Most of my professional career has been fixing things for people that made such a statement. 😉
What's really bad about the "running just fine now" statement is that when it does become a performance problem, it usually gives the company that wrote it one hell of a black eye because it always becomes a problem when people most need it not to be. Such problems spread like wild-fire in this industry and you can lose a lot of current and future customers over things that could have been prevented.
Hat's off to the "crazy" programmers that "always seem to want to make the code better, improve it, optimize it". They save a ton of rework and deadas panics.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 19, 2014 at 4:46 pm
vliet (8/19/2014)
For most forms of art, even a (trained) spectator can see the difference between a craftsman and a dabbler.
That's the comparison that I would have made instead of "artist and scientist". A craftsman doesn't have to science anything out. (S)he already knows what works and just does it right the first time.
Heh... me? I guess I'm an "alchemist". A lot of my time is spent turning piles of manure into gold. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply