January 13, 2015 at 10:20 am
A real true developer, as opposed to a coder, will be humbled and mortified to have bugs found by others. You should know your code and be creative enough to anticipate what can happen in all cases. One of the biggest failures in coding is to fail to anticipate and handle errors without crashing things. If there's a problem, it's YOUR problem.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 13, 2015 at 10:21 am
Todd Townley (1/13/2015)
There does seem to be a disturbing trend, however. The editorial alluded to it, and I've seen it in the software company where I work - that developers these days seems to concentrate on pushing the code out, but maintain little responsibility for making sure that the code is right (other than within it's immediate realm) within the context of the application. And when it's not right, well, it's up to Q.A. to catch it, or Support to triage it, or some other team to fix the data errors caused by the problem.
Trend? I've seen this my whole 25 year career in IT.
January 13, 2015 at 10:22 am
aaron mertes (1/13/2015)
Steve,I have been creating unit tests for database code for many years now, using DBFit and some early techniques gleaned from the folks at SQLity. Having developed using TDD and without, I can say without a doubt using TDD will make your code better now and easier to maintain later.
Aaron Mertes
Love to see a writeup on some examples you use. If you're interested, let me know. It's good to get actual requirements and their tests published for people to learn from.
January 13, 2015 at 10:40 am
skeleton567 (1/13/2015)
A real true developer, as opposed to a coder, will be humbled and mortified to have bugs found by others. You should know your code and be creative enough to anticipate what can happen in all cases. One of the biggest failures in coding is to fail to anticipate and handle errors without crashing things. If there's a problem, it's YOUR problem.
Amen to that!
January 13, 2015 at 10:41 am
I've always advised the best way to avoid bugs or get them fixed is to force those who develop products, IT or other, to use their own products, with only the same resources as the end user. Things may change is a big hurry. Interesting that developers will be the first to jump all over software vendors for their bugs and demand new fixes RIGHT NOW.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 13, 2015 at 10:43 am
Steve Jones - SSC Editor (1/13/2015)
Todd Townley (1/13/2015)
There does seem to be a disturbing trend, however. The editorial alluded to it, and I've seen it in the software company where I work - that developers these days seems to concentrate on pushing the code out, but maintain little responsibility for making sure that the code is right (other than within it's immediate realm) within the context of the application. And when it's not right, well, it's up to Q.A. to catch it, or Support to triage it, or some other team to fix the data errors caused by the problem.Trend? I've seen this my whole 25 year career in IT.
I've been in IT 37 years, most of it in software design and development - and I'm surprised neither of you are asking WHY 'developers seem to concentrate on pushing out code'. No developer worth some salt will produce code without regard for its quality, unless pressured by unreasonable deadlines and/or impossible scope creep and/or the lack of decent functional/design specifications.
Steve, you've fallen into finger-pointing mode again, and as usual, your finger's pointed at developers. I'm disappointed, but not surprised.
January 13, 2015 at 10:59 am
GoofyGuy (1/13/2015)
Steve Jones - SSC Editor (1/13/2015)
Todd Townley (1/13/2015)
There does seem to be a disturbing trend, however. The editorial alluded to it, and I've seen it in the software company where I work - that developers these days seems to concentrate on pushing the code out, but maintain little responsibility for making sure that the code is right (other than within it's immediate realm) within the context of the application. And when it's not right, well, it's up to Q.A. to catch it, or Support to triage it, or some other team to fix the data errors caused by the problem.Trend? I've seen this my whole 25 year career in IT.
I've been in IT 37 years, most of it in software design and development - and I'm surprised neither of you are asking WHY 'developers seem to concentrate on pushing out code'. No developer worth some salt will produce code without regard for its quality, unless pressured by unreasonable deadlines and/or impossible scope creep and/or the lack of decent functional/design specifications.
Steve, you've fallen into finger-pointing mode again, and as usual, your finger's pointed at developers. I'm disappointed, but not surprised.
I agree. When I'm constantly told to lower my estimates because x was promised to be delivered in two days... what was that joke about pick two?
January 13, 2015 at 11:34 am
I feel very lucky. It is been a rare that I have been told get done by x date regardless of how poor it's done. Just yesterday my CFO asked when I would release the product in dev and I said when I am 100% sure it works. Which usually means it doesn't have big bugs. 🙂
January 13, 2015 at 1:15 pm
GoofyGuy (1/13/2015)
I've been in IT 37 years, most of it in software design and development - and I'm surprised neither of you are asking WHY 'developers seem to concentrate on pushing out code'. No developer worth some salt will produce code without regard for its quality, unless pressured by unreasonable deadlines and/or impossible scope creep and/or the lack of decent functional/design specifications.
Steve, you've fallen into finger-pointing mode again, and as usual, your finger's pointed at developers. I'm disappointed, but not surprised.
wha? You've added a lot of qualifications there.
"no developer with some salt" - what's what? Plenty of good developers make mistakes and shoot out code that's flawed. It happens all the time, and I've seen it from people I think are good developers.
"pressured by unreasonable deadlines, etc" - Sure, but that's a reality that you will face some deadline you don't think you can meet, or you cannot meet for various reasons. Some are valid, some not, but that doesn't mean that your reasons don't impact testing or code quality. I haven't said every developer, but I've seen regular issues crop up in software of all shapes and sizes. From good and bad developers. From everyone.
Regardless of the reasons, which may be some you've listed, code is pushed out and not tested properly.
And there are plenty of developers in the world that have jobs, get paid to write software, and knock out code without a lot of regard to quality. It's been happening since computers existed and it continues. I didn't say most developers, I didn't say you, so don't project this to mean everyone, but don't try to pretend that plenty of poor code isn't written and delivered to production environments.
January 13, 2015 at 1:34 pm
Steve Jones - SSC Editor (1/13/2015)
GoofyGuy (1/13/2015)
I've been in IT 37 years, most of it in software design and development - and I'm surprised neither of you are asking WHY 'developers seem to concentrate on pushing out code'. No developer worth some salt will produce code without regard for its quality, unless pressured by unreasonable deadlines and/or impossible scope creep and/or the lack of decent functional/design specifications.
Steve, you've fallen into finger-pointing mode again, and as usual, your finger's pointed at developers. I'm disappointed, but not surprised.
wha? You've added a lot of qualifications there.
"no developer with some salt" - what's what? Plenty of good developers make mistakes and shoot out code that's flawed. It happens all the time, and I've seen it from people I think are good developers.
"pressured by unreasonable deadlines, etc" - Sure, but that's a reality that you will face some deadline you don't think you can meet, or you cannot meet for various reasons. Some are valid, some not, but that doesn't mean that your reasons don't impact testing or code quality. I haven't said every developer, but I've seen regular issues crop up in software of all shapes and sizes. From good and bad developers. From everyone.
Regardless of the reasons, which may be some you've listed, code is pushed out and not tested properly.
And there are plenty of developers in the world that have jobs, get paid to write software, and knock out code without a lot of regard to quality. It's been happening since computers existed and it continues. I didn't say most developers, I didn't say you, so don't project this to mean everyone, but don't try to pretend that plenty of poor code isn't written and delivered to production environments.
And I'm not saying developers should be released from a responsibility to produce quality code. What I can't fathom is urging developers to assume additional responsibility for quality assurance, while acknowledging they should do so while dealing with unreasonable deadlines, shoddy or non-existent design specs, and raging scope creep.
The essential problem isn't lazy, slipshod developers (although there are some). It's lazy, slipshod management of developers.
January 13, 2015 at 2:09 pm
skeleton567 (1/13/2015)
I spent 42 years as a developer in various languages and as a DBA heavily involved in producing SQL code. Due to my own testing as I worked, I rarely had any bugs discovered by QC testing. If developers take pride in their product, they WILL get the testing done, if they have the true understanding of the language and the assignment. I also did lots of breaking down and testing pieces of code for others in order to get needed performance and reliability. Good developers will not depend on someone else finding their bugs.
I agree with you completely.
January 13, 2015 at 2:18 pm
GoofyGuy (1/13/2015)
The essential problem isn't lazy, slipshod developers (although there are some). It's lazy, slipshod management of developers.
Certainly in some cases. In some it's not.
However building in better testing is like writing better code. It doesn't add a lot of extra time if you learn to do it well. Whether there's still time in a compressed schedule, that's possibly an issue if things are wildly optimistic.
January 13, 2015 at 2:23 pm
It's really an easy out for a developer to just go ahead and blame management for their buggy software, "it couldn't possibly be my fault!". In the end, as the developer, I created it and I'm going to be held responsible for it. Nobody wants buggy software, no matter how aggressive the schedule. I'm not suggesting that all the blame falls at the developers feet, but I just can't agree with saying it's all management's fault either.
January 13, 2015 at 2:41 pm
The essential problem isn't lazy, slipshod developers (although there are some). It's lazy, slipshod management of developers.
Certainly in some cases. In some it's not.
However building in better testing is like writing better code. It doesn't add a lot of extra time if you learn to do it well. Whether there's still time in a compressed schedule, that's possibly an issue if things are wildly optimistic.
The problem is that things usually are 'wildly optimistic', and/or unknown, and/or underestimated.
Advocating quality code is like standing up for mom, apple pie, and the flag. No-one disagrees about the need for it. And most of the developers I've known -- after having been one, and then managing a large number of them over the last 37 years -- have been intelligent, conscientious, quality-minded people.
The problem is in the nature of software development itself, and the way it's managed (or often, mismanaged). Many (most?) development projects miss their task estimations by several factors of time, and I firmly believe the causes are usually due to the reasons I've already stated: unrealistic deadlines, poor/non-existent specifications, scope creep. Developers can and should manage their code quality, but they can't often control these external factors -- which are the responsibility of those managing the project.
Quality project management is needed at least as much as is quality code, and I would argue the former begets the latter.
January 13, 2015 at 2:51 pm
aaron mertes (1/13/2015)
It's really an easy out for a developer to just go ahead and blame management for their buggy software, "it couldn't possibly be my fault!". In the end, as the developer, I created it and I'm going to be held responsible for it. Nobody wants buggy software, no matter how aggressive the schedule. I'm not suggesting that all the blame falls at the developers feet, but I just can't agree with saying it's all management's fault either.
I'm not suggesting developers blame management for buggy software, but let's also be realistic about the kind of environment in which many developers must work: one with unreasonable deadlines, poor or non-existent specifications, and perpetual scope creep.
Most developers I've known -- and believe me, I've known hundreds of them -- care greatly about the quality of their work. You can tell when someone is simply making excuses. You can also tell when someone is trying conscientiously to deliver the goods but has been set up for failure by the lack of competent project management.
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply