Block Comment

Beginning in the 1920s, the majority of automobiles that have ever seen production have been modeled using clay during the early stages of their development. This is a process that was pioneered by Haley Earl during his career at General Motors, where it was met with great success.
The whole purpose of this process was to show what a tangible product would look and feel like before steeping the production team into the expensive and intense development of that product.

In any project, the earlier that new design changes are introduced, the cheaper they are to successfully implement in the final product.

General Motor’s Designers and Engineers adopted the clay modeling technique many years ago to help them ensure the final product was a success, and more importantly, that the end product ended up being what they set out to create.

So, what do cars and clay have to do with software, you may ask? Well, the same principles described above can be seen in software engineering. The “clay” that we use to represent our software products often consists of data flow diagrams and user interface sketches, among other things.

In the next few posts, I hope to be able to outline an effective process for creating a “clay” model of our software before we direct a team of talented (and expensive) developers down a path that we may find later was paved with incorrect choices.

Modern day Designers and Engineers still take advantage of the clay modeling technique for automotive development.

Well then.

As modern day software engineers, should we (and how can we) model something that is so inherently intangible as software? I am going to do my very best to convince any readers that this is not only a helpful, but crucial step in the development process.

Any commentary is invited from those that have experience in this area, or anyone else that would like to add to what I have here- the more the merrier!