|
All part of the friendly service, Marc  .
Software Zen: delete this;
|
|
|
|
|
I've always seen agile programming as the-tail-wagging-the-dog.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Gary R. Wheeler wrote: My problem with Agile has always been that there's no plan - just implement whatever the customer wants this week.
That's not agile - that's chaos.
The agile shop where I work requires specs, sign-off and code reviews. Changes to requirements cause new work items to be generated for a future sprint.
/ravi
|
|
|
|
|
Perhaps I should have phrased that as "My problem with most Agile shops' process". I've read too many anecdotal accounts from folks that describe a very chaotic development environment. There's no buy-in from the marketing crowd into the process. They treat it as 'oh, that's how engineering wants to be told what to do' and leave it at that.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: There's no buy-in from the marketing crowd into the process.
Yes, that's a common problem. Management has to understand that the organization as a whole (and not just the engineering department) needs to be agile.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Management has to understand that the organization as a whole (and not just the engineering department) needs to be agile.
- Management with understanding? Oh yes, head to the science fiction shelf at the end of the corridor, please
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Maybe I've been luckier than most, but the companies (exclusively early-stage) I've worked at since 2000 have had pretty good management in place.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: exclusively early-stage
Probably that's why.
I have seen / worked (as extern) for companies starting up as well and it is quite nice. But with the time...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: Oh yes, head to the science fiction shelf at the end of the corridor, please
Bite your tongue. That's obviously in the fantasy section.
Software Zen: delete this;
|
|
|
|
|
Because ALL management are clueless jerks?
|
|
|
|
|
There should be a Dilbert strip for this one
|
|
|
|
|
Oh yes, yes. Well said.
Regards,
Rob Philpott.
|
|
|
|
|
Swallowing exceptions and copy/paste programming. They are going to cost you A LOT of time.
I have solves SO many bugs that were almost impossible to solve because no exceptions seemed to occur. You'll be looking for hours trying to find some logical flaw in the code and after hours you realize some (in-house) library swallows the exception that caused the bug... ARGH! When reading the error message the bug is often fixed in a couple of minutes.
A lot of bugs come from copy/paste programming. Either because someone forgot to change a variable name or some such or because code is changed, but not in the copied version (because no one simply knows it's there).
At a close third is probably keeping commented out code in production, it just not so dangerous since it doesn't do anything. I had a colleague who was afraid of code, but even more afraid of deleting code.
The source was littered with commented out code. When I told him to just delete it because we have source control anyway he started making weird faces and noises and I think he changed his pants afterwards...
The only thing I don't consider a bad practice in that list is not writing comments.
I prefer no comments over useless, outdated or misleading comments. I'm a programmer, I'll figure out what the code does. It's my job!
People often forget that every line of comment is just another line of code that needs to be maintained.
On top of that most programmers are just that. They aren't writers. Writing good comments is an art most programmers don't master. Comments get messy and may be harder to understand than the actual code!
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Such as when changing the code and leaving the old comments.
|
|
|
|
|
First of all... I am 95% of the time dealing with PLCs (so the comments I do might not fit into high-level world)
I partially agree that the lack of comments is not so terrible. But with the condition of: Code is done easy to understand.
Variable names: I have been fixing bugs in programms where "TaskDone" was used for "TaskActive" (but not ended), or "PlaceActive" used for "PlaceFull" or even worst just "int1", "int2", "int3" and try to understand what does each one mean.
Bad Formatting: It can be a kick in the ass to read something with bad format, but this is for me one not so critical for the understanding. It is just comfortability.
Mistery side-effects: This is one that I very often have to deal with, when I go to a customer to fix something, and it is really annoying because it is very difficult to simulate the error-trigger situation. One of my "favourite" is when same area in memory is being written from two different places at the same time and the value get mixed, triggering god knows what in other places.
Magic Numbers: Lucky me, this is something I don't find often
Leaving commented out code for long: This is something I have to deal with 90% of the times in legacy code. I hate it. Starting to get into the functionality, spending a precious time to know what it is done in a function and then find a commented out call to that function, or a return (1) or whatever else making it for the cats. I really hate it.
Copy and paste programming: ---> Search and replace for something meaningful / useful. Time wasting but... not so bad as others
Assuming default behaviour: Related to mistery side-effects. Can be really annoying / dificult to find out.
Swallowing Errors: It depends, if the programm get blocked, then I don't really care. They are easy to find. If not... 
Not checking values: In my experience, that use to end into points "Assuming default behaviour" and/or "mistery side effects"
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
My team deals with PLC code a lot, since our application is primarily process control. Our experience has been that PLC programming is done by hardware engineers, often with little or no software background. Even when the PLC development environment includes sophisticated support for input/output, communications, concurrent processing, and the like, the hardware engineer has an inherent distrust of the smart tools. They re-invent the wheel. The end result is limited, buggy, and the interfaces are painful.
Software Zen: delete this;
|
|
|
|
|
Such problems are not specially to be found in Software done by hardware ingineers. That can increase a bit the statistics, OK, but... if you saw things I have seen from people with electronics engineering (specialization in automation) degree... you would not believe it.
I had once a trainee...
Situation:
memory area with an Array for 30 data units and dynamical presentation into the human interface. When opening window or clicking in +1 or -1 just get the actual number and bring it to the edit area. When saving, geting that element and overwrite the position in the memory area.
Question of the trainee when I explained it: Why "place - 1"???
Me:    (explanation for about 15 minutes about arrays, start addresses of elements and the difference between "human" place 1 and "array" place 1)
Trainee: hmmmm, Ok (10 sec later), but would not be easy to show the element in "place" instead of "place - 1"??
Me: Ok, it doesn't matter  let's go to another thema
I don't mind to train newbies, but that one was the most defying challenge until now. Not to teach him, but not to kill him  
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
How about none of the above. And who says no code comments is a bad habit? Code should be self documenting. If you need to document your code, then you are need to think about restructuring your code!
|
|
|
|
|
|
I fully commit that - code should be self explaining and no comments are needed. Many comments are really a sign for restructuring.
But sometimes are hacks, workarounds or magic numbers needed. And that is screaming for comment.
The big exclamation is, that I write a "major change history" on top of the file. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
|
"If you can say it in code, do so. Otherwise, say it in a comment.
- Dan Saks, one-time secretary of the ANSI/ISO C/C++ standardization committee
Comments should describe your intent, not what the code is doing (or what you think it's doing). They can also correlate requirements to features, and describe interactions between components. Identify the algorithm if it's noteworthy. Comments can aid source code navigation.
Having comments in your code is not a blind indicator that refactoring is in order. The KISS rule applies here. I've seen several projects that used esoteric language features to force the compiler to process 'self-documenting' code (C++ template meta-programming comes to mind). The end result is that the intent is obfuscated by the syntax, the code itself is difficult to read and impossible to debug, not to mention the concomitant obscure compiler diagnostics.
Software Zen: delete this;
|
|
|
|
|
/ravi
|
|
|
|
|
Of course, I am not saying that you should never comment your code, and indeed I often do, but to have it on a list saying its a bad coding habit is odd. It seems to suggest that you should always comment your code, which of course is not the case.
To clarify one of my statements, I should have said, as far as possible code should be self describing, as rather than self commenting.
|
|
|
|
|
Steve Solomon wrote: Code should be self documenting.
Absolutely!
And you shouldn't need written details about driving a car, flying an aeroplane, or using microsurgery machines, either!
Anyone who can't look at 40,000 lines of code and immediately understand absolutely everything that the program does and how all elements of the program affect each other should not even be allowed near an IDE!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
