After completing the planning phase of the software design lifecycle, it is usually a good idea to test your architecture before the programming begins. You might be wondering – how do you test an architecture without doing any programming? Well, here’s one way you can do it:
Try conducting a series of role-playing exercises with the development team. This should be a fun exercise, so be careful not to impose any rigid rules on the game. First, give each person a piece of construction paper and markers. Next, conduct the exercise by providing the team with a use-case scenario that fits the context of the application that has been assigned to the team. Allow them to brainstorm the solution using the architecture that you created as a guide. They should decide who plays what role, based on the elements of your architectural diagram. A role could be an object, a data or series of data packets, an event, an event dispatcher, etc. Each person should then write down the name of their role on the piece of construction paper they were given and hold it up while acting out the use case scenario. The only requirement is that the developers involved need to first understand the architecture, or it will result in confusion and frustration. They must also be familiar with basic object-oriented principles so they may communicate effectively, especially if they run into a situation where your architecture fails. The team must then brainstorm possible solutions to the problem.
This is a solid, low-cost way of putting your architecture to the test before the application development process starts. During their performance, you will likely find them discovering what will and will not work for the application while they interact with each other. Expect to be surprised by unexpected results that the team will encounter during the performance (like bumping into each other while performing a task, being in the wrong place at the right time or vice versa, etc…).
This type of multi-sensory problem solving has proven to enhance learning and problem solving skills at an incredibly rapid rate in education, and a number of related studies have been conducted in the field of Psychology to fully understand just why this works so well. What researchers have found, is that it facilitates a “rewiring” of the brain, effectively bridging the gap between the right and left hemispheres.
Development Styles and Methodologies
Enterprise level application development is extremely complex and researchers have had a terrible time identifying the specifics of why so many large-scale software projects fail. However, a more generalized approach would suggest that it is due to having a constantly changing environment. This includes: changes in business requirements in the middle of the project, swapping developers in and out of projects like monkeys that bang on keyboards all day, budget cuts, and a lopsided team with regard to skill sets. With regard to the latter, it is common to find small development teams with too many “experts”. Remember, you need people to worry about the trees too, not just the forest.
The latest development methodology (warning: buzzword ahead) is commonly referred to by the term agile development. Agile development is a “best practices” type of approach that supersedes prior attempts at creating a universal development model such as “extreme programming” and “Rational Unified Process”, among others. Every time I hear a Technical Lead or Project Manager say “we use the agile development method”, I am reminded of Einstein’s definition of insanity: doing the same thing over and over, yet expecting a different result each time.
As a science, computer programming is quite immature, and it therefore suffers from the same concepts and theories right now that once existed in the early years of every science, each of which we now look at as being totally ridiculous. For example, it was once thought that the earth was the center-point of the universe. We can even find some disturbing theories and practices in the field of Medicine. In the 1400’s, it was believed that bringing the sick back to health meant “bleeding” the illness out the individual. As a result, a mere sinus infection could cost you your life thanks to what was then considered “modern medicine”.
The history of other sciences and what was considered to be “best practices” must be taken into account considering the age of the science of computer programming. Agile development, for example, favors experts in the field to a great extent, which is comprised of maybe 2% to 5% of the computer programmer population. By definition, Agile Development uses feedback to make constant adjustments in a highly collaborative environment. The problem with this is that the ability to self-correct based on previous experiences is only possible at higher skill levels, where the developer is able to observe an application as an objective whole, not just the little pieces that she constructed. According to Andy Hunt in his book Pragmatic Thinking and Learning, “Advanced beginners and competent practitioners often confuse design patterns for recipes, often with disastrous results.”
Possibly Related Posts:
Posted by Dan Orlando on April 5th, 2009 :: Filed under
Enterprise Flex
