You’ve heard the term ROI before, probably in a room filled with big wigs throwing around other useful terms like lift, push, paradigm, and my favorite, Web 2.0. It’s in these meetings that I dream about going back to a 110 degree heat of an Arizona restaurant kitchen. Ok, not really.

Whether you have experienced the buzzword bingo meeting from hell or not, the term ROI, or Return on Investment, is truly missing in most, if not all, software projects. Do you, dear reader, know how much it costs to build and maintain software? Do you know how much time will be saved or how much money will be made by your solution? Do you know the life expectancy of your solution? If you did, then you would be able to calculate your solution’s return on investment.

ROI is all about the Benjamins. Is your solution going to save or make enough money to breakeven and when? These are tough questions. The cost benefit analysis of ROI gives you a sobering number, with which, you should be using for your projects Go – No Go decision. Most applications would not see the light of day if you used these criteria because the ROI numbers would force you to seek cheaper solutions elsewhere.

Is the future of ROI based software building in jeopardy? No, it is not. The need for pragmatic solutions to everyday problems still exists and these problems, when prudent, should be solved by software. The real question is what software?

We all have the default software architecture in our head or in our IT shop. You know the comfy solution you pull out when you need to solve a problem. It’s the one that has been drilled into your head by folks like me or the gurus in your community. The problem with this architecture is cost. It is expensive to do “things right” and that’s the problem, what is right for one problem is not right for another.

Will being a dogmatic user of stored procedures tip the ROI decision into the no-go category?

Please, don’t get me wrong; there are a few things that should not be skimped on like testing, maintainability, logging and data integrity. You should be pragmatic in your selection of features needed for each solution to give your ROI a fighting chance. Stored Procedures are great when data is modified by multiple independent systems but unnecessary for a small app to track meeting attendance, if your business is making kitchen widgets.

Is your default software architecture like a golden hammer looking for golden nails? Is your hammer appropriate to the nail you’re currently trying to pound? ROI should never be calculated with a default architecture. If you had a real golden hammer, would you use it on a copper nail? I wouldn’t, it’s just too expensive.

Well, it’s the first day of 2010 and it’s time to get the New Year’s resolutions in order. Like most years, my resolutions have centered on becoming a better, slimmer person / programmer, and this year will be no different.

Slimmer

If you knew me at the beginning of last year, you would have known more of me. I have lost about 40 pounds and I am hoping to restart that trend in this new year. My goal for 2010 is another 40 pounds and to gain some strength and endurance.

I plan on meeting my resolution using my favorite exercising activities—stair climbing and kettlebell lifting. My goal for this year is a 10 minute kettlebell swings set with a 16Kg kettlebell while only switching hands once. Can you do something with a 35 pound hunk of metal for 10 minutes without putting it down?

Programming

By day, I am a .Net developer for a local university; but by night, I am Ruby on Rails enthusiast. This year, more, if not all, of my non-university coding will be on the Rails stack. I am finding Rails, Ruby, Gems, Capistrano, Rake and RSpec to be superior for my needs then the current Microsoft offerings. I would love to write a Rails web app to help Microsoft developers; I just love the irony.

Blogging

Yeah, yeah, I’ll get to it; I think.

Culinary

Most people don’t know this about me but I have a culinary degree from a nationally known culinary school and have been, in a previous life, a pastry chef for a 5 star restaurant. My cakes have appeared in the local papers and some national newspapers like the Dallas Morning Star and the New York Times.

With all of this training and experience, I have let it go to waste, but no more. I plan on knocking the rust off of my culinary talent and putting it to good use helping people eat and live better.

The problem with New Year’s resolutions is that it only comes around once a year. What I really need is a monthly or weekly resolution. Maybe that should be this Year’s resolution. A resolution to be resolute in my resolutions.

Hello, my name is Adam and I am addicted to information. My addiction has flared up in 2009 and, if my pre-orders and beta purchases are any indication, 2010 will be more of the same.

I have purchasing accounts at Amazon with Prime, Kindle with one click and Pragmatic Programmer’s with multi-file format downloads. Whether in dead tree, PDF, MOBI, AMZ, or EPUB format information is my best friend. I don’t have an addiction; I can stop at any time. I am helping the economy.

If you are striving to get better in your craft, then I would suggest you pre-order Rework and CLR via C# Third Edition. Both books are from people with experience and real world knowledge to share. Their previous works were so good that their new work deserves a pre-order.

I don’t want to wait to get it into my hands and into my brain.

Rework – Estimated Delivery March 11, 2010

I can’t wait to read the second book from the guys over at 37 Signals. I have no doubt it is full of uncommon sense and unconventional wisdom like their previous work, Getting Real. If you have not read the original, you can read it online for free at 37 Signals website http://gettingreal.37signals.com. After you read it, I know you will pre-order this book.

CLR via C#, Third Edition – Estimated Delivery February 10, 2010

If you have not read the second edition of this book, then you have truly missed something. Even today, I look through the second version and remind myself of what I have forgotten or failed to learn. I am truly excited about getting my hands on this new version written by a true craftsman, Jeffrey Richter. The new section on threading alone will be worth the price.

If an application is going to be used by other people, then logging events and errors is an essential and required part of the application.

Logging is not a feature; it is part of a standard base architecture. Recently, I have been working on projects that do not have any logging at all. The application emails the error and stack trace to the original developer when an error reaches the global.asax. This does work in their small environment today but it will fall short when the number of applications and support personnel grow, or when a developer goes on vacation.

I do not understand why Microsoft has not made this part of IIS. Even Rails out of the box has a logging framework and sensible configuration values when you create a new project. Yes, I know about the event log; it does not work well in a deployment scenario with more than one server. You would think that the company that makes the server and the framework would sit down with each other and come up with something better, but they have not, so as a good developer we turn to open source.

Technical craftsman do not build what they can legally use for free, today.

There are a great number of logging frameworks to choose from. My current choice is NLog. This is a great framework that is simple to set up and, more importantly, simple to configure. I don’t know about you, but I like the simple XML configuration of NLog compared to the Log4Net or EntLib configurations. Log4Net configuration is something you don’t touch once you get it running because you fear that you are going to break something and spend another hour of your life fixing it. Have you ever copied a Log4Net configuration file from a pervious project just so you didn’t have to figure it out again?

Logging in three easy steps:

1.) From your project add a reference to the NLog.dll. The NLog assets should be put in your solutions lib directory and added to your version control.

2.) Add a “NLog.config” configuration file to your web project’s root. This sample configuration will log to the output window.

 
<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       throwExceptions="true" internalLogLevel="Debug">
 
  <targets>
    <target 
	name="debugger" 
	xsi:type="Debugger" 
	layout="${message}" />
  </targets>
 
  <rules>
    <logger name="*" minlevel="Info" writeTo="debugger" />
  </rules>
</nlog>

3.) Log a message

//Gets the current logger for this class
var logger = LogManager.GetCurrentClassLogger();
           
logger.Info("this is my message.");

Well, that’s it. NLog should be up and running and logging to your output window. Easy as easy could be. Adding a more persistent logging target is the next necessary step. I log to a central application support database by adding the following target and rule to their appropriate configuration sections.

 
<target name="database" type="Database">
      <dbprovider>mssql</dbprovider>
      <dbhost>SQL</dbhost>
      <dbdatabase>AppCommonDatabase</dbdatabase>
      <dbusername>nloguser</dbusername>
      <dbpassword>yougue55ed1t</dbpassword>
 
      <commandText>
        insert into LogTable (
          [CreateDate],
          [Identity],
          [Origin],
          [LogLevel],
          [Message],
          [Exception],
          [StackTrace])
        values (
          @createDate,
          @identity,
          @origin,
          @logLevel,
          @message,
          @exception,
          @stackTrace);
      </commandText>
      <parameter name="@createDate" layout="${date}"/>
      <parameter name="@identity" layout="${identity}"/>
      <parameter name="@origin" layout="${callsite}"/>
      <parameter name="@logLevel" layout="${level}"/>
      <parameter name="@message" layout="${message}"/>
      <parameter name="@exception" 
		layout="${exception:format=Message,StackTrace}"/>
      <parameter name="@stackTrace" layout="${StackTrace}"/>
     
    </target>
 
<logger name="*" minlevel="Debug" appendTo="database" />
 

Now that you are up and running you should add error logging to the global.asax or a HttpHandler to log all application errors. Remember, with power comes responsibility; use logging wisely. I would start off with logging errors that reach the root of your application and every catch block. From there you could log about interesting things in your application like application events and users login errors.

Now, when the support phone rings, you can at least look at a stack trace and not just a screen shot of the Oop’s page from your web application. Don’t get me started about adding an Error Id to the Oop’s page and the logging database so you can easily connect the error to the log. That would just be slick and very easy to do with NLog.

I think Scott Adams is following me!

Sometimes I think that the creator of the Dilbert comic is following me. Is it just a coincidence that his comic strip mirrors my life? I am a big Dilbert fan. In my office there is a framed version of the “Code Simian – Architect” comic that makes me laugh every time I read it.

That said. If you feel like Asok, then you have two choices, you can do nothing or you can take your career into your own hands. If work is not providing you opportunities to use or expand your skills, then you need to create your own opportunities.

We, as developers, are very fortunate because we have abundant ways to enhance our skills. Whether you do it alone with books and blogs or with others in user groups or OSS projects, the key is to make these investments regularly. When was the last time you invested in yourself?