Flat Earth Studio LLC

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 Swift. I have been experimenting with Swift with complete rewrites of my shipping apps and new app development. I’ve uploaded some of this work on GitHub. Swift embodies and enables a lot of the best practices I’ve sought to follow throughout my career. It’s very freeing to be working with richer enumerations, 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 C++, Objective-C, Object Pascal, SmallTalk and Java, throughout my career.

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-based architecture in C++ with the CppMicroServices 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 and theory—wasn’t going to be enough.

This lesson applies well to software:

— 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:

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

Great user experience is about understanding the customer's goals, and enabling them through software. Which includes getting out of the customer’s way, sometimes. The ideal user interface is no user interface.

On algorithms

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 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. So instead, let’s talk about requirements, alternatives, and measurements for success. Because if we screw those up, it doesn't really matter what algorithm was used, how fast it was written, or how “correct” it is. 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 CamelCase. 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 anything gets too big, aggressively refactor. Code that exceeds its original 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 could do on my own.

Hiring and retaining great people is hard. I’ve begun to suspect that it’s a little bit easier to develop 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.

I encourage breaking things and making mistakes; the important thing is that that we learn from these experiences. I generally don’t like meetings. If I need to discuss something with someone, I use SneakerNet (I talk to them in person). I strive for a high-trust, collaborative, 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).

Articles

• "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.