JSR Notes:

The Design Cycle

The cycle that we go through with each major release of a product is, generally (for both hardware and software):

1. Planning (or understanding)_______ IA Stage A
2. Design _______ IA Stage B
3. Development (i.e. making)_______ IA Stage C & "Programming" Stage
4. Installation & Implementation _______ IA handing it over to your user to try
5. Evaluation _______ IA Stage E

And this is cyclical - so right back to the planning for the next iteration of the product, making better and better and better. In fact the key word in the assessment statement, "iterate" implies the importance of the design process being cyclical.

Think of the expression "back to the drawing board"; you are not just making minor tweaks at the end of the process with true design cycle thinking, you are literally going back to the drawing board and starting a new, fresh iteration with all of the experience and information from the current and previous iterations.

Design is Cyclical

At one point during my first ISB year, at Design meetings it was suggested that there be an "out" arrow from the Design Cycle diagram. But I argued (apparently successfully!) against that, since as long as a product exists, there is at least evaluation of how to improve it, if not 100% of the time always an actual implementation of the improvements. Design really is a cycle, not a path that ends.

Think of all of the version, indeed all of the Design Cycle iterations of:

• iPhone, and all the differenent versions
• iMacs
• Mac Operating System
• Windows... with all the patches
• iTunes... with all those updates
• indeed, every application
• indeed, just about every piece of hardware

The Importance of Iteration

"Iteration" means to repeat. And so the point here is that you don't just go through the design cycle once. Rather, once you have a functional product, you then look at it and refine it, and in the process go through the entire design cycle again. And this repeats over and over again, whether it be a new major release of a software application, or a new MacBook Air.

Importance of iteration (*** the main point of this assessment statement***)

i.e. why it is important to iterate in the design process:

• Often it takes actual full implementation and "real world" conditions to know what to improve.
• Incremental, dependent improvements: Improvements in one iteration are only made possible by improvements in the last.
• New technologies and techniques which did not exist in former iterations can be applied/used.
• It is important to always go back to the initial basic questions and the basic needs, but at the same time, these needs can change over time.
• And overall, the stability and reliability of the produce is improved with each new version.

IA Solution Connection and Considerations

Your main design iterations will hopefully happen during your planning stages only. If you have to iterate over and over again at the coding stages, that's when we run into trouble; there's just not the time go be going back to the drawing board with the time-consuming nature of programming.

So you **need** to go back and forth, and back and forth to your client, at the planning stages, until you are absolutely clear what thier problem is and how you can address it to their satisfaction. It is a whole lot easier to draw a line through a part of your prototype than to completely re-tool two or three classes of code.

As the old addage goes (and now is the time to get the irony with this):

"Weeks of programming can save hours of planning."... :-/

So rather than live that possibility, do your hours of planning during stages A, B, and C, and save yourelf weeks of unnecessary coding and re-coding.

 

 

 

--------------------------- Extra ---------------------------

 

Note that the 2 following "And finally" are good and interesting, but not specifically geared to this assessment statement.

And finally 1: Could your own IAs get another iteration?

For a while now I've had this neat idea of potentially having your IA solution being taken on by another student another year. If this idea happens, the students will not just program from where you left off; they will "go back to the drawing board" and go through all the analysis, class diagrams, and planning etc., and only then they will edit, re-tool, and add to your code to both improve it and expand its capabilities.

Many of the same points and considerations that came up in your planning and prototyping of the first iteration of the product would still likely be applicable the next time around. But - and this is a main point - they could be slightly refined based the existence and use of the first program that you made. Through its actual use, in real life, many things unable to be seen or thought of before, could then be taken into consideration in the development of the "new and improved" version!

And finally 2: What the The IT/CS World can teach us about mistakes & starting over

It is well worth noting the IT/CS world's much higher tolerance of mistakes, not knowing, and "messing around", compared to other realms of society. Google, for example, always releases in "beta" first. Indeed the rest of the world could learn a whole lot from IT folks and computer scientists in this regard.

Since we know that we will be doing multiple iterations, we are a lot freer to be more objective, even critical, with our assessments of each stage in the process. And since this happens often and early, problems tend to be nipped in the bud, resulting in both quicker overall design and cost savings. And iterative design in this way teaches us that through messing up repetitively you will actually get it right sooner or later, resulting in a more successful final product.

As I often note, this is not quite the same when building bridges or other physical things, but with coding, yes, "if it's almost right, it's wrong", but at the same time "if it's wrong, it may be almost right". Mess around and see! That's the iterative design cycle way!

 

 

Jaimie: Version controlling, GIT Hub

And great example of robot fine tuning and ramping up year after year with FIRST/Vex teams. Things learned one year are applied the next.

Jose: FIRST (and Vex robotics) - even changing the design because of an initial lack of proper understanding of the rules and how the game points work.