Worse than outsourcing...
-
...is being a freelancer and forced to work with another one. My client hired another developer to help me out in the project because it's quite big and I can't work full time on it. He got some Russian guy... First I had to sermon him several times for screwing up our SVN repository (for instance he committed one feature in 5 separate commits - one for each folder/project in which he made changes :doh: ) and committing broken code. Furthermore he doesn't know how to merge source files and even asked me if he could just overwrite my version with his. I "jokingly" (not really, but just trying to be nice) suggested him that perhaps he should read the Subversion Book, to which he just replied with a smile. :doh: Then he created some problematic code[^] which we haven't settled out how to do yet. I gave up until today when he updated one of my pages and mixed the two different methods of business object handling in one source file. When I talked to him about the need to establish some sort of conventions for our own good he told me that each developer should be allowed to write any code that he wants. I understand the autonomy and support it as long as it's your code inside your methods, but not when it comes to contracts and interfaces which are used by many people. He doesn't update test data for our database and doesn't handle the scenarios where some data is missing so his JavaScript code throws exceptions and client side controls are not loaded. We are using ComponentArt Web.UI, but he uses MS AJAX controls (they throw some errors, too) even though the same functionality is provided by ComponentArt and the client asked me to use ComponentArt. He writes
try..catchblocks initializing unused Exception objects. Today I updated my working copy just to find the following code in a page I created and he edited:try
{
// lots of his code here
}
catch (Exception e)
{
throw new Exception(e.Message);
}By the way, we do have a global exception handler for unexpected errors which logs the exception and redirects the user to a generic error page. I am reluctant to inform the client of all my concerns, though I did a few times already (including today). I feel like a scumbag because I have some issues with him constantly and I tell
We have a similar situation with one of our developers. After several years of mentoring, teaching and yelling nothing has changed :D We eventually figured out that we just have to sandbox him in his own little world and make sure that he doesn't mess up the main application too much (like leaving UI debugging stuff in the main release). On the plus side he can implement some highly complex algorithms for 3D analysis that not many of the others on the team can or have time to do. I would suggest you let the Russian guy make his mistakes and let them find their way into QA and even production. That's probably your only hope of getting buy-in from your client to change the situation. Or do like we did and make him work in his own branch and have someone else take the time to merge his changes while doing a code review to catch any major malfunctions.
Todd Smith
-
I have met a couple Russians who were actually good at programming... BTW, using try catch blocks in a web application is so pointless. Just use the global asax and call your error handler...
I didn't get any requirements for the signature
ToddHileHoffer wrote:
BTW, using try catch blocks in a web application is so pointless.
:wtf: I hope you're not serious. Exception handling in a web application is as valid, as performing exception handling in a desktop application. Suppose that you have a custom exception that is thrown to indicate that a resource you're accessing is locked - your code could retry the access; at which point the resource might have been freed up. Please don't make blanket generalisations about exception handling, people may take what you say as gospel and not bother to form an opinion for themself.
Deja View - the feeling that you've seen this post before.
-
We have a similar situation with one of our developers. After several years of mentoring, teaching and yelling nothing has changed :D We eventually figured out that we just have to sandbox him in his own little world and make sure that he doesn't mess up the main application too much (like leaving UI debugging stuff in the main release). On the plus side he can implement some highly complex algorithms for 3D analysis that not many of the others on the team can or have time to do. I would suggest you let the Russian guy make his mistakes and let them find their way into QA and even production. That's probably your only hope of getting buy-in from your client to change the situation. Or do like we did and make him work in his own branch and have someone else take the time to merge his changes while doing a code review to catch any major malfunctions.
Todd Smith
Todd Smith wrote:
Or do like we did and make him work in his own branch and have someone else take the time to merge his changes while doing a code review to catch any major malfunctions.
Or fire him and find someone else to do the algorithms?
Jon Smith & Wesson: The original point and click interface
-
ToddHileHoffer wrote:
BTW, using try catch blocks in a web application is so pointless.
:wtf: I hope you're not serious. Exception handling in a web application is as valid, as performing exception handling in a desktop application. Suppose that you have a custom exception that is thrown to indicate that a resource you're accessing is locked - your code could retry the access; at which point the resource might have been freed up. Please don't make blanket generalisations about exception handling, people may take what you say as gospel and not bother to form an opinion for themself.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Please don't make blanket generalisations about exception handling
Exception handling is for girls.
-
ToddHileHoffer wrote:
BTW, using try catch blocks in a web application is so pointless.
:wtf: I hope you're not serious. Exception handling in a web application is as valid, as performing exception handling in a desktop application. Suppose that you have a custom exception that is thrown to indicate that a resource you're accessing is locked - your code could retry the access; at which point the resource might have been freed up. Please don't make blanket generalisations about exception handling, people may take what you say as gospel and not bother to form an opinion for themself.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
WTF I hope you're not serious. Exception handling in a web application is as valid, as performing exception handling in a desktop application. Suppose that you have a custom exception that is thrown to indicate that a resource you're accessing is locked - your code could retry the access; at which point the resource might have been freed up. Please don't make blanket generalisations about exception handling, people may take what you say as gospel and not bother to form an opinion for themself.
I was serious. Sure it is possible that the only way to check for a resource is to put the call in try catch blocks, but usually there is a more efficient way of doing so. I have not used try catch blocks in any of my web applications outside of the global file in about three years. I have an error handler I've been tweaking for years now. It uses reflection goodness and a whole lot more. If I get an exception it emails me the line number of the code that caused the problem the stack trace + all the session / viewstate / cookies / page info etc. If the error is a sql problem I get the sql text that caused it.
I didn't get any requirements for the signature
-
Pete O'Hanlon wrote:
WTF I hope you're not serious. Exception handling in a web application is as valid, as performing exception handling in a desktop application. Suppose that you have a custom exception that is thrown to indicate that a resource you're accessing is locked - your code could retry the access; at which point the resource might have been freed up. Please don't make blanket generalisations about exception handling, people may take what you say as gospel and not bother to form an opinion for themself.
I was serious. Sure it is possible that the only way to check for a resource is to put the call in try catch blocks, but usually there is a more efficient way of doing so. I have not used try catch blocks in any of my web applications outside of the global file in about three years. I have an error handler I've been tweaking for years now. It uses reflection goodness and a whole lot more. If I get an exception it emails me the line number of the code that caused the problem the stack trace + all the session / viewstate / cookies / page info etc. If the error is a sql problem I get the sql text that caused it.
I didn't get any requirements for the signature
ToddHileHoffer wrote:
I have not used try catch blocks in any of my web applications outside of the global file in about three years.
You can do it that way, but it doesn't make it the right way. It may work for you, but in general it's not a great way - for instance, your web application uses multiple web services and one of them has a problem. What exception do you get back? You can't use reflection here because you've got to deal with SoapExceptions and they aren't handled as normal exceptions. The best place to work with these exceptions is in the web service, not propagated back up through the call stack Similarly - if you provide a web service to external applications, what should you do if there's an exception? Let that propagate up to a client or deal with it yourself.
Deja View - the feeling that you've seen this post before.
-
Pawel Krakowiak wrote:
committing broken code
I nearly assaulted a woman who did that to MY code base :suss:
Harvey Saayman - South Africa Junior Developer .Net, C#, SQL
you.suck = (you.Passion != Programming & you.Occupation == jobTitles.Programmer)1000100 1101111 1100101 1110011 100000 1110100 1101000 1101001 1110011 100000 1101101 1100101 1100001 1101110 100000 1101001 1101101 100000 1100001 100000 1100111 1100101 1100101 1101011 111111harvey ... her name wasn't helena was it?
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
...is being a freelancer and forced to work with another one. My client hired another developer to help me out in the project because it's quite big and I can't work full time on it. He got some Russian guy... First I had to sermon him several times for screwing up our SVN repository (for instance he committed one feature in 5 separate commits - one for each folder/project in which he made changes :doh: ) and committing broken code. Furthermore he doesn't know how to merge source files and even asked me if he could just overwrite my version with his. I "jokingly" (not really, but just trying to be nice) suggested him that perhaps he should read the Subversion Book, to which he just replied with a smile. :doh: Then he created some problematic code[^] which we haven't settled out how to do yet. I gave up until today when he updated one of my pages and mixed the two different methods of business object handling in one source file. When I talked to him about the need to establish some sort of conventions for our own good he told me that each developer should be allowed to write any code that he wants. I understand the autonomy and support it as long as it's your code inside your methods, but not when it comes to contracts and interfaces which are used by many people. He doesn't update test data for our database and doesn't handle the scenarios where some data is missing so his JavaScript code throws exceptions and client side controls are not loaded. We are using ComponentArt Web.UI, but he uses MS AJAX controls (they throw some errors, too) even though the same functionality is provided by ComponentArt and the client asked me to use ComponentArt. He writes
try..catchblocks initializing unused Exception objects. Today I updated my working copy just to find the following code in a page I created and he edited:try
{
// lots of his code here
}
catch (Exception e)
{
throw new Exception(e.Message);
}By the way, we do have a global exception handler for unexpected errors which logs the exception and redirects the user to a generic error page. I am reluctant to inform the client of all my concerns, though I did a few times already (including today). I feel like a scumbag because I have some issues with him constantly and I tell
As to the outsourcing issue, I can say I have never ever met a SAS programmer that uses source archiving. I can't convince them. I work at a place where most of the programmers use SAS. I never understood why this specific population of programmers were so resistant to archiving thier code.
MrPlankton
-
Pete O'Hanlon wrote:
WTF I hope you're not serious. Exception handling in a web application is as valid, as performing exception handling in a desktop application. Suppose that you have a custom exception that is thrown to indicate that a resource you're accessing is locked - your code could retry the access; at which point the resource might have been freed up. Please don't make blanket generalisations about exception handling, people may take what you say as gospel and not bother to form an opinion for themself.
I was serious. Sure it is possible that the only way to check for a resource is to put the call in try catch blocks, but usually there is a more efficient way of doing so. I have not used try catch blocks in any of my web applications outside of the global file in about three years. I have an error handler I've been tweaking for years now. It uses reflection goodness and a whole lot more. If I get an exception it emails me the line number of the code that caused the problem the stack trace + all the session / viewstate / cookies / page info etc. If the error is a sql problem I get the sql text that caused it.
I didn't get any requirements for the signature
are you sure you understand the web properly? :omg:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
Pete O'Hanlon wrote:
WTF I hope you're not serious. Exception handling in a web application is as valid, as performing exception handling in a desktop application. Suppose that you have a custom exception that is thrown to indicate that a resource you're accessing is locked - your code could retry the access; at which point the resource might have been freed up. Please don't make blanket generalisations about exception handling, people may take what you say as gospel and not bother to form an opinion for themself.
I was serious. Sure it is possible that the only way to check for a resource is to put the call in try catch blocks, but usually there is a more efficient way of doing so. I have not used try catch blocks in any of my web applications outside of the global file in about three years. I have an error handler I've been tweaking for years now. It uses reflection goodness and a whole lot more. If I get an exception it emails me the line number of the code that caused the problem the stack trace + all the session / viewstate / cookies / page info etc. If the error is a sql problem I get the sql text that caused it.
I didn't get any requirements for the signature
ToddHileHoffer wrote:
I have an error handler I've been tweaking for years now. It uses reflection goodness and a whole lot more. If I get an exception it emails me the line number of the code that caused the problem the stack trace + all the session / viewstate / cookies / page info etc. If the error is a sql problem I get the sql text that caused it.
Could I persuade you to share this with us? :-D
-
harvey ... her name wasn't helena was it?
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
Nope, Tanya... I'm dying hear how Helena pushed your buttons :)
Harvey Saayman - South Africa Junior Developer .Net, C#, SQL
you.suck = (you.Passion != Programming & you.Occupation == jobTitles.Programmer)1000100 1101111 1100101 1110011 100000 1110100 1101000 1101001 1110011 100000 1101101 1100101 1100001 1101110 100000 1101001 1101101 100000 1100001 100000 1100111 1100101 1100101 1101011 111111 -
ToddHileHoffer wrote:
I have not used try catch blocks in any of my web applications outside of the global file in about three years.
You can do it that way, but it doesn't make it the right way. It may work for you, but in general it's not a great way - for instance, your web application uses multiple web services and one of them has a problem. What exception do you get back? You can't use reflection here because you've got to deal with SoapExceptions and they aren't handled as normal exceptions. The best place to work with these exceptions is in the web service, not propagated back up through the call stack Similarly - if you provide a web service to external applications, what should you do if there's an exception? Let that propagate up to a client or deal with it yourself.
Deja View - the feeling that you've seen this post before.
I agree! Using one catchall for errors is just lazy programming. Exceptions are designed to known expcetion at a local level where the design should know more about the condition and be able to make the call if it is a valid error and we need to abort or it is something we can handle at that level. In addition to localizing of the error block, it localizing your error reporting back to the user. Instead of throwing up some generic error message about the hampsters running off the wheels, you can actually give your users a more informative error.
Rocky <>< Recent Blog Post: Netflix Gets Starz!
-
...is being a freelancer and forced to work with another one. My client hired another developer to help me out in the project because it's quite big and I can't work full time on it. He got some Russian guy... First I had to sermon him several times for screwing up our SVN repository (for instance he committed one feature in 5 separate commits - one for each folder/project in which he made changes :doh: ) and committing broken code. Furthermore he doesn't know how to merge source files and even asked me if he could just overwrite my version with his. I "jokingly" (not really, but just trying to be nice) suggested him that perhaps he should read the Subversion Book, to which he just replied with a smile. :doh: Then he created some problematic code[^] which we haven't settled out how to do yet. I gave up until today when he updated one of my pages and mixed the two different methods of business object handling in one source file. When I talked to him about the need to establish some sort of conventions for our own good he told me that each developer should be allowed to write any code that he wants. I understand the autonomy and support it as long as it's your code inside your methods, but not when it comes to contracts and interfaces which are used by many people. He doesn't update test data for our database and doesn't handle the scenarios where some data is missing so his JavaScript code throws exceptions and client side controls are not loaded. We are using ComponentArt Web.UI, but he uses MS AJAX controls (they throw some errors, too) even though the same functionality is provided by ComponentArt and the client asked me to use ComponentArt. He writes
try..catchblocks initializing unused Exception objects. Today I updated my working copy just to find the following code in a page I created and he edited:try
{
// lots of his code here
}
catch (Exception e)
{
throw new Exception(e.Message);
}By the way, we do have a global exception handler for unexpected errors which logs the exception and redirects the user to a generic error page. I am reluctant to inform the client of all my concerns, though I did a few times already (including today). I feel like a scumbag because I have some issues with him constantly and I tell
I think you make it worst than it is. Just try to divide the work between the two of you so that you do not step over your toes all time. Maybe you do one set of pages, he does another set of pages, given that you agree on the fundamentals such as database schemas or whatever everything should work fine. Also it might help to determine who the lead developer is in case a decision needs to be taken on a topic you two disagree.
-
ToddHileHoffer wrote:
I have not used try catch blocks in any of my web applications outside of the global file in about three years.
You can do it that way, but it doesn't make it the right way. It may work for you, but in general it's not a great way - for instance, your web application uses multiple web services and one of them has a problem. What exception do you get back? You can't use reflection here because you've got to deal with SoapExceptions and they aren't handled as normal exceptions. The best place to work with these exceptions is in the web service, not propagated back up through the call stack Similarly - if you provide a web service to external applications, what should you do if there's an exception? Let that propagate up to a client or deal with it yourself.
Deja View - the feeling that you've seen this post before.
The web services I write use the same error handler in a global file. If an error occurs I get all the info about the service. The ones I have written for outside vendors have never thrown an exception. They aren't that complex. If I was calling an outside vendors web service, I might use try catch blocks...
I didn't get any requirements for the signature
-
I agree! Using one catchall for errors is just lazy programming. Exceptions are designed to known expcetion at a local level where the design should know more about the condition and be able to make the call if it is a valid error and we need to abort or it is something we can handle at that level. In addition to localizing of the error block, it localizing your error reporting back to the user. Instead of throwing up some generic error message about the hampsters running off the wheels, you can actually give your users a more informative error.
Rocky <>< Recent Blog Post: Netflix Gets Starz!
If there is a certain type of exception that you can trap and continue with the code than sure it makes sense to write try catch blocks. I have never come across that situation. Every time my code has thrown an error, it is a bug that needs to be fixed. It isn't about laziness either. Having a global error handler makes sure that all the bugs are accounted for and logged in the same place. I have worked in Environments where ever program had custom error handling and exceptions were just killed in try catch blocks and nothing was ever done with them. Using my global error handler, if an error occurs in a .net web page, I'll get an email with the line of code that caused the error. That's not laziness, it is good design and it makes life easy. Granted I have only worked in small corporations with < 1000 users. I'm not writing code for Amazon.com.
-
Pete O'Hanlon wrote:
Please don't make blanket generalisations about exception handling
Exception handling is for girls.
-
ToddHileHoffer wrote:
I have an error handler I've been tweaking for years now. It uses reflection goodness and a whole lot more. If I get an exception it emails me the line number of the code that caused the problem the stack trace + all the session / viewstate / cookies / page info etc. If the error is a sql problem I get the sql text that caused it.
Could I persuade you to share this with us? :-D
I didn't write all of this, it has been around for years. Also, I leave the debug set to true in the web.config. It is a performance hit, but that's not an issue in my environment. Our server is fast and we don't have that many users. using System; using System.Collections.Generic; using System.Text; using System.Net.Mail; using System.Web; using System.Collections.Specialized; using System.Configuration; using System.Collections; using System.Reflection; public class ErrorHandler { #region Declarations const String heading = @"
"; const String td = @""; private HttpApplication application = null; private Exception exception = null; private string messageBody = string.Empty; private MailPriority mailPriority = MailPriority.Normal; private string subject = "Application Error"; private bool isWebApp = false; #endregion #region Configuration //********************************** // You must have the following in the web.config or ap.config // "autoDebugTo" // "autoDebugFrom" // "smtpHost" //********************************** private List toEmail { get { List objReturn = new List(); if (ConfigurationManager.AppSettings["autoDebugTo"].ToString().Contains(";")) { foreach (string x in ConfigurationManager.AppSettings["autoDebugTo"].ToString().Split(";".ToCharArray())) objReturn.Add(new MailAddress(x)); } else objReturn.Add(new MailAddress(ConfigurationManager.AppSettings["autoDebugTo"].ToString())); return objReturn; } } private MailAddress fromEmail { get { return new MailAddress(ConfigurationManager.AppSettings["autoDebugFrom"].ToString()); } } private string smtpHost { get { return ConfigurationManager.AppSettings["smtpHost"].ToString(); } } #endregion #region cTor public ErrorHandler(Exce
-
are you sure you understand the web properly? :omg:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
Of course I understand it. It's just that I don't work for an IT company. Web Services don't play a role in most of the Intranet applications I work on.
I didn't get any requirements for the signature
-
Of course I understand it. It's just that I don't work for an IT company. Web Services don't play a role in most of the Intranet applications I work on.
I didn't get any requirements for the signature
so then would you say that making blanket statements about "the web" and what is and isn't a good idea for web programming might not be your forte? i mean given that you say you're not working in a "web" environment as such just curious as your advice is just plain misguided for the web at large :|
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
Pete O'Hanlon wrote:
Please don't make blanket generalisations about exception handling
Exception handling is for girls.
god doesn't use
try {
......
} catch (e){
...
}he uses
try {
.....
} chuck (norris){
...
}and it gets handled :rolleyes:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"