Today in the news: Why Builds Fail
-
Simon O'Riordan from UK wrote:
it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity.
I know, I laughed when I read that too, especially the "extra brainpower." We can't be contributing to global warming now, can we? Or heaven forbid, we ask our programmers to actually think There's a lot of times when I make a major change to an interface and rather than figure out all the dependent classes I need to touch, I just I hit the compile button and let VS tell me where the fixes need to occur (of course, if I used something like Resharper, it probably could fix them for me, but I don't, so I have no idea.) Anyways, the point is, I use the compiler as _a tool to facilitate in productivity. Marc
Latest Articles - APOD Scraper and Hunt the Wumpus Short video on Membrane Computing Hunt the Wumpus (A HOPE video)
_
Now we know why the ice caps are melting! :laugh:
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
Would that be a spare time-machine or a spare-time machine. Because I think the latter would be much better.
Now I want a spare-rib machine... :cool:
You'll never get very far if all you do is follow instructions.
-
This absolute gem, quote: "When builds fail, due to compilation errors, it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity." Yes. Waiting for the computer to boot, that too. And sleeping for 7 hours at night. And eating, and going to the coffee machine. All these things. Did I mention design? Coding? These two REALLY use up that there productivity. :laugh:
In related news, I understand that broken cars are really affecting the productivity of mechanics. And doctors are complaining that sick people are affecting their productivity.
-
This absolute gem, quote: "When builds fail, due to compilation errors, it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity." Yes. Waiting for the computer to boot, that too. And sleeping for 7 hours at night. And eating, and going to the coffee machine. All these things. Did I mention design? Coding? These two REALLY use up that there productivity. :laugh:
As one of my college lecturers once said, code like you're stuck in the 1940's. In other words desk check it til the cows come home and ONLY then you compile. Treat the computer like it's a time share where you have to book several weeks in advance to get any run time to compile your program. A little extra time during the design cycle works wonders for bug count (compile and logic bugs), amongst other things, such as code that will run until the cows come home like in financial institutions that have been running the same code on the same machines for 40 years or more. HUZZAH for stability.
-
As one of my college lecturers once said, code like you're stuck in the 1940's. In other words desk check it til the cows come home and ONLY then you compile. Treat the computer like it's a time share where you have to book several weeks in advance to get any run time to compile your program. A little extra time during the design cycle works wonders for bug count (compile and logic bugs), amongst other things, such as code that will run until the cows come home like in financial institutions that have been running the same code on the same machines for 40 years or more. HUZZAH for stability.
Oddly enough, what you say is borne out by courses such as CMU's self-management course for softies. A detailed code walkthrough spots most errors before they get to the compiler. However, the bugs that really slow you down are nothing to do with the compiler; testing bugs(inappropriate behaviour found in testing) occupy five times the span of compiler bugs, and if you want to get your LOC/Bug ratio down to acceptable levels, it is the testing bugs you should be aiming to get down. :suss: And this is mostly about design.(If I remember right):suss:
-
Oddly enough, what you say is borne out by courses such as CMU's self-management course for softies. A detailed code walkthrough spots most errors before they get to the compiler. However, the bugs that really slow you down are nothing to do with the compiler; testing bugs(inappropriate behaviour found in testing) occupy five times the span of compiler bugs, and if you want to get your LOC/Bug ratio down to acceptable levels, it is the testing bugs you should be aiming to get down. :suss: And this is mostly about design.(If I remember right):suss:
Simon O'Riordan from UK wrote:
And this is mostly about design.(If I remember right)
Yup, and as I said, careful design will squish a lot of logic bugs as well. The bugs I find hardest to track down are what I refer to as 'incidental bugs'. Bugs that are normally not there but pop up from time to time when a user does something specific. In my experience when I am trouble shooting code the user who is reporting the bug really doesn't know how to describe what they were doing when it happened. Very frustrating.
-
Don't forget testing. That destroys productivity!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
It all went wrong when clipboards were replaced with iPads.
I may not last forever but the mess I leave behind certainly will.
-
This absolute gem, quote: "When builds fail, due to compilation errors, it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity." Yes. Waiting for the computer to boot, that too. And sleeping for 7 hours at night. And eating, and going to the coffee machine. All these things. Did I mention design? Coding? These two REALLY use up that there productivity. :laugh:
I agree, this is a gem! BTW, this came from CIO.com, shouldn't have CIO's already have got over such bullshit quotes? http://www.cio.com/article/754704/Why_Software_Builds_Fail[^]
-
When builds fail, that's just 'cause I'm letting the machine do the work for me. Not like in the stone ages where you had to "desk check" your code (punch cards) before turning it over to the operator. Back then, a compiler error was a *BIG* waste of time. The time spent desk checking was well worth it. Today, who cares? Let the machine figure out where the errors are.
If you can't be arsed to even try and write the code correctly in the first place, I can't believe that when it does compile cleanly it will do anything reasonable.
Software Zen:
delete this; -
If you can't be arsed to even try and write the code correctly in the first place, I can't believe that when it does compile cleanly it will do anything reasonable.
Software Zen:
delete this;I try to write the code correctly. But I'm certainly not going to waste my time "desk checking" for semi-colons, and other nonsense. The compiler will tell me the details, while I work on writing code that does what it's supposed to do. Besides, I'm an old fart and I'm allowed to be lazy.
-
I try to write the code correctly. But I'm certainly not going to waste my time "desk checking" for semi-colons, and other nonsense. The compiler will tell me the details, while I work on writing code that does what it's supposed to do. Besides, I'm an old fart and I'm allowed to be lazy.
My point is that the devil is in the details:
if (condition1 | condition2);
{
Action5(0,Beta);
}See the problem?
Software Zen:
delete this; -
My point is that the devil is in the details:
if (condition1 | condition2);
{
Action5(0,Beta);
}See the problem?
Software Zen:
delete this;Well of course, you cleverly crafted a logic error disguised as a "compiler error". Hell, I make many stupid mistakes, many are much worse than your example. But all in all, I try to write my code as carefully as possible. However, I have no objection to letting the compiler catch the nasties. I'm certainly not going to exert myself "desk checking" like I used to do with punch cards and paper tape. After all, the compiler spits out the results in a matter of seconds as opposed to getting my printout 45 minute later.
-
Simon O'Riordan from UK wrote:
it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity.
I know, I laughed when I read that too, especially the "extra brainpower." We can't be contributing to global warming now, can we? Or heaven forbid, we ask our programmers to actually think There's a lot of times when I make a major change to an interface and rather than figure out all the dependent classes I need to touch, I just I hit the compile button and let VS tell me where the fixes need to occur (of course, if I used something like Resharper, it probably could fix them for me, but I don't, so I have no idea.) Anyways, the point is, I use the compiler as _a tool to facilitate in productivity. Marc
Latest Articles - APOD Scraper and Hunt the Wumpus Short video on Membrane Computing Hunt the Wumpus (A HOPE video)
_
Marc Clifton wrote:
I just I hit the compile button and let VS tell me where the fixes need to occur
I do exactly the same. I find this very useful while refactoring. I change variable types and names and don't let visual studio rename them so I can re-check every compile error if anything else needs to be changed.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
This absolute gem, quote: "When builds fail, due to compilation errors, it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity." Yes. Waiting for the computer to boot, that too. And sleeping for 7 hours at night. And eating, and going to the coffee machine. All these things. Did I mention design? Coding? These two REALLY use up that there productivity. :laugh:
I wonder how long it will take for someone to produce a study that finds "sawing reduces carpenters' productivity!". What concerns me more though, is the notion that compiler errors are a bad thing: Me, I *want* the compile to fail as often as possible, rather than have the program fail at runtime! I specifically design my code to fail at compile time if anyone uses it in an unintended way! Also, when I write such code, I do test that the compiler really issues an error. I consider that a build success though, not a build failure! Besides, I often use templates and other complex code constructs, and sometimes it simply takes less time to just do a quick compile rather than brood over the code for hours and wonder whether the syntax is actually fine. My brain isn't hard-wired to do syntax checks - so why shouldn't I use the compiler for that purpose? Also I often try to eliminate #includes that I believe are no longer necessary (specifically in header files). Considering the convoluted mess of system include files, there is no way to find out without running the compiler! Conclusion: Compiler errors are a good thing! They're easy to fix, and safe me a lot of effort on code inspection. Anyone who builds compilers with the goal to reduce compiler errors has missed the point entirely! Compilers should be built to point out as many errors as possible. That's why we have strongly typed languages after all!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I wonder how long it will take for someone to produce a study that finds "sawing reduces carpenters' productivity!". What concerns me more though, is the notion that compiler errors are a bad thing: Me, I *want* the compile to fail as often as possible, rather than have the program fail at runtime! I specifically design my code to fail at compile time if anyone uses it in an unintended way! Also, when I write such code, I do test that the compiler really issues an error. I consider that a build success though, not a build failure! Besides, I often use templates and other complex code constructs, and sometimes it simply takes less time to just do a quick compile rather than brood over the code for hours and wonder whether the syntax is actually fine. My brain isn't hard-wired to do syntax checks - so why shouldn't I use the compiler for that purpose? Also I often try to eliminate #includes that I believe are no longer necessary (specifically in header files). Considering the convoluted mess of system include files, there is no way to find out without running the compiler! Conclusion: Compiler errors are a good thing! They're easy to fix, and safe me a lot of effort on code inspection. Anyone who builds compilers with the goal to reduce compiler errors has missed the point entirely! Compilers should be built to point out as many errors as possible. That's why we have strongly typed languages after all!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Hear hear. Not to mention meta-programming. Who could remember all those rules perfectly?
-
My point is that the devil is in the details:
if (condition1 | condition2);
{
Action5(0,Beta);
}See the problem?
Software Zen:
delete this;I totally agree with Abu Mami. These kind of errors are best detected by testing and debugging. If you're prone to such simple errors, then it's likely that you won't easily spot it in static analysis either. Testing is much more effective at that!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Ah but the former is only a spare one, so it's not getting much use.
If it's spare, can I have it? :-D
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I totally agree with Abu Mami. These kind of errors are best detected by testing and debugging. If you're prone to such simple errors, then it's likely that you won't easily spot it in static analysis either. Testing is much more effective at that!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Letting the compiler catch syntactical errors while you 'worry about the big picture' isn't testing. It's laziness and a recipe for disaster. Competent software requires attention to detail. Incompetent software doesn't have it.
Software Zen:
delete this; -
Letting the compiler catch syntactical errors while you 'worry about the big picture' isn't testing. It's laziness and a recipe for disaster. Competent software requires attention to detail. Incompetent software doesn't have it.
Software Zen:
delete this;I never said I only worry about the big picture. I don't. I did say that I spend (some of) the time I save by not brooding over code for debugging and testing. Maybe I should have been more clear: what I'm talking about is contemplating the effect of each statement on the variables, then running a test and verifying each indivdual step to confirm that the changes occur in exactly the way I expect. That still takes a lot of time, but nevertheless, it is orders of magnitude faster than emulating the computer in your head while brooding over some piece of code! Static analyisis is what tools do. Real programmers debug!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
