Archive for January, 2010

Design First, Right?

Monday, January 4th, 2010

Engineers and engineering managers generally agree that the first step of a project is to define requirements. They also agree that a design should be done before implementation starts. But is this commonly known and widely observed practice correct? Haven’t we all encountered a design that, well into the project, was found to be a poor fit for the platform? It’s not that the design was bad – it was just inappropriate for the specific technology being used. Can it be there are times when the design first approach makes no sense?


How dare I suggest there are times when engineers should start implementation before there is a design? Well, actually I’m saying something even worse. I claim there are times when the engineers should simply play with the technology to learn about it and see what it can do – BEFORE they do a design. I’m not saying they should do this at home in their free time. This is corporate work and they should charge the project while they explore the technology with no preconceived design.

BLASPHEME!! – again.

How dare I claim there are times when a technical expert can be behaving in a professional fashion by “playing” with a technology on company time when the schedule clock is ticking? Well, because it’s true. Sometimes, especially with new or unfamiliar technology, the team can produce a design that is completely inappropriate for the mysterious new (to them) technology. Worse, the team may produce a design that is a near miss that “sort of” works. That design must be shoehorned into the platform and beaten into submission with months of tweaking and hard work. If you have not seen this on a project, you are in denial or have not been an engineer long enough. Asking an engineer ignorant of the nuances of a technology to do a design is like asking Picasso to do a gothic painting of the Last Supper. You might get something, but the genius, subject matter, and style are just not in sync. Such a design will likely be ugly and inefficient or worse.

I recently completed an iPhone application called “Treadmill Controller”. I started it in the universally accepted right way. I started with full and complete requirements, a design, and even an implementation on a Windows PC platform. My initial concept was to simply port this implementation to the iPhone. However, the two platforms (PC and iPhone) have very different capabilities and user interface concepts.

· The PC application was intended to generate a “chirp” audio file that could be played back later with Media Player to control the treadmill speed and incline. With the iPhone app, however, it seemed more appropriate to stream the controlling audio “chirps” out the earphone jack.

· The PC has much, much more screen real-estate.

· The PC application was mouse oriented and made extensive use of drop-down menus. This approach just didn’t translate well to the touch-screen iPhone.

In just a couple of days I was able to generate “chirp” audio on the iPhone and stream it out the earphone jack to control a treadmill. However, generating specific audio chirps is pretty much an algorithmic exercise and somewhat independent of whether it is implemented in C, C++, or Objective C. Specifying a workout segment, on the other hand, requires extensive interaction with the iPhone user interface. One must provide its time, speed, and incline.

To build a suitable user interface on the iPhone I had to learn how to create and manipulate a number of user interface elements. To appropriately use this iPhone technology I also had to learn what looked and “felt” right. While there was learning “how to” there was far more learning “how to in situ”.

I invested over a month “playing” with different approaches and implementation concepts to learn what was useable, comfortable, and efficient. In many companies the cost of this investment would have been prohibitive and the first generation product would not have been very good.

There can be many unknowns in the real world of engineering design. Resolving issues and implementing a good product requires teamwork between management and staff and between the various corporate groups. Great products cannot be made from a superficial understanding of a new technology. One must master the technological nuances, speak the proper incantations, and lay the magic sticks in the right orientation. This will only happen when management supports pre-design “playing” to become expert with the new and unknown technology.