OK, so it has been awhile since my last post- thanks for bearing with me!
Life gets busy, and the design series is taking more time to put together than I originally thought it would. So in lieu of finishing that series, I am going to change topics for a bit- but don’t worry, the series will not go unfinished.
With modern software development, an application is rarely created completely from scratch. There is a plethora of libraries, plugins, and components that can be leveraged to ease the workload. This has become such a part of our way of thinking, we often don’t notice it anymore. I know that I have found myself grumbling about challenges associated with configuring an application server- without taking the slightest consideration of how difficult and involved it would be to create an application server from the ground up. Although this is an extreme example, it illustrates the point.
With all of these components available for us to use, it changes the way that we engineer software. We have to take into account the advantage of using code that someone else wrote, while also not forgetting the learning curve of the API that comes along with each one.
This changes the idea of modeling our software in clay, or rather from an unformed lump of clay at least. It is almost like we are putting together pieces of the system that fit together nicely, like just like a child (uh…a child…right) might play with a bucket of legos. But we are still need to configure and shape these pieces to work seamlessly together. It is more like we are developing with preformed pieces of clay that can be used to construct a larger system. This concept could be thought of as using “Claygos” to model and develop our system.
For example, lets say that we are going to create ourselves a bright, shinny, and profitable AJAX driven web based application. When designing the system, we already have many, many components to consider using- and consequently learning the APIs for.
So lets start with the what the users will be interacting with. We should think about our user interface design. We could develop all of our nifty AJAXy interactions with the user in JavaScript by ourselves, but why do that, when we can find an easy, out-of-the-box solution that can offload allot of that work for us. There is an ever growing community of user interface AJAX frameworks to choose from. There is the Dojo toolkit, and old time favorite. Then there is the Yahoo UI library- backed by a large corporation that can afford to develop quality products. There is also JQuery, a solid AJAX framework, with many advanced user interface features. But then, there was that time that a friend showed me a site that used Mootools, which had some great visual effects. Oh, and there is the Prototype framework, a favorite in the Ruby on Rails community…and I hear that if your going to use Prototype, then you can add allot of really cool visual effects in your UI if you take advantage of the Script.aculo.us library as an add on. And oh yeah, there is also ExtJs, a library that extends the Yahoo UI library, Jquery, and Prototype. Hmmmmm. This is alot to take in. All of a sudden we have allot of research to do in order to find the right “easy, out of the box” solution to our user interface issues.
BTW- click the comic to view it in at a larger, more readable size.
OK, so lets take a break for a minute from our user interface design and take a look at some of the fundamentals of how we are going to process our data on the server-side. Ah, good ol’ fashioned server side programming. For sake of argument, lets say that we have already decided to develop our application with Java. Lets get started! Well, we should look at any components that will make it easier to process our data, and transfer that data back to the client AJAX style. We don’t want to go reinventing any wheels here do we?
Oh look, there are some choices here too. Should we use DWR, which allows us seamless communications between the server and the client, which hides allot of the AJAX magic? Also, the Google Web Toolkit looks interesting- it takes Java code and compiles it into compatible JavaScript code for use on the client side, which would assuredly alleviate some of the headaches associated with traditional AJAX development. I also remember running accost a project called ThinWire, which seems to be able to produce some impressive results. Yup, that’s right…more reading and possible API learnin’.
So with all of these rich choices out there, and a gang of fanboys (and girls) following each one of them around singing their praises, which ones do we choose to make our application the best that it can possibly be? Also, how can we create mock ups that represent how these external components will make our application look and feel.
These is the question that we will attack in the next section of this series.
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!
Welcome to the blog!
My name is Chris Arnold, and I am a software developer for a company in the Portland, Oregon area. This blog will be a platform for all of my personal thoughts and opinions to springboard off of into the rest of the world. Feel free to leave any comments you may have, I value and feedback- be it positive or very positive.
The topics presented here will be general in nature, but will all be related to my interests somehow. This means that most posts will be related to technology in some form or another. Feel free to let me know if there are any topics of interest that you think deserve commentary.
Welcome, and check back often!
