I was currently working on some error handling code for one of my side projects when I came across this problem. I have objects stored in a database, which of course has a field Id for its primary key. However, when the user goes to create this object, the Id field has no value until it gets saved to the database, as which point the database engine gives it an Id. The object in my code includes a member for the Id field of type int? (which is a nullable int, it can have a value of null). The function I use to get the object from the database is defined as such
public Object GetObjectFromDatabase(int? ObjectId) { }.
Inside this method, if the value of ObjectId was null then I would return null as the object.
if (ObjectId.HasValue)
{
// Get and Return the object
}
else
{
return null;
}
Adding in my error code, I thought about that behavior and decided that if I was going to the database to get an object, I would need to know its Id, so I decided that passing in a null would be considered an error. So I changed that else statement to read
else
{
throw CustomizedError;
}
I still wanted the function to accept a nullable int to avoid checking if there was a value for Id and then convert it to a regular int for every place I call GetObjectFromDatabase. I have other functions that take in similar parameters, including updating the object, deleting the object, and other various things that can be done with the object, After some debate with myself, I changed those functions to only accept a regular int instead of a int? for three reasons.
1) Programmers can only make mistakes when the code allows them to. This is why we have private variables and enforced type checking. In languages like Javascript, bugs arise when strings get treated like numbers and vice versa. Javascript doesn't force the programmer to choose a type for thier variable and stick with it. It's just var Name; Take the following code
var Two = 2;
var Three = "3";
alert(Two + Three);
The pop up you get will display "23". This would be a bug if the developer wanted 5. It's a simple mistake, but it happens because it was allowed to happen. If you tried that in C#, you wouldn't be able to compile. If I don't want programers to pass a null into this functions, I just need to not let them at all.
2) Bugs make it through testing all the time. I or someone else will eventually make the mistake of passing a null into that function, and, if I had testing for my project, since it would be a special case there is a good chance it would make it through testing.
3) It is always better not to have to throw errors. Even if it means more code to write. Sometimes having to write more code means you have to think through what you are doing. Also, bug-free code is sort of the goal and writing code that actually prevents bugs before it even compiles is preferable.
Monday, September 22, 2014
Wednesday, September 17, 2014
Book Finished: Mythical Man-Month
I just finished reading Mythical Man-Month by Frederick Brookes. It was pretty good, although a bit dry at times. It is a bit dated too although the 20th Anniversary Edition tries to updates the old material with a new chapter that includes discussions with others on the original material. Some of the points I took away from the book that I think are still applicable today for software projects are:
- Adding people late in a project makes it late, or makes it later if it is already behind schedule. There is an initial overhead cost of training and the new worker to find their way and become familiar with the project before they can fully contribute to the project. If you need more people, add them sooner than later to mitigate that cost.
- The system architects and designers should stick to only architecture and designing and the coders should only stick to coding, that may you have a separation between design and implementation, otherwise implementation may influence or change the design to fit the implementation, which may cause problems with what is intended or if a decision is made to change platforms.
- There should be as few designers and architects as possible, or at least as few people making decisions as possible, in order to preserve conceptual integrity and uniformity.
- Communication is the hardest part about working on a team. The effort to communication and coordinate grows exponentially as the team grows in size. This means that doubling the work force will not double the productivity because the effort of communicate will more than double.
- As much documentation as possible should be completed before any other work starts on a project. Writing documentation forces you to make decisions and ask questions you would otherwise put off or not know you had to make or ask. It is easier to implement things from the start rather than add them in later.
- Despite the above point, the only real constant in a project is change, and so one must plan for changes to occur, not just in specifications in the project, but also for changes in the organization or the team performing the work.
- Milestones need to have a clear and precise definition, otherwise confusion about progress may arise. If the definition is precise you cannot lie to yourself about progress and a person receiving a progress report will have close to the same understand of the progress as the person giving the progress report.
I've seen this book on a few required reading lists that some software developers have up on various blogs and website. I think it is worth a read as long as you pick up the 20th anniv. edition so you can understand what may or may not be still be applicable.
- Adding people late in a project makes it late, or makes it later if it is already behind schedule. There is an initial overhead cost of training and the new worker to find their way and become familiar with the project before they can fully contribute to the project. If you need more people, add them sooner than later to mitigate that cost.
- The system architects and designers should stick to only architecture and designing and the coders should only stick to coding, that may you have a separation between design and implementation, otherwise implementation may influence or change the design to fit the implementation, which may cause problems with what is intended or if a decision is made to change platforms.
- There should be as few designers and architects as possible, or at least as few people making decisions as possible, in order to preserve conceptual integrity and uniformity.
- Communication is the hardest part about working on a team. The effort to communication and coordinate grows exponentially as the team grows in size. This means that doubling the work force will not double the productivity because the effort of communicate will more than double.
- As much documentation as possible should be completed before any other work starts on a project. Writing documentation forces you to make decisions and ask questions you would otherwise put off or not know you had to make or ask. It is easier to implement things from the start rather than add them in later.
- Despite the above point, the only real constant in a project is change, and so one must plan for changes to occur, not just in specifications in the project, but also for changes in the organization or the team performing the work.
- Milestones need to have a clear and precise definition, otherwise confusion about progress may arise. If the definition is precise you cannot lie to yourself about progress and a person receiving a progress report will have close to the same understand of the progress as the person giving the progress report.
I've seen this book on a few required reading lists that some software developers have up on various blogs and website. I think it is worth a read as long as you pick up the 20th anniv. edition so you can understand what may or may not be still be applicable.
Thursday, September 11, 2014
Double Post To Start Off Renewed Blogging Attempt
I'm doing two posts today in my renewed effort to blog. Don't expect this pace from me though. in fact, keep your expectations low.
Today I'm pointing out that clever code is not a good thing. You should code in a way that even non coders understand what you are trying to achieve (if you are using a high level language that is, if you are using a low lever language, then go ahead and ignore this advice, nobody will be able to understand anything you could write without a great deal of effort no matter what). A quote by Brian Kernighan is "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
So you should write code like this:
public string GetMonthAbbreviation(int MonthId)
{
switch (MonthId)
{
case 1:
return "JAN";
break;
case 2:
return "FEB";
break;
case 3:
return "MAR";
break;
case 4:
return "APR":
break;
default:
return "N/A";
break;
' }
}
And NOT like this:
private Dictionary<string, string> Monthlist;
public Constructor()
{
Monthlist = new Dictionary<string, string.>;
MonthList.Add("1", "JAN");
MonthList.Add("2", "FEB");
MonthList.Add("3", "MAR");
MonthList.Add("4", "APR");
}
public string GetMonthAbbreviation(string MonthId)
{
return (MonthId != null && MonthList.ContainsKey(MonthID)) ? MonthList[MonthId] : "N/A";
}
Which seems easier to understand?
Today I'm pointing out that clever code is not a good thing. You should code in a way that even non coders understand what you are trying to achieve (if you are using a high level language that is, if you are using a low lever language, then go ahead and ignore this advice, nobody will be able to understand anything you could write without a great deal of effort no matter what). A quote by Brian Kernighan is "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
So you should write code like this:
public string GetMonthAbbreviation(int MonthId)
{
switch (MonthId)
{
case 1:
return "JAN";
break;
case 2:
return "FEB";
break;
case 3:
return "MAR";
break;
case 4:
return "APR":
break;
default:
return "N/A";
break;
' }
}
And NOT like this:
private Dictionary<string, string> Monthlist;
public Constructor()
{
Monthlist = new Dictionary<string, string.>;
MonthList.Add("1", "JAN");
MonthList.Add("2", "FEB");
MonthList.Add("3", "MAR");
MonthList.Add("4", "APR");
}
public string GetMonthAbbreviation(string MonthId)
{
return (MonthId != null && MonthList.ContainsKey(MonthID)) ? MonthList[MonthId] : "N/A";
}
Which seems easier to understand?
Changing things up
I'm changing the way my blog works. Instead of posting only longer articles that are checked for spelling and grammar and then revised to sound better, I've decided to do much shorter posts. I'll still do the longer pieces, and there will be a post about them with a link as well as links to them on the site, but I want be more active with this. Attempting to write articles that equated to a school essay or paper doesn't seem to be working well for me, so I'm trying something different. Short posts for the most part, longer articles as pages on the site which will be accompanied by a blog post with a link to it, and I'm going to set up my google drive to host my custom code that people can download and use or just look at, which I will update a page with links to it and of course a short post to inform when I do updates. I most likely will not be putting up links on my Facebook and G+ accounts to new posts, but I will when I do something substantial. I'm not sure if I'll use Twitter to announce new blog posts. I've really stopped using Twitter, last time I was on it was just to tweet that I had a new post up (yeah, that long ago). Hopefully this get me writing more, unless blogging just really isn't my thing.
Monday, April 21, 2014
Hey look....code!
So I posted up a page of code today. You can see a link to it on the right titled intTextField. This page is a work in progress as I'm unsure exactly how I want to use the pages feature on blogger. . I want to showcase general purpose code that I write that I think would be useful for others and get feedback from others on it, and update it when I can. So here is my first tiny piece of code for people to see. It is a user control that show a textfield that does server-side validation on it as a number and includes an asterisk that displays/hides depending on if the validation fails or not.
http://codetimecharlie.blogspot.com/p/inttextfield.html
http://codetimecharlie.blogspot.com/p/inttextfield.html
Sunday, December 15, 2013
I hate resumes
I hate resumes. I hate creating them. I hate that potential employers expect me to have one, and for it to be current. I find it hard to believe that resumes still exist with all the communication and social technology we have today. Right now, my resume is just a copy of my LinkedIn profile because I hate writing resumes that much. What does a resume do for a potential employer that looking at a LinkedIn profile doesn't? Even Facebook have a place to list where you have worked, at what position, and for how long.
I should really state my problems with resumes instead of just ranting about how much I hate them.
1) They don't do anything better than other forms of communication. In fact, they don't even replace other forms of communication. Resumes are just another useless step in the communication chain. They don't introduce you, that's what your cover letter, or email, is for. While resumes summarize your job experience or skills, the letter or email you write can do the same thing, while also showing off your ability, or inability, to communicate well. Also, most professionals have a LinkedIn account, or something similar (that may be a lie, I don't know of anything similar to LinkedIn, but if there is I don't want them to feel left out). I have many recruiters email me because they found me on LinkedIn. As I said before, my resume and LinkedIn account are the exact same. So why do I need to provide a resume as well? Can't you just send your client a link to my profile, it's public for a reason. Also resumes can't answer any questions a potential employer may have about you. Those are what interviews are for.
2) They are too general. If someone plans on sending out resumes to lots of different jobs, they tend to use the same resume. This means that the resume is generalized. They doesn't make you look as attractive as someone who may have tailored their resume to be more appealing to the specific job. Even with the tailored resume, they do tend to come off generalized. They are supposed too. The resume represents you. Many people just want a job (although some only want a specific job, so their resume tends to be more specific), but the good jobs don't want to just hire anyone, they want a specific person. In fact, it is probably easier for the company to use some sort of network to search for people with specific skills who may be looking for a job. I wonder if such a network exists. Oh yea, LinkedIn.
3) You can't tell anything about a person without ever talking to them. A resume only states what that person has done in the past, according to that person. No one ever hires someone based off their resume. They give out interviews based on resume. Actually, that's wrong. They contact people based on their resume, either by email or phone. There they will ask a few questions to make sure the person isn't totally lying about the skills they have, and THEN set up an interview.
I think it was Leonardo da Vinci who wrote the first resume, and he wrote it as a form of introduction. I don't see how a quick email with a link to a place with more information about you (once more LinkedIn, no they aren't paying me for this post…I just use it) is any different. It seems way easier to me, especially since I tend to lose my resume file all the time or it is horribly out of date for some reason. Having LinkedIn is even better because now I get contacted about potential jobs, although it is starting to get a bit annoying, and I've pretty much stopped responding to anything that doesn't look interesting to me, which is pretty much ALL of the jobs I get emailed about.
I'm going to see if I can get anyone to try to hire me without using an resume. Sounds like a fun challenge.
I understand that many companies won't look at you if you don't use a resume. By all means, don't not use one (double negative for the win), especially if it is a job you really really really want. It is a small hoop to jump through. Resumes had their place back in the day. Back before email was a regular thing. I just feel like the resume is an old fashioned and inefficient way of doing things, or maybe I just hate writing them that much.
I should really state my problems with resumes instead of just ranting about how much I hate them.
1) They don't do anything better than other forms of communication. In fact, they don't even replace other forms of communication. Resumes are just another useless step in the communication chain. They don't introduce you, that's what your cover letter, or email, is for. While resumes summarize your job experience or skills, the letter or email you write can do the same thing, while also showing off your ability, or inability, to communicate well. Also, most professionals have a LinkedIn account, or something similar (that may be a lie, I don't know of anything similar to LinkedIn, but if there is I don't want them to feel left out). I have many recruiters email me because they found me on LinkedIn. As I said before, my resume and LinkedIn account are the exact same. So why do I need to provide a resume as well? Can't you just send your client a link to my profile, it's public for a reason. Also resumes can't answer any questions a potential employer may have about you. Those are what interviews are for.
2) They are too general. If someone plans on sending out resumes to lots of different jobs, they tend to use the same resume. This means that the resume is generalized. They doesn't make you look as attractive as someone who may have tailored their resume to be more appealing to the specific job. Even with the tailored resume, they do tend to come off generalized. They are supposed too. The resume represents you. Many people just want a job (although some only want a specific job, so their resume tends to be more specific), but the good jobs don't want to just hire anyone, they want a specific person. In fact, it is probably easier for the company to use some sort of network to search for people with specific skills who may be looking for a job. I wonder if such a network exists. Oh yea, LinkedIn.
3) You can't tell anything about a person without ever talking to them. A resume only states what that person has done in the past, according to that person. No one ever hires someone based off their resume. They give out interviews based on resume. Actually, that's wrong. They contact people based on their resume, either by email or phone. There they will ask a few questions to make sure the person isn't totally lying about the skills they have, and THEN set up an interview.
I think it was Leonardo da Vinci who wrote the first resume, and he wrote it as a form of introduction. I don't see how a quick email with a link to a place with more information about you (once more LinkedIn, no they aren't paying me for this post…I just use it) is any different. It seems way easier to me, especially since I tend to lose my resume file all the time or it is horribly out of date for some reason. Having LinkedIn is even better because now I get contacted about potential jobs, although it is starting to get a bit annoying, and I've pretty much stopped responding to anything that doesn't look interesting to me, which is pretty much ALL of the jobs I get emailed about.
I'm going to see if I can get anyone to try to hire me without using an resume. Sounds like a fun challenge.
I understand that many companies won't look at you if you don't use a resume. By all means, don't not use one (double negative for the win), especially if it is a job you really really really want. It is a small hoop to jump through. Resumes had their place back in the day. Back before email was a regular thing. I just feel like the resume is an old fashioned and inefficient way of doing things, or maybe I just hate writing them that much.
Thursday, October 24, 2013
Are you done yet?
I would like to start this off by saying that not every story I post here is a true story. There are almost always exaggerations, since they get the point across the best, and the people, places, and companies involved are probably not who you think they are. I've worked in plenty of places with plenty of people.
So...I once had this kind of conversation:
Other Person: "Do you have everything checked in to TFS?"
Me: "They aren't done testing yet, so I don't know what needs to be fixed."
Other Person: "Well...we need to move to staging so we can get the release out."
Me: "Ok, but we need to test our stuff first and fix the bugs they find. They just started testing today."
Other Person: "Well, you think you can have all the bugs fixes done by 12:30?"
I look at the time.....it is just past 11:30.
Me: "I can't tell you that, because I don't know what bugs there are....because they aren't done testing. They probably won't finish testing today either. "
Other Person: "But we need to go to staging. How about you fix what you need to fix and just ignore anything they tell you they need fixing for this upcoming release then"
Me: Sliently screaming and cursing.
Now some back story for this little conversation. We have a one month release cycle. There is a date for a code freeze, the day where all of our code for new features and changes to old feature need to be in by. The next day, a new build is supposed to be built for testing. From what I gather is SUPPOSED to happen, we get a week to test the new code / fix bugs, and then it moves to "staging" and then live right after that. So generally three weeks of coding new stuff / fixing bugs that have made it to production and a week of debugging new code. (I don't know what the actual schedule is...nothing is documented). What happened here is that the guy who is supposed to do the test build didn't get to it until Friday...which is basically our whole testing week. Tt doesn't matter to him though, different employer and all. So the move to staging was supposed to be that Friday, the day he did the test build. In certain places of employment, this isn't a problem, since they have a test environment that they themselves control. We do not. We are subject to the whims of others, and it makes me mad (we don't even have proper testers either).
Here are some of the problems I have identified that this story and conversation present. The first being a delay in the schedule....but not moving the deadline. When you have something on your schedule..say like updating an application, and it can only happen after something else on your schedule...like testing said updates and correcting bugs....when the first something is late or delayed, the thing that follows is automatically behind. So if you are five days late to making the build for the test server and we need and/or get five days for testing before moving to staging, then the date to move to staging gets pushed back five days, otherwise you end up with a pile of s**t. Good example would be the ACA Exchange website. I think they only had like two weeks or so for testing. I could be wrong about that, but it wasn't nearly enough time. And changing the requirements of the product with less an a month to launch means you need to push back the launch date...or not change the requirements (yea, that would have been easier). If you don't have cushion days, you can't keep your schedule if a single thing ends up falling behind. Cushion days are extra days to get stuff done in case something like this happens. They are a bit like hurricane days that schools get in Florida. They are extra days off for the students...unless a hurricane comes in and wreck the hell out of the school, making it close down. In that case the student makes up those days the school were closed by attending school on the hurricane days.
The other problem with this conversation is asking me when the bugs will be fixed. I can't possible know that...especially if I don't even know what the bugs are! That is like asking a physics student how many sheets of paper they need to solve a problem when they don't know what the problem is. It could be half a sheet of people....or it could be 10 sheets of paper. Depends on the problem. It is the same with coding, a bug could take 10 seconds to fix, it could take the entire week. I can't know until I see the problem. Every coder does things wrong from time to time. It happens. If you can't fix the bug by the time you are ready to go to staging, you roll back your changes and that feature isn't released. Simple.
The correct course of action here would be to roll back our changes and not release any features since there was no time to test. That isn't what happened. In fact, I'm not really sure what happened. Testing was still being done the next week and I was still checking in bug fixes the next week. I guess they gave us more time to fix stuff. Which makes me wonder why I was being hounded with that conversation in the first place. I suppose that is a post for another day though.
So...I once had this kind of conversation:
Other Person: "Do you have everything checked in to TFS?"
Me: "They aren't done testing yet, so I don't know what needs to be fixed."
Other Person: "Well...we need to move to staging so we can get the release out."
Me: "Ok, but we need to test our stuff first and fix the bugs they find. They just started testing today."
Other Person: "Well, you think you can have all the bugs fixes done by 12:30?"
I look at the time.....it is just past 11:30.
Me: "I can't tell you that, because I don't know what bugs there are....because they aren't done testing. They probably won't finish testing today either. "
Other Person: "But we need to go to staging. How about you fix what you need to fix and just ignore anything they tell you they need fixing for this upcoming release then"
Me: Sliently screaming and cursing.
Now some back story for this little conversation. We have a one month release cycle. There is a date for a code freeze, the day where all of our code for new features and changes to old feature need to be in by. The next day, a new build is supposed to be built for testing. From what I gather is SUPPOSED to happen, we get a week to test the new code / fix bugs, and then it moves to "staging" and then live right after that. So generally three weeks of coding new stuff / fixing bugs that have made it to production and a week of debugging new code. (I don't know what the actual schedule is...nothing is documented). What happened here is that the guy who is supposed to do the test build didn't get to it until Friday...which is basically our whole testing week. Tt doesn't matter to him though, different employer and all. So the move to staging was supposed to be that Friday, the day he did the test build. In certain places of employment, this isn't a problem, since they have a test environment that they themselves control. We do not. We are subject to the whims of others, and it makes me mad (we don't even have proper testers either).
Here are some of the problems I have identified that this story and conversation present. The first being a delay in the schedule....but not moving the deadline. When you have something on your schedule..say like updating an application, and it can only happen after something else on your schedule...like testing said updates and correcting bugs....when the first something is late or delayed, the thing that follows is automatically behind. So if you are five days late to making the build for the test server and we need and/or get five days for testing before moving to staging, then the date to move to staging gets pushed back five days, otherwise you end up with a pile of s**t. Good example would be the ACA Exchange website. I think they only had like two weeks or so for testing. I could be wrong about that, but it wasn't nearly enough time. And changing the requirements of the product with less an a month to launch means you need to push back the launch date...or not change the requirements (yea, that would have been easier). If you don't have cushion days, you can't keep your schedule if a single thing ends up falling behind. Cushion days are extra days to get stuff done in case something like this happens. They are a bit like hurricane days that schools get in Florida. They are extra days off for the students...unless a hurricane comes in and wreck the hell out of the school, making it close down. In that case the student makes up those days the school were closed by attending school on the hurricane days.
The other problem with this conversation is asking me when the bugs will be fixed. I can't possible know that...especially if I don't even know what the bugs are! That is like asking a physics student how many sheets of paper they need to solve a problem when they don't know what the problem is. It could be half a sheet of people....or it could be 10 sheets of paper. Depends on the problem. It is the same with coding, a bug could take 10 seconds to fix, it could take the entire week. I can't know until I see the problem. Every coder does things wrong from time to time. It happens. If you can't fix the bug by the time you are ready to go to staging, you roll back your changes and that feature isn't released. Simple.
The correct course of action here would be to roll back our changes and not release any features since there was no time to test. That isn't what happened. In fact, I'm not really sure what happened. Testing was still being done the next week and I was still checking in bug fixes the next week. I guess they gave us more time to fix stuff. Which makes me wonder why I was being hounded with that conversation in the first place. I suppose that is a post for another day though.
Subscribe to:
Posts (Atom)