|
Law of Least Effort
Someone has asked me what I understand by the "Law of Least Effort" or "Law of Minimum Effort". There we go:
When do *you* work better? When are *you* most productive? Is it when stressed? When relaxed?
It seems our brain follows the Law of Least Effort to solve problems. That's probably why we give our best when our brain energy can be focused in a problem, when nothing in the outer world disturbs us.
This status where your brain can concentrate lots of energy in a single problem is usually know as the "flow" or "the zone". This phenomenon is well known among developers, but I think applies well to everybody else! ;-)
As Joel expresses it:
We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment.(taken from Joel on Software)
For more on this you might want to take a look at: Undertanding the Psychology of Programming.
Conway's Law
Organizational Pattern: Make sure the organization is compatible with the product architecture.
It seems Conway's Lay is important when you build an architecture or when you reorganize your company.These measures can work to reduce the risk and increase the effectiveness of your enterprise architecture efforts.
I think Conway's Law is just a corollary of the Law of Least Effort. When a company is badly organized, or when the software architecture does not fit the company structure, then tensions arise and you don't allow people to enter "flow". You don't allow them to concentrate. You don't allow them to give their best.
I have seen this myself. I remember a company where the IT department was separated into the Analysts Group, the Database Group and the Development Group. This was a big project. These divisions were well established and could not be changed. We designed an architecture where a group of developers was responsible for dealing with Analysts (thus enforcing communication with them). We made the Database Group responsible for designing and tuning the SQL queries inside our DAOs. Communication within the three groups was boosted. Everybody knew what to do. Law of Minimum Effort. Flow. The project was a success.
Manageability
Managing people and architecturing software systems are dependant things. The Human Factor, the People building the system, are as important as choosing between JDO, EJBQL or Hibernate. Don't just focus on the technical part. See what people thinks and what their skills are. Maximize those. Apply the Law of Minimum Effort.
As Alistair Cockburn (of Use Case Analysis world fame) puts it:
Yet it is clear that social issues affect the software architecture in ways that the good architect takes into account.
|
Enviado por jjmahe en junio 21, 2004 a las 09:50 PM CEST #
Enviado por Thinking Out Loud: Thought Leadership from an Enterprise Architect en septiembre 30, 2004 a las 11:36 AM CEST #