Hot answers tagged

47

A Duck From http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html: A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.


43

Contrary to intuition, the number of errors per 1000 lines of does seem to be relatively constant, reguardless of the specific language involved. Steve McConnell, author of Code Complete and Software Estimation: Demystifying the Black Art goes over this area in some detail. I don't have my copies readily to hand - they're sitting on my bookshelf at work - ...


26

Refactor the existing source code. I know it sucks but if there's a lesson I've learned in development its that you don't just throw away a working project because the code is terrible. Your game is working. Keep it that way. Keyboard events are being handled in gigantic if blocks? Spin that off into a class and segregate functionality into methods. You'll ...


22

Actually in manufacturing (and quality assurance) there is something called a Red Rabbit Test (aka Red Herring) that refers to putting a known bad part into the machine or process and making sure it's detected. Red Rabbit Test used to check how long it takes to identify a defect. In this test, a red part is added to the mix and the time until it is ...


21

According to Fundamental Concepts of Dependability: A system failure is an event that occurs when the delivered service deviates from correct service. A system may fail either because it does not comply with the specification, or because the specification did not adequately describe its function. An error is that part of the system state that may ...


19

Code review is something people do, static analysis is something machines do. There are (sometimes good) static analysis tools. Code review is when a colleague/mentor/professor/friend goes over your code and gives you constructive criticism. Static analysis is, on the other hand, an automated process in which a machine, informed by what it knows about the ...


19

Why should we have separate development, testing, and production environments? You have several activities going on concurrently: development - where developers commit code, make mistakes, experiment, etc... testing - where tests are run, manually or automated, and due to complexity, can consume a lot of resources. production - where value is created for ...


18

The claim is - at best - naive. SLOC isn't exactly a reliable metric for anything useful, except perhaps comparing the size of two or more projects. Furthermore there are two distinct types of SLOC, physical LOC and logical LOC, and those might differ significantly. Consider this example, from Wikipedia: for (i = 0; i < 100; i += 1) printf("hello"); ...


16

Drop that "background" out of your head - it's useless for the assignment you've got. For both programs, do the same: read the code, file by file, line by line. Anything that doesn't feel right, add it to the list of issues. Typos, duplicate or dead code, things that are hard to understand, IDE/compiler warnings, anything. Use free form comments, don't ...


15

The basic Six Sigma activities are captured by the acronym DMAIC, which stands for: Define, Measure, Analyze, Improve, Control. You apply these to the process that you want to improve: define the process, measure it, use the measurements to form hypotheses about the causes of any problems, implement improvements, and ensure that the process remains ...


15

It is reasonable to negotiate for having automated test scripts as a deliverable, but it is not reasonable to expect to get them if they were not explicitly included in the (initial) agreement. Unless the project is explicitly being executed under a development method that implies automated testing, such as TDD, or you negotiated for delivery of the scripts ...


14

As this question created some controversy, let me start off this answer with my background: Apart from being exposed to V&V in daily project work, I worked for several years in the software engineering department of my alma mater and am a lecturer for software engineering. While this does not guarantee that anything I say is correct, I hope it at least ...


14

Short answer: If you don't have the time to do it properly now, will you have the time to do it properly later? Long answer: Maintenance is 70% of the effort in developing software. The more technical debt you build up in the code, the more maintenance effort is required. Bugs cost more effort to fix the longer they go unfixed, because of the need to ...


12

If your team isn't skilled (as in your definition), you will get nothing done at all. In this case the process doesn't matter. Not skilled in the sense of not much experience would be another matter. If your people are talented, but have not much experience with projects, then a good process may help avoid problems. Testing and early response from customers ...


12

This observation is very old, and comes from a very venerable source, namely Fred Brooks in his book "The Mythical Man Month". He was a top manager at IBM, and managed many programming projects including the milions-of-lines operating system OS/360. In fact he reported that the number of bugs in a program is not proportional to the length of code, but ...


12

It depends on what you mean by "succeed". If you mean succeed in the classical sense, as in to make as much money as possible with absolutely no regard to personal health, relationships, etc. then it will be much harder if you are not programming all the time. People who get jobs at Google, VMware, etc. are either geniuses or work 60-80 hour weeks to make ...


11

Static analysis is the process of analyzing a software without executing it. This is very good and recommended, but you have to keep in mind that different static analysis tools have different understanding of the code they are studying, hence they can signal (or not signal) different issues. One tool can give a clean report, and the other may complain ...


11

I'd like to read the opinion of experts on whether compiled, strictly-typed languages help programmers write robust code easier, having their backs, checking for type mismatches, and in general, catching flaws in compile time that otherwise would be discovered in runtime ? For some programs they do. For some programs they require you to do things that are ...


10

There are some tools out there which can find 'dead code' in your programs. you can read about them on Stack Overflow threads here and here. a small summary: use the gcc compiler flags -Wunused and -Wunreachable-code, and then use a tool like lcov to find the unused methods.


10

I think that there is indeed a role for quality assurance in an agile organization, especially one that has to adhere to a quality management system such as ISO9001, ISO13485 for the medical device industry or AS9000 in the aerospace industry, for the purposes of meeting customer requirements, regulations, or corporate mandates. There are two important ...


9

Software verification is the collection of methods used to determine if the software system that is being constructed is being built right. Some aspect of the system, whether it's the design, the implementation, or the test cases, are compared to the documented requirements of the system. A software inspection is a particular technique that can be used to ...


8

Books like http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 should be witness enough to how large, legacy poor quality code bases are common in the industry. My guess at why you have not heard or seen, and, more importantly, you will never likely hear about them until you work on one of them yourself, is, nobody seems capable ...


8

Obviously, firing them or reporting them to management is an option; whether or not it would be my first choice as an option would depend on whether or not they're also a good developer. It seems wrong-headed to send a very smart person packing just because they don't follow the process. Especially if you don't fully understand why they don't follow the ...


8

I'm going to preface my answer with the fact that my expertise is in AS9100 and AS9115. AS9100 is the aerospace industry standard that incorporates additional aerospace industry requirements with ISO 9001. The revision of AS9100 that I'm familiar with is AS9100C, which corresponds to ISO9001:2008. There may be minor differences between the two. The first ...


8

I prefer to test the interface, not the implementation. If your consumers have access to your code, tests are a form of documentation that is guaranteed to be up to date. If you only test for 200, consumers may come to rely on that, and changing to 204 (always or sometimes) is more likely to be a breaking change. From a more selfish point of view, tests ...


7

The situation you are describing is the same situation you will meet everywhere in the industry concerning so called legacy-code. To get a notion why you probably not should start from scratch I suggest you read this nice article from Joel. http://www.joelonsoftware.com/articles/fog0000000069.html Furthermore, I suggest to get a copy of Feathers' book "...


7

There are a number of metrics that can be gathered from code reviews, some even extending throughout the lifecycle of the project. The first metric that I would recommend gathering is defect removal effectiveness (DRE). For every defect, you identify what phase the defect was introduced in and what phase it was removed in. The various defect detection ...


7

At a technical level, bugs, features, it's all the same, a change request. Do you ever decide not to add a feature because it's not worth it? It's the same with bugs. The only difference between bugs and features is commercial - 'customers' pay for features, the 'company' pays for bug fixes, or something like that. However, as with feature requests, every ...


Only top voted, non community-wiki answers of a minimum length are eligible