Jeff Atwood on Professional Programmers

by fwhagen Fri, 04 May 2007

"You're an amateur developer until you realize everything you write... sucks, basically."   
--Jeff Atwood on .NET Rocks! podcast #232 (23:44) - 26 Apr 2007

"The minute you realize that then you've crossed the threshold.  Now you're a professional developer..."


Filed Under: Programming

VSS Source Code Headers: Automated Comments

by fwhagen Fri, 20 April 2007
One best practice I insist on is codefile headers, especially since VSS makes this stupid easy.  Below is the format I currently use for C#.NET:


#region Version Header
/// <remarks>
/// ----------------------------------------------------------------------------
///   Application: XXXXXXXXXXXXX
///     $Workfile: Default.aspx.cs $
///   Description: Start page for XXXXXXXXXXX.
///        Author: Frank Hagen
///       Created: 11/22/2006
///     Copyright: © 2007 XXXXXXXXXXXXXXX.
/// ----------------------------------------------------------------------------
///      $Modtime:  $
///     $Revision:  $
///   Mod $Author: XXXXXXXXXX $
///  VSS $Archive: /XXXXX/XXXXX/XXXXX/Default.aspx.cs $
/// ----------------------------------------------------------------------------
/// </remarks>

Keywords: ,

Filed Under: .NET | Programming

Lazy Coding or Careful Coding?

by fwhagen Fri, 09 March 2007

Some background:  A few months ago, I decided to put a little AJAX in an app I inherited.  The problem was a huge form that used post-back to fill some dropdown boxes based on values in other elements.  I coded the AJAX all from scratch, or near scratch anyway, mainly because ATLAS was still in early beta and this is a 1.1 app.  Anyway, everything worked well enough, or so I thought. 

This is where good end-user testing is so important.  You see, since I inherited this beast, I don't know how everything is supposed to work.  Some of the nuances are not always apparent to me and I might miss them.  For example, when creating a new form, a set a parameters will autofill the main form.  When I inserted my AJAX streamlining and tested, everything worked great from my perspective, a new form was created with some of the values prepopulated.   What I didn't realize was that the dropdown list was not being read correctly by the codebehind, because from it's perspective, it was empty the last time it saw it and was not reading the form post value.  I don't know yet whether this is my fault or the friendly designer who wrote this screaming... thing, but the end result is that not all of the values were filled that were supposed to.

So here's where my post title comes in:  When I put the AJAX calls in, I did not change the code-behind.  I simply added my JavaScript and disabled the elements' autopostback attributes.  When developing systems I don't understand, I make as little impact as possible and comment like hell, so someone can come in behind me and fix what I broke.  I also CYA in comments for who requested what changes and why.  Fixing broken code reminds me constantly about the importance of good commenting, despite that I don't do very good job of that in my original code.  Anyway, the implementation of some business logic features and these got rolled up, tested of course, and deployed late yesterday.

Well, this morning I get a frantic call and a HD Ticket:  Yep, the form is not populating all of the values.  It needs to be fixed immediately!  And behold!  It only took 15 minutes to find the cause and simply turn on the autopostback and disable the JavaScript.  All in the aspx file!  If I had removed or commented the methods in the code-behind, I would have had to recompile everything and risk version conflict; I had started on the next set of changes, of course.

So there's a lesson here, I think.  Although it is not the most efficient coding technique in the world, there is ample reason to not remove a method that you think is unused, especially if you do not understand the total impact of a change.  Let it sit there, all it is hurting is a tiny amount of overhead and some compile time.  This time it really saved my bacon!  Next time it will probably bite me.

Disagree?  Send me your exeriences in comments!

Keywords: , , ,

Filed Under: .NET | AJAX | Programming | Work

I Believe - ADO.NET Edition

by fwhagen Fri, 02 March 2007
I Believe...  that all database connections should be opened immediately before using them and closed immediately afterwards.
I Believe...  that if you are going to create a data layer, and you should, and you also create a data access layer, and you should, that the method be put in the lowest level and handled as abstractly as possible.  Yes the connection.close should be called before returning results.
I Believe...  that if you open the connection to the database in a method and pass that connection as a variable to another object, you should be shot.
I Believe...  that if you open the connection to the database in a method and pass it as a variable to another object, and forget to close said connection, you should be stabbed.
I Believe...  that if you open the connection to the database in a method and pass it as a variable to another object, and store the open connection in an ASP.NET session variable, you should be stabbed in the eye.  Twice.  With a spoon.
I Believe...  that if you store the results of a large query in ASP.NET session so you can page it back to the user, they haven't devised a painful enough punishment for you yet.
With special thanks to Blue Collar TV for the "I Believe..." concept.

Keywords: , ,

Filed Under: .NET | Programming | Rant

C#.NET Inheritance

by fwhagen Fri, 01 December 2006

Inheritance is a good thing.  It offers a great way to simplify coding through rollup of repetitive tasks and common attributes.  It is one reason why OOP is superior to most other programming methods.  It's a beautiful thing.

It also offers great job security.  Nothing endears your successor more than trying to figure out properties that are inherited 5 levels up in the abstraction with NO commenting or clue where to look.  And don't even get me started on N-Tier programming when N > 5!  Solutions get a bit unwieldy with 8+ projects attached.

Keywords: , ,

Filed Under: .NET | Programming | Work

Here's Your Sign

by fwhagen Wed, 22 November 2006

When you are looking at someone else's code, at what point can you definitively know it is bad code?  I'm sure everyone has their metrics.  Here's mine and so simple too:

Server Timeouts

Yep, real simple.  Here's the thing:  Nothing else, in my mind, shows a greater lack of understanding of the basic architecture of a system than poorly set timeouts.  For instance.  while not a bad idea to adjust the timeout of the SQL connection to fit what you are doing, setting it to 1200 means you don't realize that it means seconds and you just told your application to wait 20 minutes before doing any damage control.  I don't know about you, but ANY application that makes me wait 20 minutes for anything (without showing me real progress) is broken; I am impatient after 20 seconds!  Another example:  setting an ASP.NET app to use a session timeout of 300 minutes means you don't care about your server at all.  Why not store user specific information (full DATASETS!) in memory for 5 hours after the user has left the page.  5 hours!

These are real examples of code I am working on today.  I don't care how elegant your architecture is, Server Timeout abuse has always been a very simple indicator of developer incompetance.  Oh, and it seems to be in direct proportion of scale too.  I have actually seen an ASP session set to 3000000.  Yes 3 MILLION minutes.  That is 50,000 hours.  5 years, 8 months, 14 days, 13+ hours.  Yeah, that'll work.  I was not well loved because I wouldn't allow crap like that to run on my servers.

BTW, 3M minutes was by the same coder who thought LastName is a good primary key on a DB.  And when that didn't work, how about a composite key on LastName, FirstName.  Yep, World Class programmer.

Keywords: ,

Filed Under: Programming | Rant

Programmers' Bill of Sale

by fwhagen Tue, 29 August 2006

Jeff Atwood of Coding Horror, one of my favorite blogs, recently posted his list of Programmer's Bill of Rights.  While I completely agree with his enumeration, I think he overstates things a bit.  The list, editing out the links, is below:

    1. Every programmer shall have two monitors
    2. Every programmer shall have a fast PC
    3. Every programmer shall have their choice of mouse and keyboard
    4. Every programmer shall have a comfortable chair
    5. Every programmer shall have a fast internet connection
    6. Every programmer shall have quiet working conditions

I would add to that the ability to alter or modify my workstation in order to make it more productive to my style of programming.  Not trash the system or make if vulnerable to exploits, of course; but to allow me to load any little utility that I need to make coding easier, faster, or cooler.  I will get into some of these utilities in a later post.

I don't think it's our right to have these things, but the employers obligation to provide them.  Follow me here for moment:  It is my duty to do the best coding I can do given the tools I have.  That includes clear requirements, necessary hardware/software, and decent working conditions.  However, if my employer wants to get the greatest amount of productivity out of me, the above conditions should be met.  If they wish to pay me for substandard conditions, they should expect substandard output.

As GC says, If you go out and hire the greatest distance hauler you can find in order to guarantee the delivery of goods between LA and NY, you don't give him a pickup truck to do it with.

I am fortunate; after six years, I finally have a decent system:

  • A 21" Viewsonic Gfx monitor with a 17" Viewsonic sidekick
  • Dual CPU 3.4GHz Xeons with 2GB RAM
  • Crap keyboard, but I bought me a MS Wireless Laser 5000 mouse
  • Grabbed this comfy chair my first week and never let it go
  • Stupid fast Internet (OC style)
  • Could be quieter, but has been much worse.

So I am pumping out some great code.  At least I am not wasting any significant amount of time trying to coax my system into doing what it's supposed to be doing.


Filed Under: Programming