The anatomy of our minds

The human brain is divided into two hemispheres. The left hemisphere is responsible for analytical and logical thinking while the right hemisphere is responsible for emotional and creative reasoning. Neuroanatomist Dr. Jill Bolte Taylor, defines the right hemisphere as a “parallel processor”, receiving input from all our sensory interfaces and caring about nothing else other than the present moment, and the left hemisphere as a “serial processor” thinking linearly, analyzing and categorizing all the sensory data received by the right hemisphere. In a sense software developers have a tendency to be “left-brain thinkers”, people who are analytical, factual, logical and rational by nature, while designers, musicians and other artists tend to favor the use of the right hemisphere which enables them to tap into their creative and emotional ego.

Why creativity matters…

Software developers are faced daily with project constraints and restrictions. Deadlines and ship dates are often set, dependant components are not ready on time for integration, new features creep into the spec and so many other issues arise during the process of developing software. Just imagine having to develop a piece of software that you know will take 40 hours and you have to have it developed, unit tested, integration tested and documented in 20 hours and no one else can be assigned to help you. Sounds familiar?

Whenever we are faced with some form of constraint or hardship, our rational, logic thinking is tested against these constraints and it sometimes doesn’t hold up. Suddenly the task at hand seems impossible. In particularly challenging situations our left-brain tends to shutdown or simply go blank. In these situations the right-brain kicks in – we get frustrated, angry and stressed. The right-brain is responsible for emotional responses but it is also responsible for creative thought and playful problem-solving. Constraints and hardship trigger creative thinking and, more often than not, it’s precisely in these situations that we find so-called “creative solutions” to seemingly impossible problems – our “eureka” moments.

The creative process

In 1926, Graham Wallas, a social psychologist and educationalist, presented one of the first attempts to model the creative process in what came to be known as the Wallas stage model. This model explains the creative process in five stages (sometimes four stages where Intimation is a sub-stage):

1. Preparation – Focusing on the problem and exploring the problem’s dimensions;
2. Incubation – The problem is internalized into the unconscious with no external evidence of activity. You’re not even aware of thinking about the problem;
3. Intimation – You somehow feel you’re on the verge of something, but it still seems elusive;
4. Illumination/Insight – The idea burst into awareness. This is the “eureka” moment. This is when you run to the computer;
5. Verification – The idea is applied and verified. This is the moment you test your idea and see it working.

Other models may exist. Some different, some adapted, but according to my own experience this one comes pretty close to the different stages I go through.

Tools of the trade

Everyone is creative, but as adults we usually shy away from admitting it (people in a science or a business profession more than most). Sir Kenneth Robinson says that “if you walk into a room full of five year olds and ask “Who can draw?”, all hands go up. If you ask the same question in high-school almost no hands go up”. Sir Kenneth Robinson, suggests that we unlearn to think creatively. I have to agree. However, don’t believe anyone who says “I don’t have a creative bone in me.” it’s absolutely not true – after all no one can survive on only half a brain. The good news is that we can relearn to think creatively. There are several tools and techniques that are designed to stimulate creative thought and help solve problems creatively. The list below gives an idea of such techniques but is by no means complete:

• Randomness
• Lateral thinking
• Brainstorming
• Thinking outside the box
• Improvisation
• Mind-mapping

What about software development?

There are many stages in the software development lifecycle where these techniques and tools can be used. However, providing a recipe is a left-brain activity and I’d suggest you try to come up with creative ways in which to use these tools. Here are a few ideas of when these tools and techniques can be used:

1. Use mind-mapping to capture requirements and while talking with customers and users;
2. Use brainstorming sessions together with mind-mapping to capture design ideas;
3. Whenever you get stuck, just take a step back, relax, go do something else. You’re already aware of the problem. This is the incubation period, so just wait it out – part of your brain is still actively working on the problem (hmm… Can we still bill these hours to the customer?);
4. If you get into what seems to be an impossible situation with no solution in sight, try to think outside the box using lateral thinking. This can be done effectively in brainstorming sessions as well.
5. In the end, always verify that the ideas you came up with are feasible (back to the left brain!)

In the end we’re all trying to make great software, and what makes software great is it’s applicability to people’s lives. Creativity generates new ideas. The application of new and creative ideas is called Innovation…

So, if you’re planning on starting up your own company, here’s a piece of advice from someone who has surely seen the raise and fall of many potential great companies.

Lately I’ve been involved in several engagements in the Application Platform Optimization space, mainly the Application Lifecycle Management suite of Offerings.

At the present I’m working with one customer who has gone through the Assessment phase and we’ve arrived at a six phases maturity growth roadmap that they’re starting to implement. One of the key aspects of this type of custom engagement is that all the experience gained by the customer and all the guidance delivered by the consulting team, should be persisted by the customer. We’re working with a small team within the customer and they are the ones who will have the responsibility of creating their own guidance and internal best practices and sharing all this information with the rest of the organization. So to collect, persist, distribute and, later on, update their in-house customized guidance for application architecture, development and lifecycle management, we’ve chosen to use the Guidance Explorer tool available on Codeplex.

The use of this tool turned out to be a great fit for this scenario. Instead of compiling one giant document, that would go through several versions and would quickly fall out of synch, the customer is now publishing and updating guidance, based on an existing database of industry and technology best practices. Guidance articles have their own metadata, the lifecycle of each piece of guidance is independent of each other and, if needed, all the guidance can be compiled into a Word document for a hardcopy reference. Additionally, one of my favorite features is the ability to subscribe to the guidance through a published RSS feed and receive a notification whenever guidance changes or a new best practice is published.

Now the team is working on V2, which is planned for the first half of 2009. You can follow their work through the Application Architecture 2.0 Knowledge Base on Codeplex.

You can also follow the work and additional discussions on the subject through J. D. Meier’s blog.

I believe this is a great piece of guidance and am sure it will help shape the near future of application and service architecture on the Microsoft platform.

The TFS Migration and Synchronization Toolkit allows developers to build custom tools that provide migration and synchronization capabilities with other version control systems.

There's a new version of this toolkit available in Codeplex. This release includes enhanced support for the migration of branches and merges.

She and her students have published a number of very interesting papers on varied subjects, particularly on the economics of agile practices, like Test Driven Development (TDD) or Pair Programming.

You can find a list of publications here.

As many youngsters of my generation, I first got exposed to computers in early 1980's through the Sinclair ZX Spectrum and movies like War Games.

I specialized in object-oriented programming, particularly in building enterprise software.Today I'm focusing on SOA, SaaS, S+S and Cloud Computing. I'm deeply interested in exploring new paradigms, specially when they can be abstracted from other fields of science or art.

I've also worked as a consultant on software development process improvement and agile methodologies for several customers throughout the years. I've gained a lot of experience in this field and I speak frequently on the subject in public events. Public presentations is something I enjoy doing, because it allows me to meet new and interesting people and discuss some of my favorite topics.

I live in Lisbon, Portugal, where the summers are still warm and the winters somewhat rainy but not too cold.

To know more about me, check out my .

I have always been fascinated by building design and architecture. My brother is an architect and we have long talks on the subject, where we discuss not only the works of particular architects or artists, but the nature and profession of building design. I find these talks stimulating because I can relate to most of these topics as well.

When it comes to software, however, I find the role of the architect not as defined as it is in construction. At least not yet, as there seems to be a lot of discussion going on about the nature and role of an Architect. The IT industry is not just about software, it's also about the enterprise, the infra-structure and so on. In IT we find infra-structure architects, solution architects and enterprise strategy architects, each focused on one type of architecture. There is one other aspect that, in my mind, widens the gap between architecture in software and in construction, is that architecture in construction is more akin to art than to science, while architecture in IT traditionally stems from engineering and is deeply rooted in science.

So, regarding architecture in IT I keep asking myself two questions:

1. Is software architecture art or science?
2. With so many software engineers available how do we articulate the value of and need for an architect?

I won't address the first question here as it is somewhat metaphysical (not to mention controversial) and is food for another post at a later time. I have to admit I don't have a clear answer to either of these questions, but I venture that to find an answer (if an answer is to be found) we should look at the meaning of architecture in construction and in building design.

In the conversations I've had with my brother around architecture, I became distinctly aware of the great importance architects place on context: topological context, social context, design context, material context.

Take a look, for instance, at the work of architects like Tadao Ando, Mies Van der Rohe, Frank Lloyd Wright or even Frank Ghery and you can see and feel how their buildings either are inserted into the context of the surrounding landscape or they provide a new context to the surrounding landscape. Even when the buildings are disruptive, they are so contextually (i.e. the disruption provides a new context to the surrounding elements).

I venture that one of the greatest values of a software architect's to an IT organization is to provide software design in context. With this I mean, the right design that satisfies a number of propositions, those being the requirements for the software, but also the context in which that software is to be built and operated. This context can be defined in many different ways, for instance tying a business goal to IT capabilities and mapping technology to those capabilities or understanding a services strategy for a given enterprise and designing a LOB application according to that strategy. It might seem obvious and common sense, but I find that this context is frequently overlooked or dismissed, causing numerous disruptions, like constant feature redefinition, scope creep, cost overruns and client dissatisfaction.

In a time where IT is seen as a cost center and there is a generalized idea that most software is built like a house of cards without much structural integrity, it seems like confidence in IT as a strategic asset is dwindling. IT spending is becoming tighter and IT managers have to prove the value of IT to business stakeholders. Architects are a valuable asset to any IT organization in defining the principles for the IT eco-system (the IT context for the enterprise), helping to align business goals and IT capabilities.

• LAN
• T3 6.0 Mps
• T1
• Cable/DSL 1.5Mbps
• Cable/DSL 768k
• Cable/DSL 384k
• Dial-up 56k
• Dial-up 33.6k
• Dial-up 28.8k

If we want to add an additional entry, say "Dial-up 128k", we'll have to add a new network profile definition file.

These files can be found in the following folder:

C:\Program Files\Microsoft Visual Studio 9.0\Common7\ide\Templates\LoadTest\Networks

Just select an appropriate file (say "Dial-up 56k.network"), copy and rename it (to "Dial-up 128k.network") and edit it's contents accordingly:

<Network Name="Dial-up 128k" BandwidthInKbps="128">
</Network>

You'll have to close all Visual Studio instances and re-open them so that it can reload all network profiles.

Related Links:

• Adding Firefox browser to load test you websites in Team System