Agency projects… a time for patterns or not!?

From a software development company to an interactive agency, there is quite a large difference in the perspective on systems development.

Agencies tend to be shortsighted in their operation, which is probably due to their tight bonds with market trends; they tend to focus on differences more than similarities, perhaps due to their business model which is typically about assisting a client with differentiating themselves from the general market.

Combine this with the profile of the average agency developer who typically comes from a designer world moving into development because of the need to do some advanced UI interaction and animation. Compare this profile to the average developer with a basis in Computer Science and Software Engineering and an obvious difference in optics between the two types of developers appear.

The part-time developer having emerged from the trade of visual and animation design, typically knows nothing or little about Code Design Patterns and typically even less about Architectural Patterns, they will often fail to see similarities between applications and solutions to problems. This can be resolved pretty easy by mere information to a certain point, seeing that most of these developers know about the General Responsibility Assignment Software Patterns and the basic Code Design patterns through the use of misc. API’s, though they often have this knowledge often without knowing about the fact that they have been using patterns all along (seeing that most API’s uses misc. patterns extensively).

Now, when the time comes to define the architecture for an agency software project, most often the emphasis on patterns will be small at the most but typically it will be non-existing and all emphasis will be about covering as much horizontal ground as possible at the cost of the vertical axis. This is a well-known practice for Software Engineers as it’s the architecture used for throw-away prototypes and very simple systems with no requirements to maintainability. However, it’s obvious that the cost of this architecture is that maintainability is low and the systems internal logic is non-transparent and therefore not suitable for distributed systems.

A clever guy once said that the natural development of an organization is to go from an Expanding Organization to be Learning Organization, in this light Hello Group is about ready to become a learning organization since we are now…

  1. Responsive and adaptive to our external environment and the interactive agency eco-system.
  2. Keep capability enhancement continuously on every agenda in every department in our organization.
  3. Develop collective as well as individual learning programs.
  4. Using the results of our learning to achieve better results.

By pointing to the build-in discrepancy in perceptions from the traditional agency developer and the mind and thinking of the typical software engineer, I intend to draw up the differences in the definitions of system quality and therefore one of the 4 cardinal project parameters and objectives.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s