Let me start out by defining exactly what I mean by a Successful Developer.  The ideal Successful Developer is one who is loved by management, users, and fellow developers.  I know what you’re thinking, how hard can this really be?  Well, take a look at your own career and think back on how much you’re really liked in these three areas...

Managers typically look for someone who can make them look good.  This isn’t meant to knock anyone who I’ve ever worked for, but rather a simple fact of life.  A developer who makes a manager look good is someone who knows how to play the political game; someone who knows when to open their mouth and when to keep it shut; and finally someone who under promises and over delivers, on time, always.

Well, this is possible I guess, but typically a developer who makes their manager that happy isn’t really a developer but more a Manager in training.  Sure it’s easy to quadruple your estimated effort, promise nothing, and meet the insanely high timelines you’ve set out for yourself but let’s face it, a good developer is the ultimate logical individual.  If it is going to take a good developer one month to do something they will tell you it will take a month... we don’t make things up, life is what it is, nothing more nothing less.

Users are probably the easiest to please.  As long as you’re completely honest and deliver what you promise to them on time they’re typically happy.  Although this is no simple task in today’s political nightmare we consider Software Development, keeping our promises are usually fairly easy, but usually lead to CLM’s (Career Limiting Moves for those of you not familiar).  Again, Developers are very logical people so telling the truth usually comes naturally to us, but makes enemies with those who don’t want the truth.

Now, this is by favourite category because it is the most often forgotten.  I was once told by a lead that he was not here to make friends, that business is business and personal lives are personal lives.  Although this true we have this thing called the community who we have to report to as well.  If I constantly make promises that other developers cannot keep, I make enemies even though I may have believed the task possible. 

At the same time, I have to include myself in this category.  That is, I have to consider how many times I’ve sold myself out because I made a promise, and found myself working countless extra hours on my own time just to make that ridiculous deadline that was imposed on me.  The next time you find yourself on the tail end of a 12 hours shift staring at your keyboard wondering why the keys can’t type themselves take a second to ask yourself just how happy you are with yourself... I bet you’ll be pretty irked about it.

Then there is the maintenance factor.  That so often overlooked “extra” cost that I have yet to find a project team who actually cares about it.  The fact of the matter is simple a project team is there to developer a set of features, on time, and on budget... they don’t care if it takes someone two or three times longer than it should to make modifications after the fact, their success is based purely on their delivery date.  Well, I guarantee you that for every line of code you write someone at some point will have to maintain it.

There is a legend surrounding the profession of architects that tells of an architect who designed a marvelous library in which he forgot to take into consideration the weight of the books.  This over sight on his part later caused the library to be condemned as the library gradually sank over time.  Although no more than a legend, it brings to light an interesting topic… When we make a decision and influence all of those around me, what if we miss something?

Well, our profession actually has certain check points that have been instituted to prevent such disasters from happening.

1.       Code Reviews:  This one is the most obvious, but code reviews are highly beneficial for both this check, and many others provided they should serve as more than a Hey, you spelled that name wrong purpose.  Code reviews can act as a final check to ensure that the developers are in fact sane in their design, and not off in la la land.

2.       Unit Tests:  This serves more to prevent someone from going in and changing something, and introducing these types of insights.  With a good set of unit tests covering 100% of the testable code, it is very easy to catch these modifications over sights provided the initial design was sound, and tested accordingly.

3.       Test Driven Development:  Simply put, starting with what the users (internal or external to IT) want, and moving backwards to provide the code can help to eliminate this issue as well.  When we code off in our own little worlds, we tend to add tons of edge cases and this could happen scenarios that no users would ever consider.  This is a mixed blessing because as developers we tend to be very detail oriented, and can often conceive of situations that could never happen in real life.

4.       Peer Programming:  Well, two sets of eyes are, and always will be better at catching bugs than one set… it’s that simple.

At the end of the day, this list is just a small portion of the hundreds of ways we’ve attempted to perfect our profession.  Realistically though, there are by far more failed attempts than successful ones at bullet proofing the art of software creation and it always comes down to one thing, the people developing the code.

Let us consider for a few seconds the scenario about the weight of the books again; lets apply this to software development and analyze just what could have been done differently in this situation.

1.       Code Reviews:  Well, sure if the design was reviewed it may have stopped this, but a good architect can sell any design even to other architects no matter how wrong it may or may not be.

2.       Unit tests:  Well simply put the initial design was flawed.  A good set of tests would have actually tested to ensure that the library would sink with the weight of the books, possibly exposing the issue.  Realistically it was never something which was taken out of the design, so no one would have thought to test it either.

3.       Test Driven Development:  I highly doubt the users would have ever thought to question the architect and ask if he had accommodated for the extra weight.  In fact, most architects would be offended if a user had questioned something like that because it is after all, their purpose to find those issues no one else thinks of.

4.       Peer Programming/Design:  Yes, this would have at least doubled the chance of finding this issue in the initial plans, but it could have slipped through to the end still.  Even peer teams are by no means perfect.

So I guess this kind of exposes a bit of an issue… maybe we aren’t as bullet proof as we think we are?  The only real suggestion I can think of is that we need to take that step back and look at the big picture some times, get our heads out of the code and look at the larger impact of the lines we write.  Maybe one line of code at a time, module by module is not really going to solve our problems?  I guess what I’m saying is when you look at the big picture, sometimes the code really is just a small piece of the puzzle…

Recently there has been a lot of talk around my work place about ease of adoption on a software project... essentially how easy is it for someone who has never looked at the code to go into TFS, download the code and run it and the unit tests.  I am a firm believer that I should be able to simply open my source control window, and double click on the solution file.  There shouldn’t be any third party items that HAVE to be installed separately, no libraries that need to be referenced out of the GAC, none of that.  In my eyes, if I have to do any more than a simple double click and run the project is a giant failure.  I mean it, at this point I think it would be appropriate to delete all of your code, and go register yourself back in school because you do not deserve to be developing on an enterprise level.

Now here’s why.

1)      Recently I’ve taken on a new project, and it’s taken me two weeks to find all of the third party libraries that I needed, install them, and configure my machine to actually work with this project and the others I have installed.  This is caused mostly by versioning issues, when the new project is expecting a different version of a DLL than I currently require for something else, who should win?  Well, the second I got it working I pulled everything into a library folder and checked it into our source control.  This took me all of about half an hour to accomplish once I got it working, and if I could have saved myself the previous two weeks or non-sense work I would have greatly appreciated it.

2)      Talking with the developers on the same project as I had all the issues with, they had the exact same problems as I had, and actually listed it as one of their biggest headaches. 

3)      The ability to move the code to a build server.  For those of you who have never had the luxury of using a build server I strongly suggest that you go out and download one such as TeamCity by Jetbrains.  It is one of those things that I’ve just started to use and I could not justify stopping.  It makes deployments as easy as copy and paste.  Also, when you’re working with other developers who might not be as anal about running unit tests as we are, you can set up the build server to automatically run them every time code is checked in.  Guess what that means, no more downloading someone else’ broken code when you get latest!

4)      And finally, why not?  For the half an hour that it took me to fix it, it probably would have taken 20 minutes to do it right the first time...

The most common excuse that I’ve heard in regards to this from other projects is we don’t have the time to do it right, so we made it work the only way we knew how to.  At what point did our profession become more about getting it done, and less about getting it done right?  I’m sorry but I don’t know of a single user that would object if I said I was going to spend an extra half an hour on a three month project to make it so that any changes they ever wanted would take half the time to implement... but maybe that’s just me...

I am what I refer to as a developer by birth.  I have long subscribed to the school of thought that there are two types of software developers currently practicing in our industry, there are those like myself who were born with this gift that allows them to just kind of see the way things fit together, and the reason for wanting to put them together.  There are few questions that we do not know the answer to, both professionally and personally, however acting on those answers is entirely different.  This group of developers tends to be highly practical individuals, everything follows a flow of logic and even though we may not know every term from every book on the subject we are practically obsessed with the profession that is we eat, sleep, and breathe everything related to development from a mental standpoint whether it really has anything to do with code or not.

Then there are those developers who are trained to do what they do, either officially through the use of post secondary education institutes, or through back room training found in books and practical experience.  These developers make slightly less sense to me because it seems that everything is over thought, over analyzed, or just plain too much by the book.  These developers are the obsessed type who leave work for the day hoping to read the next book on the subject so they can learn two more terms… even though most of the knowledge they memorize will never be put into place, they know the words to describe what they do not do.

I think the best way to look at the difference between the two is to take a real life situation not related to code in any way.  Let’s take the example of changing a tire on a car.  The second group will read the owner’s manual to find out where the spare tire is stored, and religiously study the book numerous times before they so much as open the trunk to retrieve the tire.  Once all of the possible details are taken into consideration, and everything is mentally mapped out then and only then will they remove the spare tire and begin their task.  If they run into a problem they first go back to the book to ensure that this scenario was not covered, than act on whatever knowledge they can to work through the task at hand.  The first group of developers however, will pull out the tire, jack, and tire iron; jack the car up; and start beating on the tire with the tire iron until it eventually comes lose.  If they run into a problem while changing the tire, it is only a matter of time before their analytical minds discover a solution, no matter how crude or unconventional in nature.

I am not here to say which group is better or worse, I mean I take great pride in belonging to the first group but would never say that someone from the second group is not as good as I am just because they belong to that group… that’s usually something said with proven evidence and countless hours of frustration on my part trying to find the right book for them to read to understand what I am talking about but, I digress.  My problem lies with all of the HR focused idiots who rate me not on the quality of my work, not on my ability to solve impossible tasks, and not by my utter love of being a developer… but rather those who rate me based on the last book that I read, the number of fancy terms I can throw out, and finally how smart I sound as opposed to how smart I am.  It is truly a sad day today as I realize that how smart I am has nothing to do with what I know, but rather how well I am liked to those HR focused dumbasses that seem to hold their rubber sticks over our progression.  I think this is where we have truly failed, by allowing a bunch of rubber stick carrying dictators instruct us on how much we know and my question to them is simple… when was the last time you wrote something?

As a software engineer by trade, I tend to think about things such as performance being a key factor to the quality of pretty much everything I use. If I go to a website and it takes me 30 seconds to load a very simplistic interface with a few paragraphs of text I tend to get an instant dislike for the application. I know that most users feel the same way. I know years ago in the age of dial up, it was said that if a user ever had to wait more than thirty seconds for a page to load, you had a 50% chance of losing that user on your site forever… My question is what happened to those days of optimization? Was it truly lost with the age of bandwidth? Do we really care about the fancy buttons that much that we've forgotten about writing quality interfaces?

When I recently had the pleasure of working through some old code written a couple of years back by another developer I had a very strange eye opening experience; just how inefficient Server controls can be in .net. This shouldn't be new to anyone really… I mean in the first couple of chapters of my MCTS book it very clearly illustrates that server controls can provide dynamic behavior, and greatly simplify the process of processing the user interaction state of development, but server controls should only be used when this is required. With this rather lengthy introduction, I present to you the most misused server control, the ASP Label.

Microsoft defines the Label Web Server control as having the functionality to "Display static text on a web forms page and allow you to manipulate it programmatically." I use labels all of the time for this purpose, and they work really nicely for it. This however is one of things I do not use a label for:

<asp:Label runat="server" ID="HeaderText" CssClass="H1HeaderText" Text="Static Header"/>

I would instead place something like:

<h1>

Static Header

</h1>

I know what you're thinking, what's the big deal with putting a few extra labels here and there? Well, I was wondering the exact same thing, so I did a bit of a test to prove my point.

I set up two pages, one with nothing but a label that had some text in it, and another with nothing but a span tag with the same text in it. I used a span tag because that is usually what a label will resolve to after being rendered by .net. I than set up a bit of a test using Watin to spin up several threads, and test the performance of rendering that page with a single label tag vs. the one without. After loading and closing each page 100 times, I found that on average it took roughly 100 ms more to load the page with a single label. I did the test again but this time placed two labels on the one page, and two equivalent span tags on the other. I found that it took roughly 200ms longer to load the page with two labels than the page without. That worked out to be roughly 10% of the total rendering time of the page, keeping in mind of course the only thing on the pages was a label.

So, 100ms per label… that's not that big of a deal right? Well imagine a page with 10 form elements on it, a few paragraphs of static text, and maybe a header and footer, this seems like a fairly typical form to me. Say we said that there were 20 labels total that could be converted to their HTML equivalent without losing any functionality. Given that my small experiment is correct, that would mean that 2 full seconds of server processor time could be simply cut, per request. That means that you could improve the efficiency of these pages by as much as 10%, for doing little more than using a control for its intended purpose… It is for that reason I consider the label ASP's most abused Server control.