Engineering Thinking

Engineering Thinking explores the mental models, habits, and reasoning patterns that separate good engineers from great ones. It focuses on judgment, tradeoffs, balance, and designing systems that are proportionate to the problems they solve.

Touch UX Trends Started by Apps

It’s interesting to watch how the accepted standard for User Experience (UX) evolves over time. It’s like there is a universal “vocabulary” of actions and gestures. We intuitively understand them and also expect them to be implemented in every app we use.

Engineering Thinking 2017-04-17

Goldilocks and the Three Functions

How much code is enough code? Does the phrase “less is more” apply here? Some people take pride in condensing their code into “one-liners,” but the reality is that makes for obtuse, unmaintainable code where defects love to hide. Sure, there are some cases where gaining performance or some other type of efficiency justifies writing code that’s a little hard to follow, but as a general rule I avoid this kind of code whenever possible.

Engineering Thinking 2017-03-05

Strong Typing Considerations

You could also call this one “Why I Hate JavaScript,” but there are many popular languages today that do not employ strong typing. JavaScript was just the language I happened to be working in when the following code had me pulling my hair out for nearly twenty minutes:

Engineering Thinking 2013-07-31

Do Horizontal Lines Make a Good Symbol for a Button?

Recently, a friend of mine asked me what I thought of the “horizontal lines” symbol that is being used more and more frequently to indicate where to click or tap to get to a navigation menu. I really had to take some time to think about it, because I realized I don’t usually pay very close attention to the symbols used on buttons in the apps that I use.

Engineering Thinking 2013-04-10

Adaptive Gadgetry - Exposing Different Functions as a Function of User Capability

Engineering Thinking 2013-04-01

Why "Bug Free" is Impossible

One of the most common misconceptions about software testing is that, once a program or software system has gone through testing, it is free of bugs. If you accept this assumption, it logically follows that, if any bugs are found by the end user, the software was not properly tested. Both of these statements are absolutely false.

Engineering Thinking 2011-08-23

The Daily - I'll Pass

On February 2nd, News Corp. launched The Daily, an iPad app that aims to bridge the gap between the print and digital world in the news arena. There were a number of news stories about this one before it arrived because Apple had been working with News Corp. to figure out a subscription payment structure and how to support it in the iTunes store. Curious, I downloaded the app, which nicely includes a 2 week free trial, and decided to see what all the fuss was about. Here’s what I found:

Engineering Thinking 2011-02-05

Agile Requirements Gathering Risks

The biggest strength that traditional requirements gathering techniques have is their structure. When using these methods, the Requirements Engineer (RE) is applying a formula, pure and simple. There are outlines to follow and forms to fill out, which makes the job of RE more accessible to a larger group of people.

Engineering Thinking 2010-07-16

Valve Got it Right

On May 12, 2010, Valve made its Steam platform available on the Mac. There are a few key points of the way Valve chose to do this that show design decisions which support the needs and desires of the customer base. All too often, software companies do things the way that is easiest for them, at the expense of end user satisfaction. The Steam platform has grown in a way that exhibits the exact opposite: Valve gave themselves extra work, and sacrificed some potential revenue, to build a platform that caters to the users.

Engineering Thinking 2010-07-11

Tested or Not?

A software system’s “tested” status is an interesting thing. Sometimes, in a schedule crunch, the decision makers may decide to cut back on testing, hitting only the most commonly used portions of the system. Almost inevitably, when this is done, a bug in one of the less commonly used parts of the system gets out.

Engineering Thinking 2009-07-22

Recording Real Time to Failure

If the mean time to failure is an important statistic, why only measure it during development and testing? Building a small, anonymous crash reporting tool into your application can provide you with a wealth of information and can help you to improve your overall quality. Of course it would be wise to make sure the users are aware of this tool, wiser to give them the ability to enable and disable it as they see fit, and wisest to leave it disabled by default.

Engineering Thinking 2008-10-29

Caching Object Data with Time Stamps

When you build an application backed by a database, one of the things you want to minimize is the amount of data transfer between the application and the database. There are, of course, two types of data transfer: the application retrieving data from the database, and the application sending data to the database. In this post, I want to focus on the former type.

Engineering Thinking 2008-09-18

Baseline Systems for Testing

I haven’t researched this, so I don’t know if it’s already an established practice or not.

Engineering Thinking 2008-09-16