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.
