February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox
March 22 - 25 - Tutorial on Modular Architecture
June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture
July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.
Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29
The opinions expressed on this site are my own, and not necessarily those of my employer.
Often times, I hear folks exclaim that they’ve been on “40 development projects over the past 10 years.” Or, “70 projects spanning a 20 year career.” They say this as if it’s some badge of honor. But I’m not so sure that it is.
Of course, there is value in widespread project exposure. Gaining experience with new technologies. Experiencing the dynamics of different teams. Understanding the challenges surrounding different organizational cultures. Each project is unique, bringing its own set of experiences, and these experiences are all incredibly valuable.
But when I see that someone has jumped from one project to another, it also leaves me wondering! Have they ever stuck around long enough on any single project to see their decisions through to the end? Have they ever had to live with the decisions they’ve made? An amazing compilation of knowledge is obtained by not only participating in the early stages of development, but also in maintaining the software system after it’s been released. To name just a few:
And there is so much more. Priorities tugging you in five different directions at one time. If you’ve had the luxury of living with a system (and the mistakes) you created, you’ll realize that there are very few, if any, decisions that shouldn’t be given conscious thought.
When an individual sticks with a project for a long time, they realize the importance of maintaining a clean design, a robust suite of unit tests, and how they package their software system. There is significant knowledge gained by sticking with a project for a long period of time. Perhaps the next time you hire a developer, it might be wise to ask them, “What’s the longest you’ve spent on any given project?” That may be more important than the number of projects they’ve been on.
Somewhere along the way, I picked up a small piece of advice that has helped serve as a valuable guide. There is a big difference between ten years of experience and one year of experience ten times. When you jump from project to project, never living with the decisions you’ve made, you have lost an opportunity to learn what works well and what does not.
I’ve owned Macs for about four years now. I use them daily. One of the biggest complaints I hear surrounding Macs is that they’re more expensive than their PC counterparts. This recent article in CIO examining total cost of ownership (TCO) for businesses using Macs left me wondering. For personal use, are Macs really that much more expensive than PCs, especially when factoring in TCO? Unfortunately, it’s not so black and white. Let’s look at some numbers.
For this little exercise, I’ve decided to compare sample TCO over a period of time (ie. 2 years) for a Mac and a PC. This includes the initial purchase cost, ongoing support costs, and software purchases. It does not include any personal time that you would need to devote to maintaining and managing the device, such as reinstalling the operating system, cleaning up unused applications, dealing with anti-virus software and configuration, and general troubleshooting tasks.
I’ve made my most valiant effort to present an unbiased view and have arguably given favor to the PC. It would have been easy to close the price gap much more quickly if I were to toss in a few not-so-easy to measure items, such as the likelihood that you’ll have to take your PC to a professional to have it saved. But I’m sticking with hard numbers; the stuff that’s easy to measure. Let’s get started.
I picked two models, fairly equal in their capabilities - a Dell Inspiron 15 and a 15″ MacBook Pro. When purchasing the Dell, I had to configure it so it had specs equal to the Mac. Let’s look at purchasing and configuring the Mac first.
The MacBook Pro
The 15″ MacBook Pro we’re going to purchase comes already loaded, so we aren’t going to make many customizations to it. We’re going to go with the entry level model, which prices out at $1699. The general specs include a 2.53 GHz Intel Core 2 duo processor with 4 GB of RAM. All we’re going to do is increase the hard drive to 320 GB, which adds $50 to the price, and purchase iWork, which adds $49 (Pages, Numbers, and Keynote). For those not familiar with iWork, this is what we’ll use on the Mac instead of Microsoft Office.
Total price for the MacBook Pro: $1798.00.
The Dell Inspiron 15
Keep in mind that the Inspiron is under Dell’s “Home” category. What this generally means is that it comes pre-loaded with a whole bunch of useless trial software that expires in either 30, 60, or 90 days. After that initial trial period, you’ll have to purchase a license to continue using it. For a business, you’d probably purchase the Latitude to avoid all of this unnecessary garbage. To keep the price down, I’m going to go with the Inspiron 15. See…told you I was giving favor to the PC!
To get a somewhat even comparison, I’m going to have to customize this thing to bring it up to equal specs as that of the Mac we’re going to purchase. The initial cost of the base machine is $499. But without any further customizations, that machine doesn’t offer much horsepower. First, I’ve got to add a Core 2 duo processor clocking in at 2.53 GHz. This adds $225 to the price. We do need the wireless -N card, which adds $40. Why would this not be standard? Odd!
Next is Microsoft Office Home and Student 2007, which adds $119. We need this if we want to create spreadsheets, documents, or presentations. I recognize I could have gone with OpenOffice, but I find that most people choose Microsoft Office, so that’s what I’m doing here. Since we’re running Windows, we need anti-virus software. With the Dell model, there’s an option to purchase a 36 month license of McAfee. I’m going to jump on that because it only adds $40 to the price.
At this point, we’re finished with the Dell. There are a few things we could have done to even out the playing field a bit more. For an additional $45, we could have upgraded to the 9-cell battery that would have given us up to 8 hours of battery life. Keep in mind the Mac has a battery that gives us about 7 hours. Additionally, the version of Microsoft Office we purchased doesn’t come with Outlook, so we’ll still need to find an e-mail client once we get our laptop. But I just couldn’t see spending another $160 to purchase the Small Business edition that comes equipped with Outlook. The Mac will have Mail.app preinstalled for us, which is a nice e-mail client with Exchange integration. Already, the cost of software licensing is a sign of things to come that’s going to factor heavily into TCO.
Total price for the Dell: $883.
While these are each good machines, to get great things done requires software. Each of us have different needs surrounding the software we use, so I’ll offer up a few samples based on what I use. It won’t take long to get a clear understanding of the significant impact this has on TCO. Choose your own software stack, and see how it adds up. Then, let me know if you’re findings are consistent with mine.
First, I want to purchase software that allows me to create some nice drawings. For the Mac, I’m going to purchase OmniGraffle, which comes in two versions, standard ($99.95) and professional ($199.95). For Windows, Visio is a good option, which also comes in two different versions, standard ($259.95) and professional ($559.95). Let’s go the cheaper route on each. This brings the total price for the Mac to $1897.95 and the price of the Dell to $1082.95. Note: If I had purchased the professional version of each, the TCO at this point would be 1997.95 and 1382.95, respectively.
Next, I want some screen capture software so I can create some short training videos for online publication. For this, we’ll use Camtasia. The Mac edition of Camtasia prices out at $99.00, and the Windows version comes in at a rather lofty $299.00. TCO for the Mac is now at $1996.95 and the Dell is at $1381.95.
See a pattern developing here yet?
Keeping this post at a reasonable length, I’m only going to make one more purchase. At some point throughout my time as owner of one of these wonderful products, it’s likely that a new version of an operating system is going to arrive. And I’m going to want to upgrade. When Snow Leopard for Mac hit the market, the cost to upgrade was a paltry $9.95. Alternatively, the price to upgrade to Windows 7 Home Premium comes in around $119.95. In fact, a full license of Snow Leopard is only $29.95. A full license of Windows 7 Home Premium? $199.99! Again, the pattern is developing. TCO for the Mac is now $2006.90, while the Dell is at $1501.90.
At this point, the Mac is still slightly more expensive. But an initial price difference of $1200 was quickly dwindled down to just over $500 by the time we were finished. Clearly, the stark difference in the initial price is quite different from TCO. I could easily keep going, purchasing software that I want and need, and each time find that the Mac edition of the software comes in priced far below the Windows version. But I think I’ve illustrated the pattern here. The cost of software for Windows is more expensive than corresponding software for the Mac, and throughout the lifetime of ownership, TCO for Windows will approach, if not exceed, that of the Mac. For instance, Apple offers the option of purchasing a 5-license family pack of iWork for a mere $20 more than a single copy. A 5-license copy of Office is going to be quite expensive ($595).
Additionally, I have not broached the subject surrounding the time you’ll spend maintaining the Windows machine to keep it running smoothly. In four years on a Mac, I haven’t devoted any effort to tuning the machine for performance. It just works. After about six months on a Windows machine, I find that I’m always tinkering with it to maintain optimal performance. Since I can’t put an accurate price tag on this, I haven’t discussed it. But it is significant. Ok, I’m a little biased here, aren’t I?
Finally, I could have gone with the 13″ MacBook Pro with the exact same specs (just a smaller display) as the Inspiron 15 for an entry price of $1448.00. And the 13″ Mac is a great machine. After purchasing the software I want, the price for the 13″ Mac comes to 1656.90. That’s only $155.00 more for the Mac!
The winner…you decide! All too often we compare Mac and PCs based on initial cost, failing to factor in the longer term TCO. When comparing Apples-to-Apples (errr…I mean PCs) though, the difference isn’t as stark. If you want a low end machine with a short lifespan, Dell (and many other PC manufacturers using Windows) offer this, including their line of netbooks.
It is possible to purchase a Dell for under $500. But remember, you get what you pay for. And side-by-side, machines of equal horsepower and capability are going to result in similarly equal TCO. By the time you spec out the machines evenly, and factor in TCO, the price of a Mac is arguably equal too, if not less than, that of a Windows PC. Either way, I know what my choice is!
Last week at OSGi DevCon, I attended Peter Krien’s Advanced OSGi tutorial. The tutorial focused on OSGi services, and I had just come off a rather lengthy e-mail discussion with Peter on a similar topic. So this was pretty good timing. I want to share with you one aspect of the discussion, and its relationship to architecture. It’s quite simple, though makes an important point.
In the past, I’ve talked about the importance of designing the joints of a system. OSGi services represent these joints, since services are essentially a module’s published interface. In general, if the implementation details of a module are well encapsulated, then implementation details can change without impacting the rest of the system. In other words, we minimize that nasty ripple affect of change if we confine change to a single module. But changes that span modules is nasty. Let’s take a few visuals to illustrate the point here.
Commonly, we visualize the module structure of a software system using a simple diagram similar to what’s shown at right (click to enlarge). We see the modules and the relationships between them. Of course, the relationships between modules represent the joints. Pretty simple stuff! Unfortunately, our attention is immediately drawn to the modules themselves, but not so much the joints.
And we really must be much more concerned about the joints than we are the implementation details because changes in the joints of the system are more complex and costly. This is where we need flexibility and it’s also where we need stability. Emphasizing module implementation is important, but flexibility in the joints is more important.
In the session, Peter annotated the diagram using a new convention, which I’ve depicted in the diagram at right (click to enlarge). The red triangles more clearly illustrate the joints. Here, our attention is drawn more toward the design constructs that span module boundaries. No longer is emphasis placed on the implementation details, but instead has moved to focus on the relationships between the modules. And the direction of the red triangle also helps illustrate the direction of the dependency relationship between the modules. In other words, these red triangles are the services.
Now, because the module itself represents behavior that is encapsulated, we can remove the modules from the diagram altogether and show only the joints, as shown at right (click to enlarge). This is where the impact and cost of change is most significant. And this is where we really need to ensure we have the greatest flexibility. These are the decisions that are most architecturally significant.
Now I don’t think it’s necessarily important to start drawing architecture diagrams this way. In fact, I’ve never felt that it’s critically important to draw these pretty diagrams in the first place. While diagrams (and documentation) can be useful, they are little more than a pimple on software development’s ass. There are much more important things to worry about than diagrams. But I digress, and in general, this simple exercise helps recognize the importance of designing the joints of the software system.
Of course, while this example illustrates the point using modules, it’s not just the joints between modules that are important, but the joints at many different levels of the system, including applications, services, packages, and classes. In other words, the point where two entities connect is where the real architecture lives.