About this blog
In my twenty years of software development (yikes!), I've come to appreciate a few things:
- Everything changes, all the time. Technology, requirements, companies -- you name it. Any attempt to hold any of this stuff constant is just about as useful as trying to nail snot to a tree.
- If you can't explain something in simple terms, it's too complex. You need to go back and study it until you can figure out how to make it simple.
- Software developers and business leaders alike value employees who defy points 1, and 2, not because they can change them (they can't), but because we really, really wish they could.
If you're thinking that this is clearly proof of a buggered-up industry, then Congratulations! You're ready for this blog.
Lex Parsimoniae is Latin for "Law of Parsimony", or the law of greatest simplicity. Many people are more familiar with the related principle of Occam's Razor, which applies Lex Parsimoniae to the evaluation of hypotheses (the simplest explanation is usually right).
I believe that Lex Parsimoniae applies to software, too. We have at our disposal today more tools and techniques than ever before in the history of computing to achieve wondrous abstraction and elegance. Despite this, we churn out copy-and-paste spaghetti at an alarming rate. We build systems that even their authors can't comprehend. We unleash these systems on an unsuspecting public, and we react with surprise when that public pans our work.
As with any deeply-rooted dysfunction, the first step to fixing this problem is to create awareness, so that's where we start.
About the author
I'm David Lambert. I've been developing software for around 20 years, so I've seen a lot of great ideas come and go, and in most cases, come back again. I consider this perspective to be an asset.
I started my career with just enough mainframe development experience to appreciate the good, the bad, and the ugly of greenbar source code listings. Although the tools were crude, I learned an awful lot about process from my first position with a little insurance company in Oshkosh, WI.
My first experience with commercial software development was at a phone company, where I was hired to build a cutting-edge phone bill reporting system (ok, but it was cutting edge back then....). The best parts of that position were working with some really outstanding people, and the chance to experience a form of shrink-wrapped product. We sold the tool I wrote, and I got to experience genesis, growth, extension, maintenance, support, and troubleshooting on a platform that people were paying real money to use. It was a rush.
Since then, I spent some time implementing CRM systems for a small consulting company, which led to the chance to build another software product and team. This product was a Business Rules Engine (BRE), and along with the challenge of growing that product, I learned a lot about the financial aspects of growing a startup organization.
Today, I'm an applications architect for a local consulting company, implementing .Net solutions for Columbus-area clients.
Your page layout and style is very elegant. Do you have any advise regarding BR engines? We are considering developing our own, but…