Assumptions and their impact on software development

The rhetoric we usually hear about assumptions is that they "make an ass out of you and me". But I've heard another one that I think is more fitting in a lot of circumstances: assumptions are the mother of all fuck ups. This was proven beyond a doubt today when a vendor professed to us in a meeting that he had made certain assumptions about our product and that he would now need much more time to take these new 'facts' into account.

It's funny the way facts and assumptions work. For most, an assumption is a fact until it is proven otherwise. This is especially true in software design where there are so many variables that to take them all into account can cost an exorbitant amount of time. As such, programmers tend to focus only on the big ones leaving the smaller assumptions to sort themselves out. This can and often does spell disaster for large projects.

One of the ways to help minimize such dangers, besides increased communication between team members, is to decrease the complexity of a project. Remarkable advances have been made in software development to facilitate code testing without sacrificing budget, time or scope. On the Java side, I've been hearing great things about JUnit from my friends. But unfortunately for J2EE development, overall complexity still remains a huge hurdle to overcome, even for small to mid-sized projects.

Enter Ruby on Rails. This is the most ambitious project I've seen to date to try to tackle the problem of increasing complexity and overhead with regards to web application development. I've worked in many languages over the years: Perl, ColdFusion, PHP and Java just to name a few. When I saw what Ruby was capable of I didn't believe my eyes. But after I installed it and had a web application running in under 15 minutes, I knew that this was something big.

So many of the modern web application languages available today require assumptions to be made. Configuration settings, typically stored in large and difficult to read XML files, are assumed to be static but RoR makes no such assumptions. Using inspection and reflection, Ruby can change its configuration settings at runtime so that changes made to a database structure are promulgated to the application itself without having to do the reconfigure, recompile and redeploy dance so many J2EE folks have gotten used to. And most important of all, less assumptions equals less fuck ups.

Today is the first day of the rest of my web development life. I had two books waiting for me when I got home and I can hardly wait to crack them open. So after I sign off here I'm off to dive into my new RoR books. Look for more articles here on this subject as I learn about this amazing new framework.