If you're not already subscribed to Jeremy Miller's blog, do so now. I'll wait for you to come back.

Okay, now that you've done that, read his latest post on sunk costs and architectural decisions. I'll keep waiting.

Done? Good.

As I was reading his post, I found myself nodding my head in agreement over and over again because I've been dealing with the exact same issues at work for the past few months. Sunk costs are something that every business deals with. A sunk cost is when you've already spent money on something and you later wish that you hadn't spent that money. The Wikipedia example that Jeremy cites of going to see a bad movie is the classic example of sunk costs.

One of the biggest problems with sunk costs isn't the actual cost involved but the fact that as soon as you admit you're dealing with a sunk cost, you're also admitting that a bad decision was made somewhere. This can lead to hurt feelings, hurt pride, etc. Jeremy points out that there can be political implications of this as well. Management will not be happy to find out that this awesome tool that was supposed to bring world peace, cure cancer, and solve the energy crisis actually is too slow for the masses to effectively use. They're likely going to question more than just the tool afterwards.

However, I submit that these same sunk costs can provide an incredible benefit to developers. One of the quickest and most efficient ways to learn is to make mistakes. If you get burned badly enough, you're not going to touch the hot stove again, because you now know that it is hot. If you're the one who is responsible for the bug that cost your company thousands or millions of dollars, will you make that same mistake again? Of course not!

Learn from your mistakes! I've been fortunate to be a part of a similar process and the results so far have been very positive. Our team has really come together and pushed out some really good code that our users are very happy with. Prior to starting the rework, we had all been dreading continuing to deal with the prior version of the product, because we knew we would be spending our time hunting down obscure bugs and hearing complaints from users. The question we continually heard from users was, "why is this better than before?" We hated the question because we didn't like the system either! Now, we can tell them with confidence that our work is without a doubt better and that we're behind it 100%.

From the management side, I submit that managers who give their teams a chance to fix mistakes and start over can gain a great deal of respect from their team. Our manager had ties to the prior system, but he also knew there were problems with it. The system had gone through three different groups before we had ever been given responsibility over it! No one even knew the system anymore! Not only did we come together as a team more, we also became more familiar with the code and were able to really take ownership of it. A positive response to problems or mistakes reflects a real maturity in leadership.

You can treat sunk costs as a straight loss and accept defeat. The better alternative is to treat them as a training expense. The benefits from training are not tangible, but most companies still spend money on their employees because they can become more efficient. Similarly, when we respond to sunk costs positively, they can provide the same kind of intangible benefits as training. Mistakes were made, but mistakes are an opportunity for growth. We all write bad code. Just be sure you learn from it and become a better developer!

UPDATE: Some clarification on sunk costs - a reader pointed out that a sunk cost isn't necessarily a bad decision or mistake, just an unrecoverable past expenditure. I'm no economist, but it seems that the term typically carries negative connotations.

Lately, I've been working on performance enhancements to one of the projects at work. Our users had all mentioned that the application's startup time was pretty slow and wanted to know if we could do anything to speed it up. Of course, when all of your users have been using green screen applications, even native C applications will likely seem slow to them... but anyway. We started digging in and found a few places where we could optimize our code but our form still took a while to load.

While testing, I happened to have Process Explorer up and noticed that our process was kicking off csc.exe, which is the C# compiler.

This is one of those instances where some (if not all) of you will know what I was seeing here. You see, we were using XML serialization in our project. When you do XML serialization, some code-gen happens to make the serialization magic work. If you have FileMon or ProcMon up, you'll actually see a temporary C# file being written out and compiled. I might have remembered this (Scott Hanselman has a lot of posts on the XmlSerializer) if I had thought about the temp file aspect, but I was wondering more about the C# compiler.

Anyway, the best way to avoid this precompilation step is to do the precompilation yourself using sgen. Basically, if you give it an assembly named Foo.dll, you'll get back an assembly named Foo.XmlSerializers.dll.

My only question regarding sgen is why standard compilation doesn't do this for you automatically. I'm sure there is some reason why, but I haven't thought of it yet. Regardless, I went ahead and added it to our build script and we've seen increased performance.

As a side-note, Red Gate's ANTS Profiler is an awesome profiler tool to help you find bottlenecks in your code. It will put big red lines next to the code that takes a long time to run.

This is completely off-topic, but I thought it was pretty funny.

I had this past Monday off from work and when I got into the office today, I noticed that I had a voicemail. As a programmer, that usually isn't a good sign, because many times it means a user has tried to call to let you know about a problem. When I noticed the message was left on Saturday morning, that made it seem even worse.

Then I actually listened to the message.

"If you would like to accept this call, please press 3... now."

I won't give you the rest of the message. Needless to say, hearing that prerecorded voice telling me my options for a collect call that I wasn't able to accept made me feel much better about my day.

I hope a user wasn't trying to call me collect.

So, want to improve at what you're doing?

In a phrase, don't stop learning.

In my profession (software development), this is even more important, because the field sure isn't going to wait for you. Jeremy Miller posted about how developers need to get out and "see the world." He was specifically talking about checking out other technologies like Ruby because it can help to see how things can be done differently, but he makes one statement that I liked in particular:

Software development is still a young profession that's in a state of constant flux and it's just not smart to put your head in the sand.

...

Yeah, I know, we all want work to end at 5 pm.  But development is the profession we chose, and if constant learning doesn't suit you, it's time to move onto something else.

This reminds me of a phrase that Scott Hanselman used in his recent podcast on "Hiring and Interviewing Engineers." Here's the relevant snippet from the podcast:

Scott Hanselman: ... I also ask
people about what blogs they read, what books
they read, how do they become lifelong
learners...

Carl Franklin: Yeah, very important.

Scott Hanselman: ...because it is not that you
want them to be people who are necessarily
working on Open Source projects at night, but
they should be enthused; they should be stoked
about whatever they are working on.

I actually typically use my lunch hour to catch up on feeds, which are an excellent source of continuing learning. As far as books... well, I've got like 5 or 6 at home that I need to read. I still need to work on that.

What are your tips on continual learning?

(man, this post reads a lot like those cheesy "the more you know" commercials from TV... sorry...)

I'm sure I'm the only one that has ever messed up like this, but anyway...

My TV is one of the 30" HDTV monitors. It was cheaper at the time and the box didn't mention anything about it not being a true "HD" TV. In other words, it doesn't support HD without a tuner. Regardless, though, it was cheap and it has a great picture.

Unfortunately, it doesn't have HDMI input, so when I upgraded from the old HD package from Dish Network to their HD/DVR service, the upgraded receiver I got only had component output and HDMI output.

Big deal, right? Surely I can deal with component.

Except that my Xbox 360 takes up one of my component inputs and my Wii SHOULD take up the other component input. I'm out of component inputs.

I did what any other self-respecting geek would do and headed over to monoprice.com, which is by far the best place to get cables or adapters... period. I ordered an HDMI to DVI converter a few days after ordering my Wii component cables. The Wii cables came first, so my 360 was unhooked for a few days while I could enjoy some 480p Wii goodness (it does look better than the 480i with the prepackaged composite cables by the way).

Today, my HDMI to DVI converter came.

And I goofed up.

I ordered the DVI (male) to HDMI (female) converter.

Not the DVI (female) to HDMI (male) converter.

The plugs don't work that way.

*sigh*

What's even better is I didn't realize this until I had already pulled the TV out, unhooked the satellite receiver from the component and rehooked the 360 component back in.

Moral of the story: double check your cables before you buy new cables.

Your programmer personality type is:
DHSC

You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.
You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.
You work best in a Solo situation.
The best way to program is by yourself. There's no communication problems, you know every part of the code allowing you to write the best programs possible.
You are a Conservative programmer.
The less code you write, the less chance there is of it containing a bug. You write short and to the point code that gets the job done efficiently.

Find out your score at http://www.doolwind.com/index.php?page=11.

You know about NTWind even if you don't think you do... NTWind is where you can get such awesome tools as WinSnap and TaskSwitchXP. The site has had a blog link on the side for a while, but it had been "under construction" for a few months...

Until now!

So go add the NTWind feed to your reader so that you'll always know when there is an update for one of the NTWind tools!

Jeff Atwood posted a great article talking about programmers that can't actually program.

I've been thinking about this a lot lately. Actually, lately is probably the wrong word, because I really started thinking about this way back when Joel Spolsky posted his infamous article on why he believes that colleges should teach C instead of Java. When that article came out, I had only been out of college for about a couple of years, but during that time, I had already seen my share of examples of programmers who couldn't program. Joel's article couldn't solve this problem for me, though, because these programmers would have had just as much trouble developing in Java as in C.

For many (non-)programmers, there seems to be a fundamental misunderstanding about programming in general, particularly with the ability to formulate basic algorithms to solve simple tasks. One example involved a programmer that had trouble with anything beyond placing formatted data to an HTML form. This programmer was tasked with moving through a DOM table to highlight cells that had certain values in them. In programming terms, he basically had to traverse an array checking for conditions - a very simple algorithm. However, he froze when he got to that part of his project, because he hadn't been trained in thinking about problems and how to solve them.

The examples that Jeff notes are just as much or more appalling and also show that these aren't isolated incidents.

What do we do about this problem?

At the end of his post, Jeff notes Steve McConnell's book on the profession of software development. It is an interesting concept and reminds me of a conversation I had with a pharmacist I met in my MBA program. He noted that some professions, such as pharmacy, have certifications to let the rest of us know that an individual actually knows what he or she is talking about regarding their profession while there are other professions that don't provide any sort of guarantee as to the actual knowledge someone possesses. I'm reminded of my wife in this case, because she has certifications for speech and language pathology. One of the requirements for her to keep her certifications is that she must have X number of hours of continuing education each year.

Could something like this work with software development?

There are obviously already many different certifications that exist (Microsoft certifications, Sun certifications, Oracle certifications, the list goes on), but that really brings out one of the problems with certifications in software development. I don't want to be a good developer with just Microsoft tools - I want to be a good developer period. If a software development certification existed that could ensure that someone was a competent developer and had a good knowledge of programming in general, it might work, but then again, the field changes constantly.

"OOP all the way!"

"No! TDD all the way!"

"Oh yeah, well, what about functional programming?"

"But... you can have functional and TDD at the same time!"

"You guys are all morons, QUANTUM programming is the way to go!"

It would be nigh impossible to have a certification that would be relevant and, more importantly, STAY relevant.

I'm sure I'm not adding anything new to this subject, but it has been on my mind for a while. I think I like the idea of a certification that requires continuing education - that almost seems like a must with software development. I primarily work with .NET 2.0 right now but it almost feels like what I'm working on isn't even relevant because of all the talk about .NET 3.0 (I know, just an extension of .NET 2.0) and LINQ, DLINQ, etc (actually coming from the upcoming new version of the framework.... 3.5?).

How would continuing education be defined in software development? Is it conferences? Reading blogs or books? Working on a variety of different projects so that you gain experience with different technologies?

Can the problem of programmers who can't program even be solved?

(By the way, before someone starts griping, I'm not advocating certifications... at least I don't think I am. I just want to see this problem fixed. Isn't that what all programmers want to do? Solve problems?)

...

I think this might be one of the longest posts I've ever written.

NOTE: This post was NOT inspired by anyone in particular... don't worry. Don't go thinking you're an awful programmer and I hate you.