July 23, 2014 at 1:07 pm
This is a great topic and one that resonates with some of the challenges that I have daily with my colleagues. One of my original mentors gave me the sage advice that in order to really thrive in IT, a person must understand three things. Programming. Networking. Hardware (specifically servers and storage).
A person does not need to necessarily master all three of those areas, but they must develop at least passing familiarity that allows them to be conversant in the general principles.
All too often, especially in the larger enterprise environments, I see what I am calling the "special flower" IT resources. Some examples of these special flowers are SQL DBAs who refuse to troubleshoot Windows problems, even when those problems are tangentially related to SQL Server. For example, when the win32 perfmon counters for SQL server are not properly initialized / need to be reset. Or another favorite of mine, the developers who exclaim "My code runs fine in dev. You just need to throw more hardware at in in prod if it is running too slowly." Like the idea of load testing their code or considering how much memory it uses is not their problem.
Being a special flower is not a badge of honor. It is not cool for a person to be a specialist with a myopic view of their thin slice of the environment. Those people are liabilities. People who cannot see how their piece interacts with the larger environment, and who are quick to fall back on common refrain of, "Well the (database, network, server, storage) is 'fine', therefore it is someone else's problem.", are burdens to their team.
What teams need, and whether you want to call it DevOps or whatever the buzzword of the year is, is people who can provide suggestions and help everyone overcome challenges. You want the server guys who know enough about programming to guide the developer towards finding a memory leak. You want a database administrator who knows enough about storage to understand that the latency on his log files could be due to improperly provisioned storage pools on the SAN. You want a SAN administrator who can look into the storage pools and then tell the network guy that the pools are actually fine, and that the issue is a saturated network port.
Since the original subject is DevOps and developers, you need developers who are responsible for their code. That means they have to test it. That means they have to understand what it takes to move it from dev, to QA, to UAT to prod. I am all for making them do it themselves. That way they have an appreciation for how long it takes the server guys to get it done.
(Warning, rant ahead) "Oh, the dev does not have time because they are so busy with other things? Like the rest of the team isn't? Oh please Mr. Dev, let me drop everything else I am doing so that you can push your changes into QA. Go push your own changes, lazy bum.... Cannot figure out how to clone and provision a VM and the associated storage? Boo hoo hoo for you. You poor, special, co-dependent flower."
July 23, 2014 at 1:37 pm
Gary Varga (7/23/2014)
TomThomson (7/23/2014)
I rather agree with Patrick's comment above - but I read the rubbish and got steadily more appalled as I went through it. A (Python) Programmer is apparently the highest form of life and people who do testing, quality assurance, deployment, or operations and of course DBA's too are all "lower" beings, clearly below him in the natural hierarchy - I just can't stomach that inflated view of a developer's place in the scheme of things. If I had ever had a developer like that working for me I would have fired him if I couldn't persuade him to change his attitude.Oddly enough, I have lots of four letter words for developers who want to do no testing, or do no customer support, or do no deployment.
I'm happy with the idea that a developer does plenty of unit testing of his stuff, that the developers work together to do system testing, and that they don't take responsibility for quality assurance (although the QA team may ask them to develop some tests for them). I'm happy with the idea that software that is very difficult to deploy is pretty useless software, and that developers have to understand that and will have to assist in deployment if they haven't managed to produce software that is easy enough for the deployment and operations teams to deploy. I'm happy with the idea that when, despite all the unit testing and the QA the sofware still has faults and the customer support team can't provide an acceptable workaround for the customer a developer may have to understand the problem (which is likely to involve talking to the customer, maybe even visiting the customer) and finding either a quick fix or an acceptable workaround. I'm very unhappy with the idea that those things are no part of a developers job.
I think I expect developers to be a more concerned with testing, QA, deployment, and customer support than Steve appears to think is right, and Steve in turn thinks developers should be more involved with such things than that Python Programmer with the inflated ego appears to believe is proper.
As a developer, I can honestly say that this "leave me to code" attitude stinks. It is all about the overall result which we all get judged on. And so we should.
[Paraphrasing Mr Python Developer] "Leave me alone. I am superior to you. I am more worthy."
Really? I agree with Tom. Get a grip and join the team.
Was the "leave me to code" attitude the difference between developers and programmers? Many can code, a lot less can develop SW.
July 24, 2014 at 6:34 am
I find testing code, which I have not written, incredibly frustrating and fruitless. I'm sure I could learn better unit-testing skills, and ways of writing better test scenarios, but if I cannot actually see what the code is doing, I just feel blind.
Take a recent, real example: some ABAP code was written for importing a CSV file into SAP. We ran multiple import tests with multiple files, and mostly these worked fine. But occasionally the new or updated data in SAP was unexpected. There were so many potential scenarios (you only need a small CSV file with a few inter-dependent columns, plus different rules for inserts & updates, to end with a huge number of possible changes).
The ABAP code was written by an external consultancy. When we eventually found someone (i.e. a precious developer) with access to the ABAP code, and stepped through the code as it was processing the file, it was immediately understood what was happening. [If interested, the ABAP code wasn't correctly clearing the interim load table between each row]. Hours of "blind testing" or minutes of working alongside a developer...
July 24, 2014 at 6:40 am
Andy sql (7/24/2014)
I find testing code, which I have not written, incredibly frustrating and fruitless. I'm sure I could learn better unit-testing skills, and ways of writing better test scenarios, but if I cannot actually see what the code is doing, I just feel blind.Take a recent, real example: some ABAP code was written for importing a CSV file into SAP. We ran multiple import tests with multiple files, and mostly these worked fine. But occasionally the new or updated data in SAP was unexpected. There were so many potential scenarios (you only need a small CSV file with a few inter-dependent columns, plus different rules for inserts & updates, to end with a huge number of possible changes).
The ABAP code was written by an external consultancy. When we eventually found someone (i.e. a precious developer) with access to the ABAP code, and stepped through the code as it was processing the file, it was immediately understood what was happening. [If interested, the ABAP code wasn't correctly clearing the interim load table between each row]. Hours of "blind testing" or minutes of working alongside a developer...
The black box testing you were initially doing is applicable to acceptance testing. The white box testing you ended up doing is appropriate to unit testing and diagnosing issues. Neither type of testing is appropriate for the other task.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 25, 2014 at 1:43 am
The idea behind this article, and the external link, was many developers don't want to be part of the testing cycle. They just want the results of the tests. And unfortunately that is the way testing usually happens.
I appreciate the explanation of black box & white box though; I've never heard of this in reference to testing.
August 21, 2014 at 3:00 am
I read this article and rememebered reading this from Brent Ozar[/url] a few weeks back. Primarily I would describe myself as a Prod DBA/with-a-bit-of consulantancy-on-the-side but I like to think I can turn my had to other roles (last year I was a SQL Dev for a client) and now, reading Brent's article I appear, for my present client, to be a DevOps. Have to say it doesn't bother me all that much as long as I am learning and the work I do is interesting.
qh
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply