We’re rewarding the question askers & reputations are being recalculated! Read more.

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 - ...


27

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

P. Brian Mackey is right about TDD being useful - and any unit tests will improve things dramatically. As a tester, I can tell you that a thorough unit test suite dramatically decreases the number of bugs, and limits the remaining functional bugs to mostly a few predictable areas where I can focus my testing (mostly integration points / environmental ...


14

My intuition goes like this: The more people assigned to a project of given size, the bigger the communication overhead => the higher the chances of misunderstandings and all sorts of communication problems => the higher the number of resulting defects. And Good developers are rarer, thus harder to find and hire, than mediocre / bad ones => the more ...


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

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 ...


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

Maybe you want to consider this: What security privs are required to install the software? Is the installation drive independent? Does the install process test for space availability? Is the connection string to the database automatically built or statically coded and requires user change? Does your code handle dialect specific data such as date correctly? ...


8

Which door represents your code?... ...Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our ...


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 ...


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