This page describes some of my perspectives on software development, and provides some additional background about my professional interests, including past consulting projects.

On language and object oriented design

My current programming-language-of-choice is SwiftI have been experimenting with Swift on GitHub. It embodies and enables a lot of the best practices I’ve sought to follow throughout my career. I’ve enjoyed learning how to work with value types and protocols with default implementations. I am not a guru in Swift, though, or in any other language. I have tended to use object oriented languages, including Objective-C, C++, Object Pascal, SmallTalk, and Java.

I spent the early part of my career using software frameworks that formed the basis of modern design patterns. At Apple I had the privilege to work on one of them. Throughout my career, I have developed a great deal of real-world experience improving existing code. I don't know everything there is to know about object oriented design, though. Lately, I’ve been advocating SOLID object oriented design principles and service-oriented architecture with the CppMicroServices C++ framework.

On academics

I don’t hold a degree in Computer Science; I hold a degree in Mechanical Engineering. So, I tend to emphasize engineering over science. I have not studied for a masters degree or PhD, but I have co-founded a startup company with a Carnegie Mellon / Stanford University professor. So, I suppose I tend to favor doing over thinking.

On systems thinking

I have been called a systems thinker.

My academic background is in the design and engineering of physical things: how to build them, and more importantly, how they behave in the real world. I suppose the systems thinking part is, I tend to observe and think about what’s actually happening.

One of my more memorable class projects was a friction experiment involving ball bearings that broke more often than it yielded "expected results"—in fact, when it did work at all, the results were far from the calculations, sometimes by an order of magnitude. Each year, a new class was challenged to explain why. Formal training—knowledge of equations—wasn’t going to be enough.

This lesson applies well to software:

In theory, there is no difference between theory and practice. In practice, there is.

— Jan van de Snepscheut

Forget the box. There is no box

On user experience

I love designing user interfaces, and I love even more how customers use them.

I co-founded a startup company to produce a visual modeling application for decision analysis. When we first shipped, a PC Week reviewer commented, “everything that's wrong with the spreadsheet is fixed in Analytica. Not everything was as perfect as the reviewer suggests, but this is the kind of result I seek by applying systems thinking to design for the user experience. 

Here is a more recent example:

Technically this the best designed app I have ever used. It is easy to use, has a clean layout… With all of my heart I wish I could get this app designer to fix all of the other apps I have downloaded. The design is perfect!

— dmilbradt, Yi Jing iOS App Store review, February 14, 2015

On algorithms

DHH @dhh

Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.

21 February

Like David, I don’t have an ability to recall data structures or algorithms. Remember, I never had formal training in computer science. Don’t ask me to write a doubly-linked list on a whiteboard. What matters to me is whether I would need to do such a thing, how I would go about doing it, and whether I would know I had done it right. I count on my ability to experiment, observe, and reflect, and on my peers to help keep me honest.

On coding style

I was heavily influenced by MacApp's coding style: concise, meaningfully named functions, legible comments, lots of white space. The higher purpose of writing source code isn't to satisfy the compiler, it's to help the person who follows in your footsteps (including yourself, if enough time passes).

Some highlights of my coding style include:

  • Use complete, clear names for functions and variables in CamelCaps. This way, code is self-documenting, and less likely to require interpretation or comments.
  • Be very careful about maintaining a function's or class's purpose and size. Whenever something gets too big, aggressively refactor. Code that exceeds its mandate is the bane of this industry.
  • Always comment code. Every function declaration and every significant block of code should have at least a brief comment. Comments are about context; you will eventually forget the context.
  • When in Rome, do as the Romans. Follow the coding style of the file you are editing, even if you disagree with it. It’s more important to be locally consistent than it is to be globally consistent.

The Swift team has done a fantastic job of articulating API design guidelines for Swift, here.

On leading and managing

I can get a lot more done by enabling a diversity of people who complement and extend what I can do on my own.

Hiring and retaining great people is hard. I’ve begun to suspect that it’s a little bit easier to grow great people. In any event, I’ve had much better success at that, lately. I have mentored and coached junior engineers who have become great, and I have built and developed teams of engineers with a variety of expertise.

If I notice someone expressing interest in something, I encourage them. If their interest is not aligned with my team’s or department’s mission, I ask the question, “does the mission need changing?” If I need to discuss something with someone, I use SneakerNet (I talk to them in person). I generally don’t like meetings. I strive for a high-trust, learning, congruent working environment where everybody is leading and initiating in their own way.

Past consulting projects

1998 Apple Inc., Cupertino, California

Implemented the Apple C++ Frameworks group's Appearance Apple Class Suite, a set of Appearance Manager classes using a runtime-switchable "theme controls" architecture.

1997 Within Inc., Waynesburg, Pennsylvania

Developed prototype Mailing List Manger (MLM) plug-in for the Qualcomm Eudora e-mail client.

1992 Moto Development Group, San Francisco, California

Assisted in the development of software tools for testing “Finger” (a prototype notebook trackpad).


  • "MacApp 2 for PowerPC," MacTech Magazine, Feb. 1996 (Vol. 12, No. 2), porting MacApp 2 applications to PowerPC.
  • "MacApp Pascal Rides Again," MacTech Magazine, Nov. 1995 (Vol. 11, No. 11), a report on the availability of MacApp2PPC.
  • "Desktop tracking in MacApp 2.0," FrameWorks Journal, Nov/Dec 1992 (Vol. 6, No. 6), a roll-your-own implementation of drag and drop technology.

© Brian Arnold 2017