The comments from your earlier article probably would apply to this article also
@see: http://www.techrepublic.com/blog/european-technology/should-developers-be-sued-for-security-holes/1109
Discussion on:
View:
Show:
"A repeated complaint during a recent TechRepublic..."
This is not new , this sort of thing has been going on since Ali the inventor of the Abacus sacrificed beads that moved for a really nice shade of purple that would indicate his passion for numeracy.
Security is only one of the casualties of "sound business thinking" in fact it's more collateral damage than anything else.
Agile has in many respects made things worse. It's far easier to react to changes so now we get far more changes we can react to...
Will agile save the day, give a break.
Security is only one of the casualties of "sound business thinking" in fact it's more collateral damage than anything else.
Agile has in many respects made things worse. It's far easier to react to changes so now we get far more changes we can react to...
Will agile save the day, give a break.
sloppy or flawed code. The code developer is the one who is releasing the finished product, on the scene above it is the company via the project manager who is responsible for NOT letting the programmer to write better code. The problem is the mindset that because changes are easy to track, they think they're easy to make and therefore it's OK to release the product with known faults to correct later. The only way to stop this mindset and process is to make them pay for doing it, either by hitting the hip pocket or by locking them up for a period. Unless they get hit that way they won't change their behaviours.
In every other engineering concern this approach would see those responsible paying huge compensation bills and facing charges of one sort or another for deliberate negligence.
In years past, the project was NOT considered finished or delivered until AFTER it was fully tested and found to be working perfectly. The follow on effect was the company did not get paid until the project passed the full testing cycle that was developed by either client staff independent of the project team or an party external to both the client and the project team. Too often, today, we see projects and applications provided to the end users without a thorough testing cycle due to the 'It's easy to change mindset.'
In every other engineering concern this approach would see those responsible paying huge compensation bills and facing charges of one sort or another for deliberate negligence.
In years past, the project was NOT considered finished or delivered until AFTER it was fully tested and found to be working perfectly. The follow on effect was the company did not get paid until the project passed the full testing cycle that was developed by either client staff independent of the project team or an party external to both the client and the project team. Too often, today, we see projects and applications provided to the end users without a thorough testing cycle due to the 'It's easy to change mindset.'
When you're told to do something stupid, comment your code:
// ADA; LL; 9-4-2012
ADA = against developer's advice
// ADA; LL; 9-4-2012
ADA = against developer's advice
via corporate memos, but I like the idea of putting it in the code base as well. It will flag it for the future and may encourage someone to clean it up while doing some other work on it.
It makes no difference, in fact, the team that has the project that is testing out agile is actually producing far more bugs than the teams that aren't.
The company thinks they do agile, but its agile with heavy governance and well.... its basically waterfall.
I recently read more about agile, and as I did I began to recognize the differences.
So maybe "real" agile might actually solve these problems afterall.
I recently read more about agile, and as I did I began to recognize the differences.
So maybe "real" agile might actually solve these problems afterall.
Basically in order to start you have to have a plan.
Despite knowing full well things will change, that plan is used to set the expectation.
Now if you were to be so foolish as to recognise the change in requirements by changing the plan, you will be adjudged to have failed to meet the expectation.
So what happens, we stick to the plan, but describe the process with terms gleaned from the glossary of the latest how to do agile book....
Despite knowing full well things will change, that plan is used to set the expectation.
Now if you were to be so foolish as to recognise the change in requirements by changing the plan, you will be adjudged to have failed to meet the expectation.
So what happens, we stick to the plan, but describe the process with terms gleaned from the glossary of the latest how to do agile book....
Why is there never enough time to do it properly the first time, but always enough time to fix it afterwards?
fixed, in most cases. It's simply a mindset issue of 'can't be bothered to do it right like a real professional.' Sometimes it's the mindset of - let's cheap this out as much as possible.
Well it must be, mustn't otherwise things would have changed, like millenia ago.
"Why is there never enough time to do it properly the first time, but always enough time to fix it afterwards?"
1. Because if the product doesn't get out the door the company goes under.
2. Because if the product isn't a hit in the market, the security hole doesn't matter a single bit. Think of options 3 and 4.
It's easy to spew insightful sarcasm and think it gets to the nub of the issue but if you're an analyst, this is a fairly normal business process. Any business process 'errors' that occur regularly are standard.
You can still be sarcastic about them, but if you want true insight, spend some time thinking about the incentives for all parties involved. Then think about the incentives for the parties that make decisions.
1. Because if the product doesn't get out the door the company goes under.
2. Because if the product isn't a hit in the market, the security hole doesn't matter a single bit. Think of options 3 and 4.
It's easy to spew insightful sarcasm and think it gets to the nub of the issue but if you're an analyst, this is a fairly normal business process. Any business process 'errors' that occur regularly are standard.
You can still be sarcastic about them, but if you want true insight, spend some time thinking about the incentives for all parties involved. Then think about the incentives for the parties that make decisions.
that can also take away sales of other products from the same company due to the bad rep of the one product. The decision to get it out the door regardless of status is usually only applied when some marketing or management person with little knowledge about what's needed in development pick a date out of the air and advertise that, then push to have people meet it.
I have seen a software project pushed to an advertised completion date that was not realistic with the staffing levels available. The end result was top management decided meeting the date was more important than budget, so overtime was approved and the project team worked ten hours a day, six days a week for two months to get the project completed and properly tested by the deadline - fully tested product delivered seven days before the deadline, allowing sufficient time for full deployment to the hardware before the units involved shipped out to the troops in the field. It showed it can be done properly, but you have to take the hit is someone announces or sets an unrealistic time frame. No one liked working 60 hours weeks for two months solid, but they all got 4 weeks paid leave as a bonus on top of the overtime payment that almost doubled their weekly pay, and all for digging in and helping dig the ultra top brass out of their stupidity.
I have seen a software project pushed to an advertised completion date that was not realistic with the staffing levels available. The end result was top management decided meeting the date was more important than budget, so overtime was approved and the project team worked ten hours a day, six days a week for two months to get the project completed and properly tested by the deadline - fully tested product delivered seven days before the deadline, allowing sufficient time for full deployment to the hardware before the units involved shipped out to the troops in the field. It showed it can be done properly, but you have to take the hit is someone announces or sets an unrealistic time frame. No one liked working 60 hours weeks for two months solid, but they all got 4 weeks paid leave as a bonus on top of the overtime payment that almost doubled their weekly pay, and all for digging in and helping dig the ultra top brass out of their stupidity.
The last part sounds like a dream, get 4 weeks paid time off, overtime, top brass realizing its mess. Fat chance, and only if they're really nice. Top brass doesn't have a clue, the software people like to have aggressive schedules (or risk losing the job), and all are gambling that the customer will not hit one of those problem spots. But, given the golden rule, the man with all the gold makes the rules. If he wants it out tomorrow, he will get it out tomorrow, with or without us (or someone else). To the top brass, the software production is a competitive business. If we can't get it out there in their time frame, then the feeling is that someone else will. And, that someone else will sell them a good con story, say they can get it out when wanted, then end up being late and over budget, or send out buggy software.
When it is going to be late, the software team announces that the software is 90% completed and needs more time to finish the last 10%. And, the company, after investing in the project, is highly likely to continue investing until the completion of the project. And, if the software engineers make it to the end, they will have spent many 60 hour weeks and will be completely burned out. A classic sweatshop.
When it is going to be late, the software team announces that the software is 90% completed and needs more time to finish the last 10%. And, the company, after investing in the project, is highly likely to continue investing until the completion of the project. And, if the software engineers make it to the end, they will have spent many 60 hour weeks and will be completely burned out. A classic sweatshop.
was many years ago and in a medium sized company.
Imagine a business concerned about money. Who knew?
Further, nothing is ever perfect. One should think in terms of functional application. That is, will it work for 9x.xx% of the time for 9x.xx% of the users. Maybe that is good enough.
There is no "perfect" security. Get over it.
You have to plan, but over planning hits a point of diminishing returns pertty quick. Not possible to forsee everthing. Deal with it.
Most software isn't going to be widely used anyway. 2 million iPhone apps? are you kidding?
And lastly most software has a short life span. Quite likey that all software done today will be long fogotten in 20 years. Every thing all programmers are doing and have done up until now is slowly sliding to the recycle bin.
Further, nothing is ever perfect. One should think in terms of functional application. That is, will it work for 9x.xx% of the time for 9x.xx% of the users. Maybe that is good enough.
There is no "perfect" security. Get over it.
You have to plan, but over planning hits a point of diminishing returns pertty quick. Not possible to forsee everthing. Deal with it.
Most software isn't going to be widely used anyway. 2 million iPhone apps? are you kidding?
And lastly most software has a short life span. Quite likey that all software done today will be long fogotten in 20 years. Every thing all programmers are doing and have done up until now is slowly sliding to the recycle bin.
leave all security measures wide open to attack, and that's what a lot of bad code does do.
Developers often design systems, and design and build software which affect many people lives; however unlike physical architects and engineers, they are often regarded as an expense and interchangeable production line workers who's judgment and ideas are often pushed to one side; this is short sighted, because computer systems are now part of the infrastructure and not a luxury, for many businesses.
A lot of the problems I have experienced are due to lack of investment in Developers (e.g. suitable training, R&D time, a sensible career path, resources) and allowing account managers and sales staff "to get away with murder".
I see the linear Waterfall approach as too rigid and inflexible; however I regard many Agile approaches and practices (e.g. SCRUM) as too extrovert oriented and cost-plus. I prefer an iterative layered approach (like Feature-driven development), where you have an overall picture (e.g. a specification), map each layer, build any components which it is not practical to source externally and assemble the product layer by layer, testing as you go, much like a physical engineer would.
I suspect a lot of Agile is really Social Engineering of the customer, managers, sales and development, when what is actually needed is competent people, systematic planning, a big dose of realism, and respect.
A lot of the problems I have experienced are due to lack of investment in Developers (e.g. suitable training, R&D time, a sensible career path, resources) and allowing account managers and sales staff "to get away with murder".
I see the linear Waterfall approach as too rigid and inflexible; however I regard many Agile approaches and practices (e.g. SCRUM) as too extrovert oriented and cost-plus. I prefer an iterative layered approach (like Feature-driven development), where you have an overall picture (e.g. a specification), map each layer, build any components which it is not practical to source externally and assemble the product layer by layer, testing as you go, much like a physical engineer would.
I suspect a lot of Agile is really Social Engineering of the customer, managers, sales and development, when what is actually needed is competent people, systematic planning, a big dose of realism, and respect.
Rarely have I encountered a dumber idea than SCRUM ... can't believe that I actually see shops requiring "deep knowledge" of it; what for? so you can spend all of your time contemplating previous "sprints?" total garbage ...
And there really are some of us who consulted often with stakeholders before there was such a thing as "agile programming" ... isn't it nothing more than common sense to periodically ask your client/user if what you're doing is what they need instead of waiting two years and having them say, "no, that's not it at all ... start over"
same old story; gullible people buying nonsense from snake oil salesmen
And there really are some of us who consulted often with stakeholders before there was such a thing as "agile programming" ... isn't it nothing more than common sense to periodically ask your client/user if what you're doing is what they need instead of waiting two years and having them say, "no, that's not it at all ... start over"
same old story; gullible people buying nonsense from snake oil salesmen
Far too many times people do not take the constraints / requirements seriously. I have watched people start projects and put off actions to sometime in the future where it is more convenient. If you make it a habit from day one to push the project to meet the projected completion date with the state constraints it will turn out better. People will give you a better timeline and more accurate constraints because they know this is what you are going to drive for. If the customer ever gets the idea that everything is subject to change sometime in the future your project will grow legs and last forever.
The ones we started with.
The ones we should have started with
Or the ones we finished with.
This article was aimed at developers, our customer is the business, and they are well aware that they can change anything.
Try and keep up mate.
The ones we should have started with
Or the ones we finished with.
This article was aimed at developers, our customer is the business, and they are well aware that they can change anything.
Try and keep up mate.
I have to say that both side are at fault. I was "on call" for abnormal endings, and was called for a "numeric termination"...my response was to call me when I get to work. This upset many as it was a month end and quarterly closing.
I did not know what the numeric value should be, so i could not fix that. As for the program, a simple TEST FOR NUMERIC values BEFORE applying would have solved the issue IN DEVELOPMENT.
I knew the programmer who was EXCELLENT by the way, and all other code in that and other programs did have the appropriate tests. I warned him to "go back over code after an interruption". Now we know why it takes longer to get a project out the door INTERRUPTIONS....are we finished yet???
There are many more that fall into the above category, I have to admit ME TOO. But a CODE REVIEW (extra time and step) clears this type of problem.
i believe that distraction is the major cause of developer mistakes. There are other instances where some thought should be applied to the logic before coding it. The best example I found was a tree structure, where the top had one, with two as the next level and 12 at the same level with 20 below this level.
The programmer tested level 1 for every 20+12+2 when the record was read sequentially. On a magnitude of hundreds of thousands of records the time wall clock or CPU was as much as 600 percent above making the testing in a bottom up sequence.
NUFFabout developers....MANAGEMENT example...
Project was running late, but was to be brought in on time. The project managing VP was brought in to go over the requirements. The scope of the project was laid out with all completed tasks noted. The one sub-project had not been started (did less with less personnel, or the old "we saved money").
At this point the VP said he did not need the project, go ahead and implement ahead of schedule, we are done. The numbers at this point were fantastic, AHEAD OF SCHEDULE and WE DID IT WITH LESS MANPOWER.
The only problem with this picture was that the "missing project" WAS THE INPUT TO THE REST OF THE PROJECT. The project had a new VP the following week. The project wrapped up six months later...LATE and OVER BUDGET.
There are a few other "management" issues too.
..Fund a study to convert assembler code to cobol, where the code was bit manipulation for telecomm programs. The study was completed, money paid, and the idea tossed out.
..Toss out all coding manuals from the library, everyone is experienced enough so they do not need them. A secretary did the task, after hours, so no one was the wiser until they had to look up something.
.."Do not talk to the users, they have no business knowing what problems there are in the system, or the order I have chosen to report or fix the problems." That advise was followed until lunch time. When anyone was reproached about the lunch, the response was SEE YOU IN HR (Human Resources NOT hour:) .
..Best of the bunch. A user specified EXACTLY how the program was to be written. I complained to my supervisor (I was the new guy) explaining the problem and what the results would be. After laughing he asked the individual if he was serious,and he was. So i was told DO IT.
The next day 30 boxes of computer paper was delivered to the individuals office not quite filling the office, but making it difficult to get around. The reason was that each page had a heading for every item in the file, but only reported on less than one percent of the records. Apparently the lesson was learned, he never told anyone how to write a program again.
I did not know what the numeric value should be, so i could not fix that. As for the program, a simple TEST FOR NUMERIC values BEFORE applying would have solved the issue IN DEVELOPMENT.
I knew the programmer who was EXCELLENT by the way, and all other code in that and other programs did have the appropriate tests. I warned him to "go back over code after an interruption". Now we know why it takes longer to get a project out the door INTERRUPTIONS....are we finished yet???
There are many more that fall into the above category, I have to admit ME TOO. But a CODE REVIEW (extra time and step) clears this type of problem.
i believe that distraction is the major cause of developer mistakes. There are other instances where some thought should be applied to the logic before coding it. The best example I found was a tree structure, where the top had one, with two as the next level and 12 at the same level with 20 below this level.
The programmer tested level 1 for every 20+12+2 when the record was read sequentially. On a magnitude of hundreds of thousands of records the time wall clock or CPU was as much as 600 percent above making the testing in a bottom up sequence.
NUFFabout developers....MANAGEMENT example...
Project was running late, but was to be brought in on time. The project managing VP was brought in to go over the requirements. The scope of the project was laid out with all completed tasks noted. The one sub-project had not been started (did less with less personnel, or the old "we saved money").
At this point the VP said he did not need the project, go ahead and implement ahead of schedule, we are done. The numbers at this point were fantastic, AHEAD OF SCHEDULE and WE DID IT WITH LESS MANPOWER.
The only problem with this picture was that the "missing project" WAS THE INPUT TO THE REST OF THE PROJECT. The project had a new VP the following week. The project wrapped up six months later...LATE and OVER BUDGET.
There are a few other "management" issues too.
..Fund a study to convert assembler code to cobol, where the code was bit manipulation for telecomm programs. The study was completed, money paid, and the idea tossed out.
..Toss out all coding manuals from the library, everyone is experienced enough so they do not need them. A secretary did the task, after hours, so no one was the wiser until they had to look up something.
.."Do not talk to the users, they have no business knowing what problems there are in the system, or the order I have chosen to report or fix the problems." That advise was followed until lunch time. When anyone was reproached about the lunch, the response was SEE YOU IN HR (Human Resources NOT hour:) .
..Best of the bunch. A user specified EXACTLY how the program was to be written. I complained to my supervisor (I was the new guy) explaining the problem and what the results would be. After laughing he asked the individual if he was serious,and he was. So i was told DO IT.
The next day 30 boxes of computer paper was delivered to the individuals office not quite filling the office, but making it difficult to get around. The reason was that each page had a heading for every item in the file, but only reported on less than one percent of the records. Apparently the lesson was learned, he never told anyone how to write a program again.
If you want to talk about security holes, yes there is time to fix them later.
When you talk sloppy code, that is another story. One developer writes a program and uses a bad design and writes generally sloppy code. The next developer comes along and makes changes or adds functionality but is locked into using the original bad design. The developer after that is then locked into the same cycle, being forced to use bad code and bad design.
I always cringe when I am asked to move onto a project I didn't help write. Too often I open up the code files to take a look and I just want to cry.
* Bad design.
* No organization to the file so you can't find the method you are looking for without scanning through 5000 lines of code.
* No proper formatting to the code.
* No comments.
* No documentation
It may sound like nitpicking but simple organization of your code files and a comment here or there can make a WORLD of difference.
When you talk sloppy code, that is another story. One developer writes a program and uses a bad design and writes generally sloppy code. The next developer comes along and makes changes or adds functionality but is locked into using the original bad design. The developer after that is then locked into the same cycle, being forced to use bad code and bad design.
I always cringe when I am asked to move onto a project I didn't help write. Too often I open up the code files to take a look and I just want to cry.
* Bad design.
* No organization to the file so you can't find the method you are looking for without scanning through 5000 lines of code.
* No proper formatting to the code.
* No comments.
* No documentation
It may sound like nitpicking but simple organization of your code files and a comment here or there can make a WORLD of difference.
Sloppy code.
How do you tell the difference between code written by an idiot and code they were forced to write under instructions from an idiot...
These discussions were triggered by concerns about product quality, code quality is a whole 'nother animal.
Surely you aren't one of those naive fools who believe the two issues are related?
How do you tell the difference between code written by an idiot and code they were forced to write under instructions from an idiot...
These discussions were triggered by concerns about product quality, code quality is a whole 'nother animal.
Surely you aren't one of those naive fools who believe the two issues are related?
There is never time to do it right but there's always time to do it over again!
"The Missing Man Month" by Fred Brooks should be required reading for both the developers and their managers. I suspect that the problem is insoluble!
"The Missing Man Month" by Fred Brooks should be required reading for both the developers and their managers. I suspect that the problem is insoluble!
There is already a movement to make software companies liable for their product. I agree. No more open ended EULA's. You make it, you sell it, you're liable. Simple to me. We hold many of our product manufacturers liable for this and that. So much of our life now is around software doing it's job, metro rail services, air traffic, automobile systems, and medical systems. For the sake of profit is crap. You knew the mission was dangerous when you accepted it. When people quit bending under the pressure and or promising something just to get the job, stop!!!
Boss, I'm not doing what you said, because of insert technical mumbo jumbo here.
Right new boy, your predecessor struggled with this, but I'm sure you have enough incentive (read a job) to meet the "customer" need.
WTFU
Right new boy, your predecessor struggled with this, but I'm sure you have enough incentive (read a job) to meet the "customer" need.
WTFU
It's sometimes incomplete data validation and associated error trapping.
Some years ago I was asked to debug a crashed program. The crash was caused by the string NOPHONE in a telephone number field. The original programmer had assumed a phone number would always be numeric.
Some years ago I was asked to debug a crashed program. The crash was caused by the string NOPHONE in a telephone number field. The original programmer had assumed a phone number would always be numeric.
The programmer assumed no one would enter a non-numeric phone number, that's called developer testing, been about for ages.
PS nophone is 6674663
PS nophone is 6674663
it was reinforced that when you established a data input field you also included the code to ensure the data was checked for validity before it was used for anything else - I was told that's the professional way to do it right.
It's why we invented testers...
And analysts, you say number to a dev, he's already made a whole range of unconscious assumptions
Now if it was going to an int field in the db, not masking the entry field for numbers, would be a poor effort.
If it was string in the db, then something went wrong somewhere, because it having non-numeric data in it shouldn't have mattered. In fact that would mean the assumption that number was numeric had been foolishlt made in more than the data entry.
This is one of those deceptively simple ones we've all fell over at least once. Now when someone says it's number, I start checking definitions, not often number = integer. Even if it does in the uderlying data, I've seen outputs called numberofClients that were populated with "You have 1 client" as such. It's an easy mistake to make. No documentation, no unit tests and no time, it will get made, I guarantee it.
last contarct I had I was given aspect where Invoice Number was defined as an int I built the entire app inclusing database based on the at spec provided to me by the IT manager no less.
Bug 1 I can't get the invoice number I/198767 into the box...
And analysts, you say number to a dev, he's already made a whole range of unconscious assumptions
Now if it was going to an int field in the db, not masking the entry field for numbers, would be a poor effort.
If it was string in the db, then something went wrong somewhere, because it having non-numeric data in it shouldn't have mattered. In fact that would mean the assumption that number was numeric had been foolishlt made in more than the data entry.
This is one of those deceptively simple ones we've all fell over at least once. Now when someone says it's number, I start checking definitions, not often number = integer. Even if it does in the uderlying data, I've seen outputs called numberofClients that were populated with "You have 1 client" as such. It's an easy mistake to make. No documentation, no unit tests and no time, it will get made, I guarantee it.
last contarct I had I was given aspect where Invoice Number was defined as an int I built the entire app inclusing database based on the at spec provided to me by the IT manager no less.
Bug 1 I can't get the invoice number I/198767 into the box...
I didn't have access to change the database, so instead I changed the code to convert the entry to Hex before saving to the database.
the work properly any more.
of the reasons I moved away from working on code was it was getting harder and harder to get people to provide specs at all, let alone decent specs. Part of the reason for that is if the specs are well done, they have to work a lot harder to move the goal posts on you and introduce changes. I got fed up of having the specs sound more and more like airy fairy wish lists than a spec sheet, so walked away to avoid having my ethics compromised by being forced to produce crap.
The phone number issue is classic. Put a number in the box and it worked, job done, on y va.
It is what it is.
It is what it is.
the wrong type of information entered, for what it does with insufficient information entered, for having the right information entered - to see what it does with it. It should also be tested to see that it performs as expected and as intended and as wanted - they aren't always the same by the end of the project.
Before you can test, you need definitions or what right and wrong are.
Telephone number is or is not numeric is an assumption. A test of an assumption, proves or disproves the assumption not the code.
Telephone number is or is not numeric is an assumption. A test of an assumption, proves or disproves the assumption not the code.
for most software you can usually work out what is or isn't acceptable data for the input fields from their field type and / or their field name. Heck, even how they display ion the informs will often tell you a lot about what should be in there.
However, you go about the application does need to be tested or you have no way of showing it's completed and you can be paid. The worst problem I've ever seen in a test environment was a tester was in a hurry to pass a program so they only tested it with the info provided by the client, all of it good data that had everything right, so of course it passed - the program concerned was returned ten days later as having failed client field tests because they sat some of the data entry clerks in front of it and said to enter data, as soon as a typo happened the whole thing crashed. In the rush to get it out the door people involved did not incorporate any data input validation processes. Needless to say that team were unemployed by the end of the week, while some of us were busy fixing the code. The program was good apart from the few routines for data validation prior to using it. That's a classic example of not proper testing - any software test should include what happens when the data is invalid.
However, you go about the application does need to be tested or you have no way of showing it's completed and you can be paid. The worst problem I've ever seen in a test environment was a tester was in a hurry to pass a program so they only tested it with the info provided by the client, all of it good data that had everything right, so of course it passed - the program concerned was returned ten days later as having failed client field tests because they sat some of the data entry clerks in front of it and said to enter data, as soon as a typo happened the whole thing crashed. In the rush to get it out the door people involved did not incorporate any data input validation processes. Needless to say that team were unemployed by the end of the week, while some of us were busy fixing the code. The program was good apart from the few routines for data validation prior to using it. That's a classic example of not proper testing - any software test should include what happens when the data is invalid.
All you are doing there is swapping one set of assumptions for another.
The guy who kicked this thread off either omitted key information, leaving us assuming, or has passed on their own assumption.
Should the telephone number box only allow numbers or should whatever expects only numbers be changed. There's absolutely nothing in the code as we've been presented it, to say which bit is wrong
Now I'll agree that comprehensive brute force testing (inefficient and unreliable) would find the inconsistency, but any fix without disambiguating the specification with the stake holders would be a guess based of the fixer's assumption.
That's removing the inconsistency, worse still from your point of view about quality software, which end would be fixed? Least effort on the vendor's part, obviously....
The guy who kicked this thread off either omitted key information, leaving us assuming, or has passed on their own assumption.
Should the telephone number box only allow numbers or should whatever expects only numbers be changed. There's absolutely nothing in the code as we've been presented it, to say which bit is wrong
Now I'll agree that comprehensive brute force testing (inefficient and unreliable) would find the inconsistency, but any fix without disambiguating the specification with the stake holders would be a guess based of the fixer's assumption.
That's removing the inconsistency, worse still from your point of view about quality software, which end would be fixed? Least effort on the vendor's part, obviously....
It was defined as a number. So you code the box to only accept a number. The testers can only verify that it only accepts a number. It goes to a client and they complain cause they want to enter text.
Yes, it is an assumption only a numeric data input is needed, however, there would be other information on hand about the relevance of that assumption. First, the majority of data input fields usually have an example beside them, second the location where the program is likely being used will also add information - all phone numbers in Australia are numeric only now, and I think that's the case for the USA too - fifty years ago they were alpha numeric, but all numeric now. Thus you would be able to make a lot of very valid assumptions from the info available, despite not having a proper set of tests.
Sure, it would be better to conduct tests based on properly defined specs; but it's better to do tests based on assumed specs that you document what's being done and why, than not to do any tests what so ever.
Today many databases programs have built-in data validation that kicks in based on the type of field declaration, but not all do, and sometimes you want more than what they offer. When I was first taught programming and developing applications there was no built-in data validation, so we were taught to first take the input data and run it through a data validation routine prior to passing it into the program for further action. Not all that hard to do, but something you had to remember to do and do right. Often with names it was an automatic process to have all the characters converted to the same case so they would always be handled the same way later and were easier to match the strings properly. Testing for this sort of thing should always be a matter of course, and it used to be, but isn't any more.
Today we get caught between the devil of 'only do what we tell you to do' and the deep blue sea of 'but my personal ethics requires I do it right.' Many years ago I got faced with a major case where I could see that who ever prepared the specs had no idea of what they were talking about and management weren't prepared to accept the job as written was undeliverable due to inbuilt errors. When ordered to do the job that way or else, I handed in my resignation and took the or else. I soon found other work in related fields in the same organisation. The people who refused to listen to me were terminated within weeks of the finished garbage being presented to the client and proven to not work as expected. The project resulted in the client and terminating some of the people as well, for writing the specs the way they did. I know in these situations some people will deliver the garbage and some people will deliver the resignation, and some will fight like hell to get the specs rewritten the right way. Which ever way a person goes will be their own choice; but those who insist the garbage be done and sold should be held responsible for it's production - that's my thoughts on it.
Below is some of the sort of issues that can give data validation checking staff major headaches:
I spend a LOT of time conducting database searches while helping people with their family history research now, and one of the most annoying things is when you find a database that will NOT allow any form of wildcard search, thus a search on ROBERTSON will not even look at ROBERTSONS etc, to make it worse, some others do soundex searches thus a search for PEARL will include PEERL in the answer as they sound similar - and until you've played with the database you don't know which way it goes. But what's most annoying is those that do an exact match no matter what, thus Delray is not matched with DelRay and older style spelling of the same name - further aggravated by people making typos when inputting the data.
Sure, it would be better to conduct tests based on properly defined specs; but it's better to do tests based on assumed specs that you document what's being done and why, than not to do any tests what so ever.
Today many databases programs have built-in data validation that kicks in based on the type of field declaration, but not all do, and sometimes you want more than what they offer. When I was first taught programming and developing applications there was no built-in data validation, so we were taught to first take the input data and run it through a data validation routine prior to passing it into the program for further action. Not all that hard to do, but something you had to remember to do and do right. Often with names it was an automatic process to have all the characters converted to the same case so they would always be handled the same way later and were easier to match the strings properly. Testing for this sort of thing should always be a matter of course, and it used to be, but isn't any more.
Today we get caught between the devil of 'only do what we tell you to do' and the deep blue sea of 'but my personal ethics requires I do it right.' Many years ago I got faced with a major case where I could see that who ever prepared the specs had no idea of what they were talking about and management weren't prepared to accept the job as written was undeliverable due to inbuilt errors. When ordered to do the job that way or else, I handed in my resignation and took the or else. I soon found other work in related fields in the same organisation. The people who refused to listen to me were terminated within weeks of the finished garbage being presented to the client and proven to not work as expected. The project resulted in the client and terminating some of the people as well, for writing the specs the way they did. I know in these situations some people will deliver the garbage and some people will deliver the resignation, and some will fight like hell to get the specs rewritten the right way. Which ever way a person goes will be their own choice; but those who insist the garbage be done and sold should be held responsible for it's production - that's my thoughts on it.
Below is some of the sort of issues that can give data validation checking staff major headaches:
I spend a LOT of time conducting database searches while helping people with their family history research now, and one of the most annoying things is when you find a database that will NOT allow any form of wildcard search, thus a search on ROBERTSON will not even look at ROBERTSONS etc, to make it worse, some others do soundex searches thus a search for PEARL will include PEERL in the answer as they sound similar - and until you've played with the database you don't know which way it goes. But what's most annoying is those that do an exact match no matter what, thus Delray is not matched with DelRay and older style spelling of the same name - further aggravated by people making typos when inputting the data.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
