|
That was my take also, but you beat me to it!
As I grow older I've found that pleasing everyone is impossible but pissing everyone off is a piece of cake.
|
|
|
|
|
Beat me to it - those were my thoughts as well.
Any decent IDE can easily deal with comments, formatting, etc. It's the other problems that are more important, especially not checking parameters. My last major project had huge issues with people not checking return values or performing even simple testing.
|
|
|
|
|
...is forcing programmers to maintain old or foreign code. Should be punishable by doubled salary. 
regards,
Kate
|
|
|
|
|
Looks like you want to punish managers, forcing programmers to maintain old or foreign code, by doubled salary.
|
|
|
|
|
Is it really punishment though? I choose to see it as a fair compensation. Foreign code maintenance (scavenging really) should probably also include one more week of vacation to calm the nerves. I'm glad, that I'm usually on the opposite side doing adoption of cutting edge technologies. But once in a while... 
|
|
|
|
|
Agreed - I was interviewing with one company who was looking for MFC developers. When they ask for something well past its sell-by date like MFC, I always give them a highly inflated number.
It amazes me how many companies want people to work on old legacy crap without a premium. Then they wonder why there's a 'shortage of engineers'.
|
|
|
|
|
While I imagine there are teams that have implemented agile well, in my experience witnessing and having to work with the resulting code, agile/refactoring is essentially the worst because it inherently incorporates all of these problems and represents, in my opinion, the worst of "programming habits."
Marc
|
|
|
|
|
My problem with Agile has always been that there's no plan - just implement whatever the customer wants this week. You're always chasing a moving target. Don't worry about future requirements, just make them happy today. If the product is of any size, the end result is a hacked-together, incoherent mess.
The products I've worked on for the last 15 years or so are multi-year efforts by a team of five to twelve people. If we didn't have a fairly good outline of what we were going to implement, we'd never have finished anything. We've become good enough at it that the 'process' is second nature. Based on requirements, we outline component behaviors and specify interfaces in detail. Ironically, we refactor fairly often as requirements change, especially during product maintenance. We even do 'scrum' to a certain extent, since we build and test almost continuously.
I've been in this trade for over 30 years. Every time I turn around there's a magic bullet being touted to management that will turn software development into a nice box with a crank on the side. Turn the crank, and out comes beautiful, money-making product. Regardless of how many times we tell them, the box continues to produce sh*t.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: My problem with Agile has always been that there's no plan - just implement whatever the customer wants this week. You're always chasing a moving target. Don't worry about future requirements, just make them happy today. If the product is of any size, the end result is a hacked-together, incoherent mess.
And that is precisely what I've witnessed. Thank you for stating it so concisely!
Marc
|
|
|
|
|
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;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
