|
You prepare a presentation for you boss detailing all the problems this current design has, suggest improvements and a rewrite of the application and if this doesn't get through to him, I'd leave the company.
No sense wasting your time following up on bad designs and practices.
Cheers,
Mircea
"Pay people peanuts and you get monkeys" - David Ogilvy
|
|
|
|
|
Buy meself a big bottle of booze...
"I love deadlines. I like the whooshing sound they make as they fly by." (DNA)
|
|
|
|
|
i'd get used to the fact that a lot of production code looks just like this. at the heart of many long-lived applications is a bad idea wrapped in layer after layer of haste.
|
|
|
|
|
Chris Losinger wrote: at the heart of many long-lived applications is a bad idea wrapped in layer after layer of haste.
This is definitely sig material. 
/ravi
|
|
|
|
|
Do what you're told to do, and ony after you think you COMPLETELY understand the code, make recommendations to address the issues, including providing time and cost estimates for not only the coding but implications regarding regression testing, code review, beta testing, and finally re-packaging and distributing the update top your customers.
If you don't want to do ALL of that, do only what you were told and keep your trap shut.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: If you don't want to do ALL of that, do your work and keep your trap shut.
I would agree with Johns advice except the last line. This is the last thing you want to do. If you don't tell anybody about the problem, guess who will get the blame when it all goes wrong. At the very least, I would make sure your management are aware of the existing issues, the difficultly in making code changes with out breaking anything, and the extra time it will take to understand the code and make the changes safely.
Simon
|
|
|
|
|
Simon Stevens wrote: I would agree with Johns advice except the last line. This is the last thing you want to do. If you don't tell anybody about the problem, guess who will get the blame when it all goes wrong. At the very least, I would make sure your management are aware of the existing issues, the difficultly in making code changes with out breaking anything, and the extra time it will take to understand the code and make the changes safely.
My experience has been that the dev team lead already knows about it, and they're waiting for a chance to re-factor the code. The absolute best he can do, is make sure HIS code doesn't need to be re-factored along with all the rest of it.
He also has to be careful about how he approaches his boss (and co-workers) about it because his boss/co-workers may very well have written the code to begin with.
I think my advice is still sound - do what you're told and keep your trap shut - especially if you're a junior member of the team.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
On further consideration, I do see the advantage of John's suggestion, especially if he is a junior developer.
It very much depends on the situation you are in, what your management are like, etc. Like John says, you wouldn't want to upset the people who wrote the code (well, you might want to, but probably not if they are your superiors  ).
Maybe a mixture of both is the best. Let people know of your concerns, but without going over the top about it.
Simon
|
|
|
|
|
If you simply must risk your position (and respect) among your peers, I would choose my words carefully. Of course, it's better to merely be thought a fool rather than to put your foot squarely in your mouth and prove it outright.
In this situation, we're talking about a junior programmer working on a 400,000 line program with no knowledge of the requirements or reasons the code is in its current state. The wise tack is to STFU and do the work he has been assigned and NOTHING MORE.
Only after he has proven his capabilities as a decent programmer and demonstrated a thorough understanding of the existing code base should he expect anyone to give a rat's ass about his view of the code.
That's the way it is in a dev shop, and that's his role in said shop.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Simon Stevens wrote: I would agree with Johns advice except the last line. This is the last thing you want to do. If you don't tell anybody about the problem, guess who will get the blame when it all goes wrong.
I concur. When things suddenly go wrong, all management wants to know is who last touched the code. And when they come to you, they do not want to see a bunch of code diffs showing that you only changed this-and-that, but not the stuff that caused the crash.
Better to say something - even if you get yelled at, or worse, ignored(!), you should have some kind of proof that you tried to raise concerns (email trails, etc.) So when things go wrong, you can take somewhat of an NMFP approach because you TRIED to tell them.
At least, that is what I would do. (People never really did like me for my social skills and tact, however... )
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Since I've got almost 30 years of development time behind me, I feel qualified to call the kettle black (if it is indeed black). However, our friend here probably has less than two-three years of real programming experience, and he should just STFU and do his job.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: However, our friend here probably has less than two-three years of real programming experience, and he should just STFU and do his job.
Good point. I was speaking in more general terms to my contemporaries, but did not make it clear that my approach works for all developers out there.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Maaaaaaaaan, you're scary! I'm just feeling that any moment you'll come and smack me 
The code is working and probably it's never going to be re factored. I know what I have to do but, I just had to tell somebody what's in here
|
|
|
|
|
razvan_dme wrote: I'm just feeling that any moment you'll come and smack me
It's probably a good thing that you fear me from the outset.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying."
- David Ogilvy
|
|
|
|
|
John Simmons / outlaw programmer wrote: Do what you're told to do, and ony after you think you COMPLETELY understand the code, make recommendations to address the issues, including providing time and cost estimates for not only the coding but implications regarding regression testing, code review, beta testing, and finally re-packaging and distributing the update top your customers.
If you don't want to do ALL of that, do only what you were told and keep your trap shut.
If application is allready fielded then I absolutely disagree!
Project Management should be informed immediatly! Especially if personnelly identifiable information is involved in application. This can cause a whole host of privacy, security issues that can get your management and your self into big problems. Especially in US where there are a bunch of IT/ and privacy laws.
-----
display screen
SQL Error:
Data insert error, username=Bob Smith ss#342-3434-3234 in table xyz of schema=xyz
failed insert
and such....
MrPlankton
|
|
|
|
|
WTF are you talking about?
This is a matter of coding technique - NOT a discovered flaw in the program. A junior programmer would be out of place recommending sweeping changes based on the relatively minute amount of code he's seen, especially to a program he doesn't fully understand. He was told to make a change. That's all he should do. They didn't ask him to evaluate the existing code for style or technique.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
No sir.
He needs to inform his project management of his observation of lack of error handling. He needs to keep a record that he informed management (or his supervisor). He can then move forward with work as directed. He needs to be polite and circumspect, but he needs to protect himself.
You can call it technique or what ever you want but at the end of the day if application fails and privacy information is disclosed there will be big costs, big penalties.
[modified...added....]
PS
I guess what really disturbes me and gets me hot about this issue, is no error handeling also implies no real testing outside of annecdotal testing "just get it work in this one case".
MrPlankton
modified on Monday, April 7, 2008 10:52 AM
|
|
|
|
|
MrPlankton wrote: but at the end of the day if application fails
That's just it - the program hasn't failed, and he hasn't identified a point of failure. He's merely trying to demonstrate his that he thinks he knows his sh*t. He just might, but he has ZERO street cred regarding the code he's working on.
And BTW, exception handling ain't the end-all-be-all of error handling. We've been handling errors for a lot longer than most of the users on this board have been alive. Besides, the original code may have been developed before exception handling was the latest industry darling, and the company in question simply doesn't want to spend the money/time to make sweeping changes.
Again, he should STFU and do his job.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: And BTW, exception handling ain't the end-all-be-all of error handling. We've been handling errors for a lot longer than most of the users on this board have been alive. Besides, the original code may have been developed before exception handling was the latest industry darling, and the company in question simply doesn't want to spend the money/time to make sweeping changes.
I understand and agree with point, but now reporting privacy information disclosures is now a hot topic and industry darling as well... government regulator darling I should say.
MrPlankton
|
|
|
|
|
You're going off on something that isn't even part of the original question or even hinted at by the OP. He's talking about *programming techniques* - plain and simple.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
razvan_dme said...
...there is no exception handling in a 400 000 lines of code application...
John Simmons / outlaw programmer wrote: *programming techniques* - plain and simple.
It's more than that it's about security. Try/Catch has been around since c++, I can't think of a single reason not to use it. An error handeling methodology is imperative for any application especially in today's environment. Especially when private data is concened.
In addition unit tests should be part of any application to test exception conditions to make sure exception handeling is working as it should and side effects are minimized when code is changed.
MrPlankton
|
|
|
|
|
razvan_dme wrote: What would you do ... After getting a project where you have to do some improvements and add some new functionalities and you realize there is no exception handling in a 400 000 lines of code application [...]
I would be happy that I am working with MFC again!
A 400K line application with no exception handling sounds like the typical inept-developer-written CString-misusing MFC application. Even though CStrings can throw exceptions at even the most simplest operation, almost nobody ever wraps them in try/catch blocks.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: A 400K line application with no exception handling sounds like the typical inept-developer-written CString-misusing MFC application. Even though CStrings can throw exceptions at even the most simplest operation, almost nobody ever wraps them in try/catch blocks.
At my last job, our flagship product was a 750,000 line MFC program with almost no exception handling. It was reliable, robust, and easily extensible. I don't recall having to fix more than a dozen bugs in the two years we worked on it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
So - it never actually had any problems to deal with, right?
Seriously, this is an interesting thing I see every now and then - IMHO, you cannot really call a product "robust" just because it runs 24x7 in its normal, stable, everyday operating environment and conditions. That kind of application just "works."
A product is robust when it runs 24/7 and correctly handles things like one of its cluster nodes failing, database disconnects, memory errors, disk errors, network problems, power failures, etc.
Most apps I use cannot handle even the simple failure scenarios that can be introduced by the Application Verifier. They may run all day on my system for months at a time, but to call them robust just because they work diminishes really robust applications out there. (Kinda like how calling an HTML writer a Web Developer diminishes software developers  .)
Example:
Notepad works. SQL Server is robust. Notepad does not recover work you were in the middle of if you kill it using Task Manager. SQL Server does.
Granted, I do not personally know the application you speak of, so this may not apply...
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
