|
It all went wrong when clipboards were replaced with iPads.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
I see nothing wrong in the quoted statement. Transfer that to the mechanical world, and it not only costs time, but also a lot material and testing equipment. Design by trial and error is the wrong way to go.
If I recruit senior Programmers, I expect better productivity, eg more qualitative code in less time.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
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;
|
|
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
|
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;
|
|
|
|
|
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)
|
|
|
|
|
The biggest problem which causes lower productivity is the programmer himself.
For example when he or she is reading articles or /and The Lounge 
I wonder how they missed that.
How unprofessional of them.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
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
|
|
|
|
|
I use the compiler in the same way when I change something that is not local to the function. The real productivity killers are the things that the compiler doesn't catch. Those that create exceptions later on (or even worse, silently fail and lead to incorrect results).
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Now we know why the ice caps are melting! 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
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
|
|
|
|
|
Quote: extra time and brainpower
Luckily, I have a bucket of extra brainpower just over here by my spare time machine.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Would that be a spare time-machine or a spare-time machine. Because I think the latter would be much better.
|
|
|
|
|
If you had the former then you would also have plenty of the latter.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Ah but the former is only a spare one, so it's not getting much use.
|
|
|
|
|
If it's spare, can I have it? 
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)
|
|
|
|
|
Now I want a spare-rib machine... 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
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.
|
|
|
|
|
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.
And this is mostly about design.(If I remember right)
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
