At JTeam, we continuously strive for good quality code. The reason is very simple: bad quality code slows down the development process. The small investment pays out in even the simplest of projects.
Measuring code quality is not a matter of a single metric. Instead, software quality has many aspects, some of which can be captured in metrics. Those metrics can be nicely assembled within a single application, which gives a nice overview of the state of an application: Sonar.
Nowadays, companies are hardly ever satisfied with a mere web-presence. No, websites have become true applications in their own right. Instead of being a by-product, most businesses acknowledge that the web offers them a nice channel to do business. However, the demands from the business keeps growing as each company want to be better than its competitors.
The increasing demands from the business have a direct influence on the applications complexity. Each time, especially when joining external projects, I am amazed by the way complexity is dealt with in most applications. “Building software isn’t rocket science”, but sometimes we do seem to make it just as complex.
In this article, I provide some insight in different forms of complexity, and how software development teams can design their application in order to deal with the ever growing demands from the business.
In a recent project for Osix, we developed an application allowing visitors of a library to use the wireless Internet connection available there. Visitors can pay for the Internet access in two ways: an online payment, for example using a credit card or by deducting the amount from their library account. All user accounts, as well as the available products, library configurations and payments are managed from a single central application, called Digital Services Manager.
In this post, I will elaborate on how Domain Driven Design has helped us build a clean and maintainable application, mainly focusing on some technical and implementation choices that we have made.
In 2002 I started JTeam and while at first managing our email accounts with the tools we got from our domain hosting provider, we settled for a Microsoft Small Business Server (with Exchange) somewhere in the beginning of 2003. Dell back then had this offer whereby you’d get the machine practically for free if you bought an SBS license (I could have been the other way around, I can’t remember anymore).
From say 2002 to about 2007, we’ve only had the occasional Linux user and hardly any Mac users, so the fact that Exchange is not a decent cross-platform solution really wasn’t too big of a deal. Lately however, we are starting to get more people that prefer an OS X or a Linux environment. Now I wasn’t aware of that, as I was working for SpringSource the past 4 years, so in fact, I couldn’t care less 
. But… as you may have heard, I’ve quit my contract at SpringSource and for the time being I’ll be at JTeam (more on that later by the way). In other words (since I am a Mac user), now all of a sudden I *do* care.
According to this excellent blog entry by there is no decent solution for synchronizing Exchange calendar information with Apple iCal.app and from what I’ve heard, the situation is exactly the same for Linux users. For the OS X user the wait shouldn’t be long anymore, since Snow Leopard is on its way and this version of OS X includes Exchange support. For Linux user there is no native solution that I know of.
In the meantime, several people have figured out workarounds that (literally) work more or less. I believe there’s somebody that maintains his schedule in a Google Calendar, is able to send out meeting invitations and also able to accept and reject meeting requests, but his Free/Busy time is not available in the Exchange calendar. There’s also somebody that just has everybody call the office manager to schedule an appointment (that somebody would be me). It all works… but more often less than more…
This lead me to think we should search for a more permanent solution. One that cross-platform, doesn’t require any more maintenance than a full-fledged Exchange server (mind you: we don’t have do a lot of maintenance on it at the moment).
Systems administration is not a task I like particularly well (and it’s also not what I’m going to do at JTeam on an ongoing basis), but I’m guessing it’s going to make a lot of people at JTeam very happy if we get this sorted out, so why not get it out of the way then. I’ve spent a little time looking for solutions and finally settled for Google Apps. For now for email and calendaring only. Maybe in the future also documents and more.
In the next few weeks, we are going to try Google Apps out with a test domain and hopefully by the end of March, we’ll have a final decision on whether or not Google Apps is going to be the new email and calendaring solution.
A little bit of background on the reasons for this change. The most important reason for it is that I think for a software development shop of about 25 people, I don’t think it makes sense anymore to manage all kinds of internal systems for things like email and calendaring. Yes, in the past, when no alternative (such as Google Apps) were available maybe, and maybe if you’re a very large organization… But these days, it makes sense IMO to focus as much as possible on what you’re doing best and at JTeam that’s software development, not systems administration (ah, so now I’ve revealed that we suck as managing systems?? ). A second big reason is spam. We’ve been fighting the spam problem with relative success, but Google seems to do a much better job at getting rid of spam. The last reason might maybe be cost-related, but that’s definitely not the main reason. Yes, I do believe it’s going to be cheaper in the end, but that doesn’t matter too much. The other reasons are way more important.
Concluding, it sounds like all is geared towards getting people to focus more on what they do best and get stuff that doesn’t matter (deleting spam, calling up office managers to schedule appointments, managing useless systems) out of the way.
I’ll report back with some findings later on.