Job Change

Just to let folks know, I changed jobs this spring. The bank has been good experience for me as a developer, but I wanted to take my career a different direction. I took a position with a "mature" web start-up company closer to home.


My family has also grown by one, and that prompted a change to make my commute shorter.


I've been away from the blog for a while, but I do plan to get to some regular posting soon.

New Feed

I'm redirecting my feed to Feedburner.com. Please subscribe here:
http://feeds.feedburner.com/BusinessOrientedDevelopment

More content to come soon!

Ice Storms, Power Companies, and Project Estimation

Rob, a coworker of mine tagged me to come up with an example and confirmation of Agile development principles in real life.

To be fair to the business world outside of software development, most of the Agile software principles existed in the "real world" in various forms long before they were expounded by Agile proponents. But it's nice when you do observe the real world confirming an agile principle you have worked to implement in a team software environment.

Recently, a massive ice storm knocked out power to a large portion of the mid-west. The resulting damage in my community caused power outages to over 50% of homes and businesses. If you have ever lost power for an extended time period in sub-freezing temperatures, you understand the importance of electric power for the necessities of life. And when that power is lost for multiple days, it becomes a really big deal.

Even though the situation was not humorous, I had to laugh out loud when I heard the power company's estimate for restoring power in our area: "We hope to restore power to this area in 2 to 10 days."

It wasn't a mocking laugh or a laugh of ridicule. I laughed at the brutal honesty of the project estimation. I laughed at some of my past software projects where we probably knew less about our project requirements than the power company, but gave a more feature-rigid and date-rigid estimate.

Every subsequent morning, the power company was on the radio giving their revised project estimates. 2 to 10 days became 6 to 8 days, the next morning it became 4 to 5 days, and the morning after it became 2 days. Since it was impossible to really know on the first day the extent of the work to be performed, the power company didn't provide a wild guess. They effectively worked in daily iterations, revising their estimate as they worked. Since electric power is so critical during cold weather, they didn't have the option to guess on day one, and find out 4 days later that it would take longer than expected. When it comes to electric power, there isn't any room for salesmanship, PR spin, or blatant bluffing.

Agile software development allows us to take the same measure-by-doing approach. Instead of spending large amounts of time designing and estimating at the beginning of a project (which often ends up being mostly a guess anyway), we can start working in short iterations and revising estimates as we progress. By the second or third iteration, there is enough real-world data to chart out a reasonable projection of when the whole project will be completed.

So, can the software world learn something from a utility company? Yes. Estimate by doing. And if it is important, there is no room for guessing, bluffing, or wishful thinking.

On Being a Business Developer

What does Business Oriented Development mean? This isn't a comment on software development methodology, but rather a comment on the orientation of the individual developer. On one level, business oriented development sounds like a catch-phrase ready made for stating the obvious. Unless you are working for an academic institution or just write software as a hobby, you normally think of yourself as oriented toward the business. That is your customer and employer after all.

But beyond just paying homage to the person or institution that writes the paychecks, software developers generally fall into at least two distinct camps. Some write software for a living because they love technology for the sake of technology. Others, like myself, like technology for its incredible potential to solve business problems.

This is how I hope my site will differ from the standard blogger fare. Sure, I'm a geek. Just ask my wife. But I am a businessman first, technologist second. In my worldview, one exists to support the other, but not vice-versa.

You will not see a ton of code posts here. Its not that I don't think code is important. It is. But in my opinion, the practice of coding is really only a fraction of what constitutes a quality business oriented software developer. Besides, there are plenty of uber-geek software blogs out there. Not that I have anything against software uber-geeks, many just have significantly different view of technology (geek-first instead of business-first).

I recently found a very telling statement on the popular "Worse Than Failure" site by Alex Papadimoulis. In a very curious article (more on that in a later post), Alex states that software developers don't like writing business software:

No One Likes Business
When it comes down to it, us software developers don’t like writing business software. It’s terribly, mind numbingly boring. Just look at the dreadful specs we’re given to work with: When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.

In my experience, this statement is only half right. It's true, a large number of software developers are not fond of writing business software; these are the geek-first types. I beleive I represent a significant number of software developers who actually enjoy writing business software. I get my charge solving difficult business problems through working software. I am excited when a business user realizes x times their old productivity standard by using a new technical solution designed and implemented by my team.

I do not get very excited about solving abstract logic problems for the sake of solving problems. In my spare time, you probably won't see me reading this, but you will catch me working on my own software projects. For enjoyment, you won't see me doing crossword puzzles, but you will catch me playing chess or poker.

So, for me, it's about having a result that matters. That is my not-so-geeky approach. That is what I call Business Oriented Development.