I’m a Mac-PC

For the last couple of months, I’ve been using a MacBook Pro (17″/2.6 GHz/4GB) as my primary machine. My workload is pretty diverse, from basic browsing (although these days “basic” browsing doesn’t have much surface area) to email to fairly heavy Excel/Powerpoint usage to development.

Here’s the thing: I split my tasks between Mac OS and Windows Vista under Parallels. Here’s the breakdown:

1. I do browsing almost entirely Firefox 3 under Mac OS. Occasionally IE 7 under Windows for intranet applications that require it.
2. I read personal email using Apple Mail and do corporate email using Outlook. I tried Entourage and I wanted to hurt myself after a very short time.
3. I run Excel/Word/Powerpoint under Windows. Once in a while I’ll use the Mac versions, but I find them particularly hard to use on an infrequent basis (mostly due to different shortcut gestures).
4. Development primarily in Visual Studio 2008. I’ve been doing some Ruby and Python on the Mac side, using TextMate. I’ve started using E, a TextMate-like editor under Windows, after a long run with UltraEdit, mostly because it has the same Python-based extensibility model as TextMate – although this advantage of this is mostly theory at this point. (As an aside, I’ve also been working with IronRuby and IronPython to take advantage of dynamic language capabilities with .NET; my good friend Harry Pierson is a Product Manager with the DLR group, focused on IronPython.)
5. I do notetaking mostly in VoodooPad on the Mac side, but this is a recent switch from OneNote, which I have a lingering love for. I had a brief tryst with EverNote (which is nicely cross-platform), but I couldn’t get comfortable with it. (And I really dig the plug-in model in VoodooPad, another reason I’m learning Python.)
6. I run MindJet‘s MindManager under Windows for brainstorming and organizing my thoughts. I haven’t sprung for the Mac version yet (another $349 – ouch – and also a version behind), but I’d love to have this in both environments.
7. I write blog entries using Ecto under Mac OS. I like LiveWriter, but haven’t used it much lately.
8. When I do UML, I usually use Altova‘s UModel (which I bought as part of their Mission Kit for Software Architects) under Windows, but this is pretty infrequent – not because I have anything specifically against UML, but mostly because I haven’t had the energy to devote to getting it accepted around here.)

So why put myself through this? This is a complex environment to live in – mostly because of the different UI paradigms in the different environments: just try training yourself to type Ctrl-A to go to the beginning of a line and Command-A to select all under Mac OS and Home/Ctrl-A for the same pair of actions under Windows. There are some integration challenges – clicking a link in an email on the Windows side opens Chrome, but whatever; Parallels makes sharing files between the environments easy, at least. I do use Dropbox as well to keep files in sync between different machines, including my host Mac OS and my guest Vista instance.

First off, this setup works for me – the Mac goes to sleep and wakes up faster than I’ve ever seen a PC take a nap (and can do so repeatedly without losing its mind), the whole thing is very stable, I can segregate resource usage by Windows applications, and I have the best PC and Mac applications to draw from to get my job (and life) done. I can snapshot my Windows environment with a single click, and Time Machine makes sure I have ongoing backups of the whole shebang.

Second: I have to run Windows because we’re a Windows development shop. But even if I didn’t have to, I still would. The things I do in Windows, Windows is best at. Arguably, some of the stuff I do under Mac OS would be better under Windows too.

The third, and most concerning reason for doing this is that I think I’m a complexity junky: I seem to enjoy managing all of the minutiae and training myself to work in the split environment. Whatever.

So, I’m a Mac-PC. I’m proud to not have any serious technology religion, and instead to use the best tool for the job at hand. There’s a price to pay, but I’m wiling, at least for my personal setup (i.e. this isn’t an enterprise strategy :-).

A few sizes fit most…

Don’t you love it when you think of things to blog about at 3AM… I guess I would have preferred to be asleep, but having a (hopefully) interesting blog post idea is a reasonable second choice.

Let me start by saying that I’m focused in this posting on organizations of a “certain” size – say bigger than 50 developers. I’m not talking about small companies. I’d offer a pretty much totally different set of thoughts and opinions for that kind of organization; I’d even go so far as to say that a small company has the responsibility to pretend that there’s nothing to see here, and should get back to getting product out the door.

So, standardization. It’s an idea that management loves. By management, I mean people that are primarily focused on large-scale organizational planning and budgeting, rather than on the specifics of executing projects. Perhaps a fuzzy line, but bear with me. Management loves standardization because you can make arguments like: “if I only have one {platform, language, pattern, keyboard, kind of chair, brand of monitor} to worry about, I can get more out of each precious dollar.” To an extent, this is true. Unfortunately, it deprives us of the opportunity to leverage something special – i.e. non-standard – when that special, non-standard thing could make my problem much easier to solve or help me get my project done that much sooner.

Sometimes this tension surfaces as an organizational allergic reaction: you’re killing my innovative spirit, man! Let me be to use Jimbo’s Foobarilicious Language #4, v.001alpha, it’s the coolest thing ever and I’m going to get my project out the door in a week and a half! But seriously, it’s probably just “I know the company standard is Java, but why can’t I use .NET?” Or, “I have tons of experience with Python and Django, why do I have to write this greenfield web application in ASP.NET?” Good questions.

Both sides of this argument have good points: there’s a lot of advantage to be gained by avoiding unnecessary or inappropriate proliferation of technology. It makes organizations more agile, because more people can work on more pieces of the puzzle, assuming that we’re not all capable of really, truly, being effective on more than one or two technology platforms at a time. However, getting painted into a technology corner makes companies more susceptible to crustification – getting rigid and boxed-in, while the technology train rolls on.

How to reconcile? It doesn’t take much to reach the simple conclusion that one-size-fits-all isn’t the answer. Even if you have the luxury to focus on a single, uniform technology environment, you’ll eventually get to a crossroads where you have to face the tension between following a standard or taking on a new approach. I should make the point here that this isn’t always a macro concern – it comes into play at the micro level in the context of design patterns, naming conventions, tool selection, and so on.

My answer is to find “a few sizes that fit most”. That is, figure out what classes of solution (that’s purposefully vague) can respond to the needs of your business, make informed choices about adopting a small subset of these solution classes that cover most of the needs, and be prepared to have exceptions sometimes. In my experience, this approach manages to strike a balance between unbounded technology proliferation and over-constrained standardization on too few solution options in a given problem domain. I’ve had good success with applying this approach in large enterprises by standardizing on a single technology platform for all customer-facing (maximum reach) applications, another for backend transactional systems and a third for internally-facing (maximum richness) applications. There were exceptions, but they were identified and managed explicitly; this explicit management gives us some leverage over the problem of managing the solution portfolio, so we can avoid getting painted into a corner over the long term.

UPDATE: This morning, while waking up (apparently when I do my best free association), I realized that I started talking about some of these ideas during a panel at OOPSLA 2003!  Unbelievably, I also found a long-forgotten blog I wrote about it; unfortunately, the link to my notes is broken.  I’ll try to track them down.

UPDATE: I found my notes from the OOPSLA panel.

A convocation address

I thought I’d share a short speech I gave when I was awarded an honorary doctorate last summer from Algoma University College, in my home town of Sault Ste. Marie, Ontario, Canada (that’s here). People generally ask, “why the heck did you get an honorary doctorate?” Fair question. I was as surprised as anyone, but certainly very honored. That’s pretty much all I have…

This was delivered as a convocation address to about 400 faculty, students and their families. This is the raw text of the speech, warts, embarrassments, misconceptions (in retrospect, many months later) and all.

---

Graduates, distinguished faculty, ladies and gentlemen, thank you for the opportunity to spend a few moments addressing you today. Drs. Ross, Woodsworth and Perlini, and to the Algoma University College Board of Governors and Senate, my sincerest thanks for this honor.

I am truly thrilled to be recognized in this way at the institution at which I first recognized my passion and took the first step in my career. My passion and my career are technology. The bad news for you is that technologists … let’s face it, geeks … aren’t known for their speech-writing skills. So, I’ll keep this brief.

The start that I got here at Algoma University College was thanks to Dr. Michael Keppel-Jones. And it’s thanks to him that I’m here today. Dr. Keppel-Jones coordinated a Saturday morning computer class; I was 11 or 12 when I joined and became fast friends with Dr. Keppel-Jones’ son Stephen. And it was thanks to Steve that I decided, years later, to pursue a degree in computer science at the University of Waterloo. Although I’ve been in the United States for several years, I’m extremely proud to say that a key enabler that allowed me to capitalize on each opportunity with which I was presented is the education I received in Canada. This education provided the theoretical and practical foundation that allowed me to take the rich, varied and challenging course I have.

That course took me to some interesting places: from my start as a software engineer at Nortel, to my time at the Software Engineering Institute at Carnegie Mellon University, through the dot com bubble in Silicon Valley to AOL, Microsoft and now to Fidelity Investments. Each opportunity presented a different set of challenges, technical, cultural and organizational, and each provided a learning experience that shapes my perspective on striving for and achieving goals.

Some environments, like the startup companies I’ve cofounded, gave me the entrepreneurial perspective – the perspective that fosters a desire to take your destiny into your own hands, to shape your own direction, and to accept the risk that comes with that ownership. Startup companies can be extraordinarily rewarding – and I’m not just talking about the rare windfalls characteristic of the dot com bubble. I’m certainly lucky to have been able to participate in that bubble, but the most important rewards were not financial – they were the ones that came from working hard with close-knit teams to make a vision into reality. To deliver a product that I could be proud to say I had a part in.

The other end of the spectrum is the large enterprise. I’ve been part of several. Each of these comes with its own particular set of challenges, including the obvious technical ones, but also its own unique set of cultural and organizational trials. Of course, these challenges always represent opportunities and the potential for significant personal and professional rewards. The trick is turning the former into the latter.

I am frequently asked how I can make the transition back and forth between startups and large enterprises; I wish I had an answer that had some practical value, but unfortunately I don’t think I do. I think it’s simply that I find aspects of each type of environment to offer a different set of opportunities to which I can apply my experience, but with a core of commonality – the practice of technology.

When I get frustrated with the ponderous bureaucracy characteristic of large enterprises, and long for the hopeful, entrepreneurial and innovative environment of a startup, I lean on a set of principles that try to bring the spirit of a startup, through the actions of individuals with dreams and drive, to any organization. Until recently, I didn’t know these principles have a name – intrapreneuring. Intrapreneuring is an idea initially formulated by Gifford Pinchot in the 70s, and is based on the idea that anyone can innovate, be entrepreneurial, within a corporate environment. Mr. Pinchot described ten commandments to be followed by the intrapreneur:

1. Come to work each day willing to be fired.

2. Circumvent any orders aimed at stopping your dream.

3. Do any job needed to make your project work, regardless of your job description.

4. Find people to help you.

5. Follow your intuition about the people you choose, and work only with the best.

6. Work underground as long as you can – publicity triggers the corporate immune mechanism.

7. Never bet on a race unless you are running in it.

8. Remember it is easier to ask for forgiveness than for permission.

9. Be true to your goals, but be realistic about the ways to achieve them.

10. Honor your sponsors.

Let me clear – I don’t suggest any of you go out and aim to get fired – this isn’t a lecture on subversion. But these principles can help us all as we work within established organizational paradigms to strive for something bigger, to bring an innovative spirit to every endeavor.

A challenge I’ve had throughout my career is explaining what I do to anyone that’s not a technologist. When I say “I’m a software engineer”, I usually produce more confusion than clarity; when I say “I do software architecture”, I usually face blank stares. When I began my career, software architecture was still an emerging discipline struggling to become mainstream. Software architecture is concerned with the principles that make software possible, particularly when software needs to achieve large scale in terms of scope, team size, user population, complexity and longevity. Many try to reason about software architecture by analogy with building architecture, but I generally find this a flawed approach. Software isn’t like buildings.

I thought I’d share with you part of a fictional letter that a building architect might receive if building architecture was like software architecture. For the new software engineers among you, you may find this a sobering truth. For the rest, you may achieve an appreciation of the challenges we face in software every day.

Dear Sir:

My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdowns for each configuration so that I can arbitrarily pick one at a later time.

…

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. …

…

To assure that you are building the correct house for our entire family, you will need to contact each of my children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any decisions that you make.

…

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the potential home buyers in my area that they like the features this house has.

I advise you to run up and look at the house my neighbor built last year, as we like it a great deal. It has many things that we feel we also need in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the construction cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

…

PS: My wife has just told me that she disagrees with many of the instructions I’ve given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can’t handle this responsibility, I will have to find another architect.

PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.

Of course this is funny because it’s got a core of sad truth – it makes pretty clear how challenging the field of software is: we in information technology have serious trouble communicating with our customers, when the most important success factor is establishing a common understanding of needs and constraints. Unfortunately, rather than focusing on working with our customers, us-and-them attitudes are extremely common – on both sides – and this just furthers the divide that stops us from understanding our mutual goals. Even more unfortunate is that none of these are new problems – they represent a long-standing status quo in the field. One of my primary goals is to change this status quo at every opportunity.

This idea leads directly to recognition of a fundamental challenge that we all face, and must, as a community, overcome: that of appreciating and understanding the wisdom of those that have come before us. My work in information technology represents an exemplar microcosm of this challenge. I experience an unfortunate phenomenon every day, in every project, on every task: every time we tackle a problem, we think it’s the first time. It very rarely is. The real problem is this: how do we organize, share, communicate and collaborate to overcome this challenge? A solution may be represented, at least in part, in the principles of the admittedly much overhyped and ill-defined “Web 2.0”. These principles provide the opportunity to share knowledge in ways never before possible, without rigid control structures and rules, such that knowledge and experience can become universal. Overhyped or not, I believe these concepts represent a paradigmatic change in the way we think about community. This change will give us, all of us, the opportunity to share knowledge in ways never before possible.

The one universal recognition, that applies to every endeavor, is the importance of striving for quality. To have the desire, the passion, to make whatever you do be the best that it can be. After this recognition, your only task is to find the projects, challenges, the environments, the teams, the coworkers and colleagues that allow you to demonstrate that passion and desire. In words familiar to those that have seen The Matrix, and as I tell my staff at every team meeting: “there is no spoon”. Your world is what you make it.

I have four more special people to mention. I’m proud to have my wife Jeannie, my daughter Julia and my dad Rene all here today. My mother, Marylyn, passed away last December. Without her patience, her lessons, and her encouragement, I could not possibly have come to where I am today.

Thank you all for your patience, and good luck.

Back in the Blogosphere

I’m happy to be back in the blogosphere, in a new home. My old home was foreclosed on, or something.

As my last posting said, I joined Fidelity in late 2005. When I left, in late 2007, I was running the group that developed the common reusable library that we called the Java Infrastructure Layer (JIL). JIL was made up substantially of internally-packaged open source frameworks and tools, augmented by proprietary libraries as necessary to close gaps with the needs of the Fidelity Java development community. My team was also responsible for collecting, generalizing and disseminating development guidance and best practices across the firm.

I left Fidelity to join VistaPrint as Chief Architect in October 2007. My team now comprises several service functions for the rest of the organization, including “Platform Architecture” (tools, frameworks and development best practices; much like the mission of my team at Fidelity), “Solution Architecture” (concerned with the long-term architectural well-being of specific functional areas within our systems), Quality Assurance, Release Engineering and Knowledge Management. I think the incorporation of QA, RE and KM into an architecture team is an enlightened approach to ensuring technical quality in a complex system. I’ve long seen architecture as the platform on which we can reliably and predictably realize a response to a business need with technology. So, solution architecture provides the roadmap, platform architecture the tools, QA the oversight, RE the machinery of delivery, KM the consistency of practice. All critical pieces that support a development organization in successful delivery of systems to satisfy a business demand. The critical additional element is a decision-making process that makes sure we’re applying the right solutions to the problems at hand. More on that in a later post.