A $5 solution to a $5 problem

When I was in band instrument repair, I dedicated myself to becoming the best repair technician possible. I was constantly looking for ways to make my instruments respond more quickly, play with a fuller tone, etc. I got pretty good at it, if I say so myself. However, I found that it’s not possible to do that quality of work on every instrument and be able to make a profit. Most instruments just do not deserve to get that attention to detail. As a telling example, I would look at a student flute, which cost the store about $250, and decide that it needed $600 worth of work to get it in order. And that was typical for brand new flutes. Yes the manufacturing was shoddy, but I had lost any sense of context for quality in my work. I could only define “quality” as the best possible end product, which I now realize may or may not have been what my customer needed.

Luckily, I found a new balance in computer programming. Yes, it is satisfying providing that super-fast, bullet-proof, wonderfully designed software application to a business user. Thankfully I’m just as happy providing an adequate solution, knowing that in some cases the business stakeholder values low cost and short time-to-market more than they do software perfection. My goal is to meet the user’s needs in the best way possible, not provide the best end-product possible.

I’m quite disappointed, however, to see a vast number of developers who are doing the software equivalent of putting $600 worth of work into a $250 flute. These developers are making the same mistake that I did as a band instrument repairman – losing sight of the customer’s needs to satisfy one’s own arbitrary set of standards. I think business stakeholders are partly to blame for this (for reasons I will get to in a future blog post). However, we as developers need to renew our focus on making sure there is a good reason for each and every line of code we write. If it does not add more value than it costs to write it, then doesn’t belong in the project.

If coding seems tedious, then there's probably a better way...

I have to admit that I hate writing repetitive code. I’m not using the word “hate” lightly here. Whenever I’m asked to write a particularly boring group of code, I have to listen to rock music just to keep my mind occupied enough so I’ll finish my task without excessively checking my e-mail, talking to others, etc. If it gets really bad, I’ll go out for a brisk walk to burn off some of my energy, just so I’ll be able to sit for the amount of time necessary to get the job done.

Luckily I get to avoid writing tedious code most of the time. Usually there are ways around it. Getting data from the database and loading it into an object can almost always be automated by using an Object Relational Mapper. Getting information from an object onto a web page can be automated by using reflection, iterating through the properties, and setting the fields automatically. (If you don’t know what that means, it’s OK, it’s not central to the point of this post.) I’ve even written my own programs that will generate JavaScript for me so I don’t have to spend as much time debugging it.

A nice benefit to my avoidance of boredom is that by automating the boring stuff, my code is almost always faster to write and less error-prone than the more tedious equivalent. It’s a win-win, right? Why don’t more programmers think this way? You will get a few programmers who won’t use ORMs or reflection because they’re slower to execute, but in most cases I’m not going to lose sleep over a few hundredths of a second. I think mostly programmers don’t automate the boring stuff because they focus on what they know rather than experiment with trying to do something faster. They seem to want their automation done for them. My question for everyone, then, is how do we motivate more programmers to be more creative in increasing their own productivity?

Measuring the success of software projects

In measuring software project success, many companies use two relatively simple metrics:

1.        Is the project on time?
2.        Is the project on budget?

Both of these are easy to measure, and we measure them in part because both of these are more difficult to achieve than we’d like.  However, neither of these two measurements gets at the heart of what makes a typical software project truly successful.  There should be one primary thought driving any software project that stakeholders on all sides should use to determine its success:

Does my project deliver more business value than the cost of building it?

Your end goal should primarily be delivering business value, not meeting a budget.  I’ve been involved in projects that didn’t meet time or budget limitations, but were still a business success because they delivered the promised business value, allowing for company scalability, greater market visibility, etc.  I’ve also been asked to rescue projects that were a success in terms of meeting time and budget, but failed miserably in providing the desired business value.

So why do many of us still focus on time and budget as primary measurements for software project success?  I think largely because they are easy to track and measure.  Determining ROI requires knowledge of the current costs and revenues associated with the current process, measuring and calculating all costs associated with development, and measuring the improved costs and/or revenues due to the end product.  Separating costs and revenues due to software only and those generated from other causes (marketing efforts, efficient or inefficient workflows, etc.) can be nearly impossible.  Pair this with the thought that software projects are ends to themselves and time and budget become more important measurements to project success than they should be.

The alternative requires either a strong project champion that is able to understand all of the costs and revenues from both the business and implementation sides or close collaboration between the business and implementation leaders to determine proper measurements of success.  Neither of these is common or easy to accomplish.  To get an idea of what I mean, here are a couple examples of better measurements of project success:

• A new internal document tracking system’s success might be measured by increased productivity and worker satisfaction
• A new content management site for a professional services company might be measured by the number and quality of unsolicited sales leads

Have any of you tried to measure project success more along these lines?  Did it work?  Why or why not?

Skills vs. Knowledge (and how it affects unemployment in IT)

If you troll the job board discussion groups targeted to IT professionals, you’ll see a large number of seemingly qualified, out-of-work technologists.  With an unemployment rate hovering near 4.5% in the industry, how is this possible?  After looking at the openings and the unemployed, I think the answer is fairly simple:

Employers are actively looking for skills, but employees want to emphasize their knowledge.

What do I mean?  By “skills”, I’m talking about technology-specific things that could easily be read in a book.  Being able to build a custom control in ASP.NET or being able to bend Entity Framework to create much more readable code are “skills”.  Being able to determine when it is appropriate to build a custom control, or when one should choose to abandon a framework rather than continuing to bend it would be “knowledge”.

The difference is subtle, but important when dealing in technology because the skills a developer needs to write custom solutions change quite frequently, but the knowledge does not.  Since this is the case, employees often want to market their knowledge and expect employers to train on skills, which is rather foolish.   Employers, on the other hand, do not wish to spend resources training for skills, but incorrectly think that knowledge is unimportant (or at least not worth paying for).  And so you get this strange combination of thousands of seemingly qualified IT professionals looking for jobs in a market with thousands of openings.