On this page.... RSS 2.0 | Atom 1.0 | CDF
# Tuesday, July 29, 2008

Wrox has started a new thing as of late they're calling Wrox First.  It's essentially a wiki of the book that I and my fellow Silverlight 2 authors are working on--Silverlight 2 Programmer's Reference.  Not only do you get early access, you can also shape how the book develops by making comments and suggestions.  My understanding is that it's just $19.99 and will get you access to drafts, revisions, and the final chapters as they are in the book for up to a year after publishing. 

Seems like an interesting option for those who want the book and sample code now rather than waiting until later this year when it is published.  Let me know what you think!

Tuesday, July 29, 2008 2:35:41 PM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, July 02, 2008

Phwew!  I just moved yesterday (actually all weekend and yesterday and still more unpacking to go now!).  Man, all that moving is starting to wear, but we're very happy in the new place.  A lot more space to make room for number four! :)

On to the point.  Josh Smith has extended his Podder skinning competition.  For those who don't know, Podder is this nifty WPF-based podcasting client/player.  He designed it so that you can completely change the look and feel using skins.  I suggested a better term would be skeletoning, since you can change the structure in addition to the styling, but so far that hasn't caught on.  Be sure to tell him you think that's a better term!

Wednesday, July 02, 2008 9:39:04 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, June 20, 2008

I'm not sure why this didn't occur to me before...  I read recently another brief article about the negative impact of email on productivity the other day, so I was thinking about a way to deal with it that didn't involve, e.g., closing Outlook and maybe even setting an "I'm not available by email until 3p today" out of office type message--seems a bit extreme, and it would also preclude my getting meeting reminders. 

It occurred to me that what usually happens is I get the nifty little toaster popup notification while doing something, almost always click on it for more detail, and then get drawn into a distraction over it.  Similarly, I was using one of those Gmail Vista gadgets that would highlight when I had Gmail waiting, or I'd leave it open and minimized and see the Inbox count in the taskbar.  The problem was not (for me) so much getting too much email as having the regular interruptions that were occasioned by these terribly useful notification mechanisms. 

Having isolated the problem, i.e., having framed the question correctly (which usually the most important part of solving a problem), I asked "How can I make these notifications go away?"  And the answer was immediately apparent: turn them off. :)

To that end, I went into Outlook advanced email options (Tools -> Options -> Email Options -> Advanced Email Options--who knew notifications were advanced?!) and deselect all the notification options:

Advanced E-mail Options Dialog

I then removed the Gmail notifier gadget, and I close my Gmail when done with it.  The magic is that I still get my task and meeting reminders, but I don't get the regular interruptive notifications.  This had an immediate noticeable effect--I could work through to a good stopping point on the thing I was working on, i.e., a point I'd normally take a break, and then I'd check my email.  Wow!  Who knew something so simple could make such a difference?  I figure if it is critical, somebody will call or come knocking on my door. :)

As a complimentary technique to that, I have taken my Inbox strategy to the next level, following a bit of advice given by Mark Hurst (who wrote a book on Bit Literacy [that I haven't read]).  One of his suggestions to avoid information overload is to keep your Inbox empty.  I previously already worked to do that because I used my Inbox like a to-do list (and don't like having a long to-do list), but Mark's advice is precisely not to do that--use it as an Inbox and get stuff out of it immediately. 

Having not read the book (in which I'm sure are tons of helpful little tidbits), I take that to mean act on it immediately if possible, file it if need be, or set up a task to do something with it later.  I was already doing the first two, but I've found this additional third technique to be a nice add.  There is a distinct satisfaction (for me anyway) to having an empty inbox--maybe it's my personality type. :)

I hope this maybe helps others out there in the same boat.

Friday, June 20, 2008 5:28:31 PM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, June 12, 2008

Thanks to Mark Hurst over at Good Experience for blogging this one.  I thoroughly enjoyed it.  My favorite: "Procrastination is playing imaginary computer games with your furniture."  I laughed out loud in public..

Now I'm going to try my first embed; let me know if there are problems.

Thursday, June 12, 2008 9:38:08 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, May 15, 2008

I haven't done any research, so maybe it is out there.  But I had a thought the other day as I accepted yet another invite to connect from yet another social networking site from someone I have connected with numerous times. 

Wouldn't it be great if I could have one, unified set of social contacts, my social network, that I could then just share out to various social networking sites?  I mean, sure, folks would have to opt into it, someone would have to think about the privacy issues, but good grief, it seems like we need something like that...

Thursday, May 15, 2008 1:02:49 PM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [1]  | 
# Wednesday, April 23, 2008

Just reading the first article in the latest edition of Microsoft's The Architecture Journal.  It's called "We Don't Need No Architects" by Joseph Hofstader.  I thought, oh good, someone voicing a dissident opinion, but the article is rather a rebuttal to that claim.  I figure maybe a response to the response is in order. :)

Mr. Hofstader suggests that architects think in terms of bubbles and devs think in terms of code and, by extension, only see part of the picture.  He describes various "architectural" activities such as analyzing the problem domain, choosing and applying appropriate technologies to solve problems, and the use of patterns.

Is it just me, or is this a sort of dumbing down of the developer role in order to support a, potentially unnecessary, distinction between it and "the architect"?  I mean, a smart developer needs to do all of these things, too.  They're not just code monkeys.

In fact, in introducing such a division in responsibilities, we would actually seemingly perpetuate a long-standing problem in software development--a disjuncture between the problem and solution space because we keep trying to insert these business translators (call them technical business analysts, software architects, whatever you want) into our methodology. 

What's wrong with this?  First, it puts the burden for understanding the business onto one (or a few) persons, but more importantly, it limits that mind share to those individuals.  That is never a good thing, but it is especially bad for software.  In so doing, it also puts a burden on those individuals to correctly interpret and translate (a considerable challenge) and finally to sufficiently communicate a design to developers--enter large specification documents, heavier process, and more overhead.

On the other hand, domain-driven design, for instance, is all about instilling domain knowledge into the solution and coming to a common alignment between the business and the solution creators.  It's axiomatic in business that you need a shared vision to be successful, and this approach to software creation is all about that.  Shared vision, mutual cooperation, and a shared language. 

It eliminates the need for a translator because both learn to speak the same domain language.  It eliminates the knowledge bottlenecks (or at least really reduces them), and it increases shared knowledge.  And DDD is not burdened with the distinction between an architect and a developer.  Agile methodologies in general are geared towards reducing barriers and overhead in the creation of software (and that's why they're generally more successful, and they can scale).

I hope that all the brilliant and more-well-known/respected folks will forgive me; this is not intended as a slight, but I have to ask--are we creating the "architecture" profession unconsciously just to create a more defined career path (i.e., a way for us techies to move up the ranks)?  Are we just going with the flow from an old but broken analogy?  Are we introducing roles that really would be better served through other, non-architecty roles?

To this last point, I see some folks suggesting "infrastructure" and "business" and "software" and "whatehaveyou" architects.  Why are we so keen on the term "architect"?  I'll grant, it does sound really fancy, but it is so, so painfully clear that it is ambiguous and overloaded (and inaccurate, if you ask me) .  Maybe these other roles do need to exist in some organizations, but it seems like we're just bent on calling them "architect" for no apparent good reason other than we've latched onto it as a respectable (and well-paid) moniker. 

In choosing to proliferate the "architect" terminology, we're perpetuating and extending the confusion around it.  We're purporting to solve the problem of it being ill-defined, but in reality we're doing the opposite.  And everyone (IASA, Open Group, Microsoft, to name some just in the latest issue of the Journal) is trying to do it all at once with little coordination. 

It seems borderline insane. 

Or maybe I'm the crazy one?

there is no spoon

Wednesday, April 23, 2008 3:15:42 PM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [2]  | 
# Sunday, April 20, 2008

I was just reading the sermon Pope Benedict gave today in the Bronx.  The following struck a cord:

The Gospel teaches us that true freedom, the freedom of the children of God, is found only in the self-surrender which is part of the mystery of love. Only by losing ourselves, the Lord tells us, do we truly find ourselves (cf. Lk 17:33). True freedom blossoms when we turn away from the burden of sin, which clouds our perceptions and weakens our resolve, and find the source of our ultimate happiness in him who is infinite love, infinite freedom, infinite life. "In his will is our peace."

Real freedom, then, is God’s gracious gift, the fruit of conversion to his truth, the truth which makes us free (cf. Jn 8:32). And this freedom in truth brings in its wake a new and liberating way of seeing reality. When we put on "the mind of Christ" (cf. Phil 2:5), new horizons open before us!

I've thought about this seeming paradox on a few occasions--that real, radical freedom is found in truth and living in conformity to that truth. 

Loss of Freedom?
There's a common perception that morals, ethics, and religion in general limit our freedom--that we're sacrificing freedom for some greater good.  But we're not actually sacrificing freedom--we're still free to choose to think and act otherwise, however, we are using our freedom, choosing to live in accord with what we believe to be true.  It's a different way to think about it, one that puts it in the right perspective.  I think it is put in a negative perspective so often because we focus on the things we're not supposed to think or do instead of on what we are freely choosing--positively--to think and do.

The funny thing that I've found is that in choosing to align my beliefs and actions with Catholic doctrine, I feel far more at peace and far freer.  I think it is because if we're constantly struggling with the basic (but important!) questions of life, such as our origins, the existence of God and our relationship to the Divine, as well as our right relations with others, we never get off the ground, so to speak--we're always stuck in an infinite loop, wondering and (maybe) worrying, if we are conscientious. 

But if we settle all that, we're free to move on and explore new horizons.  Not only that, I think we are better equipped to explore those new horizons, because we are aligned with truth, with reality.

Mental & Conceptual Models
This reminds me of the idea in psychology of mental models and conceptual models.  My understanding, based on Donald Norman's The Design of Everyday Things (a.k.a., The Psychology of Everyday Things), is essentially that there is a conceptual model that designers create and use when they design and build things.  This is the actual and correct model.  Then there are mental models that users of the design form and use when perceiving and interacting with the design.

The trick in design is to sufficiently express the conceptual model (through a variety of design mechanisms like affordances, feedback, "knowledge in the world," etc.) so that users will form the correct mental model--one that closely aligns with the design's conceptual model.  The reason this is important is that it empowers the users to use the design effectively and not spend undue time and energy trying to figure it out, dealing with frustrations and inefficiencies that come from having a wrong mental model.  You could say that having the right mental model makes the users more peaceful and more free to explore other things because they don't have the frustrations and aren't wasting unnecessary time on it.

Applied Mental Models for Freedom and Happiness
Now map that to how we think and act as human beings.  Imagine that there is a correct conceptual model that specifies how best we human beings can think, act, and relate to others.  This model can be discovered through a variety of the Designer's mechanisms such as nature (e.g., affordances in biology), reason, experimentation (use & feedback both personal, scientific, and historical/anecdotal), and even revelation (documentation, as it were).  Now if we form the correct mental model, one that most closely aligns with the human conceptual model, it follows that we'll be more at peace (less frustrated), more efficient, more effective, and freer to explore other things.  In short, having the right mental model would give us the most radical freedom and happiness.

Wouldn't we be crazy not to use the human design in accordance with the right mental model, once we figure it out?  I think so.  For instance, once we figure out that our door key is inserted into the key slot in a particular way that gets us through the door in the least amount of time, we'd be silly--bordering on insane--to keep trying to use the key in ways that don't match that mental model.  We'd be wasting time, getting frustrated, and getting stuck outside!

No, once we discover the right mental model, the only sane thing to do is to keep using it unless someone comes along and demonstrates a model that seems to work better.  Doing this--adhering to this mental model--is not "blind faith," as many liken the faith of Christians (and others) to be.  On the contrary, adhering to a mental model that seems right  to you is pure sanity, absolute reason; doing anything else would be idiocy of the first degree.

Sharing Your Mental Model - The Right Thing to Do
It also follows that if you see someone standing outside a door, fumbling with a key, unable to figure out how to use it, that what else could you do but walk over, show, and explain the right mental model--the one that you've found is the most effective and least frustrating?  Would it be kind of you to just say "well, whatever that person believes is fine for them" and just leave them stuck and frustrated?  (I'd suggest not.)

So it is with those who share their faith, their mental model about life, the universe, and everything.  They think they've found the right mental model, the one that is most aligned with the ultimate human conceptual model, the one that if applied will provide the most peace, satisfaction, and happiness.  It is an act of kindness, an act of caring, indeed an act of love, to take the trouble to share such a mental model with others.  Correspondingly, it would be an act of meanness, selfishness, even perhaps of hatred, to not share it and try to help others to understand and use it.

So to those who think having faith is ignorant, blind adherence and loss of freedom, I'd suggest they reconsider.  Using the analogy illumined here, it seems clear that such faith is actually the opposite--it is wide-eyed, reasoned, experiential, and ultimately more radically free and more likely to provide lasting happiness (which is a goal I think any sane human being can agree upon, no?). 

Similarly, perhaps the most popular philosophical adage of our age--"what you believe is okay for you and what I believe is okay for me"--is not in actuality the most humane, reasoned, or livable approach.  On the contrary, it seems far more humane--even positively caring--to try to show each other why we think we have the right mental model.  It's something to consider, anyways.

Sunday, April 20, 2008 6:24:28 PM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, April 15, 2008

A few buddies of mine, Phil Winstanley and Dave Sussman, have asked me to pass along that they're doing an upcoming DeveloperDeveloperDeveloper event in Galway, Ireland on 3 May.  So on the off chance I have some readers in that area, I figured I'd pass it along.

Enjoy!

Tuesday, April 15, 2008 5:13:13 PM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 

I'm becoming more and more averse to the term architecture and architect in terms of creating software, partially because it is such an overloaded term that seems to cause so much continual opining about its meaning but, more importantly, because I don't think it is like what we do, at least not to the extent that seems to be commonly thought.

We are not building houses (or bridges, or skyscrapers, or cities).  Houses, and other physical constructions, rely on pretty much immutable laws of nature, of physics, chemistry, etc.  These sciences are sciences in the established sense--you can perform experiments repeatedly and get the same results, and others who perform those experiments will get the same results.  Physical building, architecture, and engineering is fundamentally a scientific endeavor because it is essentially serving scientific laws.1

Software Serves Human Social Needs
Software, on the other hand, is fundamentally a human and social endeavor.  Above the basic electrical and magnetic level, i.e., hardware, it is purely human constructs built on layers of human-created abstractions built to serve human social needs--for, ultimately, business or pleasure.  As such, we (as a human industry) are pretty much free to create the abstractions as we see fit. 

Beyond the basic hardware translation layer, we are not bound by elemental laws, only by our imagination.  The problem is, it seems to me, that early software development was very closely tied to the electrical engineering disciplines that gave birth to computing machinery, so the early abstractions were engineering-oriented and assumed an unnecessary scientific and engineering bent.  Subsequent developments, for the most part, have built on this engineering basis, and our educational system has perpetuated it.  Even though relatively few software creators these days need to understand the inner workings of the hardware (and even one layer of abstraction up), such low-level engineering is at the core of many computer science curricula.

As the power of computing machinery has grown, we've expanded the uses of software to take advantage of the new power, but we have remained an essentially engineering-based culture and have accrued other engineering-related words such as architecture and architect.  We have engineers and developers, systems analysts, and architects.  We have projects and project managers, and many try to manage software projects as if they were building projects.  We have builds, and we say we're building or developing or engineering software.

We have, built into our very language, an implicit association with physical building, and we have the association repeatedly reinforced by those who want to draw direct analogies between our trades.  Certainly, there are similarities, but I tend to think much of those similarities have been manufactured--they're not inherent to the nature of software.  We've painted ourselves into a corner by such analogies and borrowing of techniques and language.

Perceived Crisis of Complexity and Terminology
Now we're having this crisis, as some seem to paint it, where we need to elaborate further and push the idea that our systems are like cities and that we need varying levels and kinds of architects to help plan, build, maintain, and expand these software cities.  We have folks struggling to define what an architect is, what architecture is, and creating various stratifications within it to expand on this analogy.  We purportedly need enterprise architects, solutions architects, infrastructure architects, data architects, and more.

There is I think a well-intentioned effort to fix it because we do see this corner we've painted ourselves into, but we're reaching for the paint brush and bucket to solve it--reaching for those same ill-fashioned analogies, techniques, mindset, and culture.  We see all this accrued complexity, and our solution is to make things even more complex, both terminologically and systematically, because we're engineers and scientists, and scientific problems are solved with scientific methods and precision, no?.

It seems the underlying problem is that we're approaching the problem all wrong.  The problems we're solving are fundamentally human problems, particularly social problems.  And by social, I don't mean social networking software that is now en vogue; I mean social in the basic sense of dealing with interactions between humans, be that economic, entertainment, education, social connection, or whatever.  It follows, then, that the best solution will be fundamentally human in nature, not scientific, not engineering.

Realigning with Our Core Problem Domain
Maybe we should avoid likening ourselves to engineering and scientific disciplines, and especially, we should shun terminology that ties us to them and binds our thinking into those molds.  As a man thinks, so is he, as the saying goes.  Surely, we can and should learn what we can from other disciplines, but we need to be more reticent to insinuate them into our own as we have done with building.

I do think various solutions have been tried to better align software with its problem domain.  Object-oriented design is at a generic level an attempt to urge this sort of alignment, as is its more developed kin, domain-driven design.  Agile and its like work toward human-oriented processes for creating software.  Natural language systems, workflow systems, small-scale (solution-level) rule engines, and even some higher-level languages have attempted this.  And in fact, as a rule, I think they succeed better than those more closely tied to the computing and building conceptual models, except that even these more human-oriented abstractions are chained by the lower level abstractions we've created.

What we need to do is continue to develop those human-oriented models of creating software.  It seems that we may be at a breaking point, however, for our continued use of the building paradigm.  Our repeated struggles with the terminology certainly seem to speak to that.  Our terribly confused and complicated enterprise systems landscape seems to speak to that.  Our control-driven, formal, gated processes have been most well shown to be broken and inappropriate to the task of software creation.

New Terminology
To make the next step, perhaps we should reexamine at a fundamental level how we think about software, both the artifacts and how we create them.  I think we need to make a clean break with the engineering and building analogy.  Start fresh.  Unshackle our minds.  Maybe we need to drill down the abstraction layers and figure out where we can most effectively make the transition from hardware control to our human, social domain.  I imagine it would be lower than we have it now.  Or maybe it is just a matter of creating a better language, an intentional language (or languages) and a move away from our control-oriented languages. 

At a higher level, we certainly need to rethink how we think about what we do.  Some folks talk about the "architect" being the "bridge" (or translator) between the business and the technical folks.  If that is a technical role, which I tend to doubt, it seems like a more appropriate title would be Technical Bridge or Technical Translator or Technical Business Facilitator or even just Software Facilitator.  Call it what it is--don't draw unnecessarily from another dubiously-related profession.

But maybe thinking this role is best served with a technical person is not ideal.  Maybe we technical folks are again trying to solve the problem with the wrong tools--us.   Well-intentioned though many are, if we are technical in tendency, skills, talent, and experience, we are not as well equipped to understand the squishy, human needs that software serves or best identify how to solve such squishy human problems.

Since software is essentially a human-oriented endeavor, perhaps we need a role more like that which has been emerging on the UX side of things, such as [user] experience designer or interaction designer.  They are better-equipped to really grok the essentially human needs being addressed by the software, and they can provide precise enough specification and translation to technical folks to create the experiences they're designing, even with the tools we have today.

Then again, some say that architects are the ones concerned with high-level, "important" views of a solution, interactions among individual pieces, that they are those who model these high-level concerns and even provide concrete tools and frameworks to help effectively piece them together.  I say that we could call this role solution coordinator, solution designer, or solution modeler.  But then, according to folks like Eric Evans, these folks should be hands-on to be effective,2 which I also believe to be true.  In that case, what they become, really, is a kind of manager or, simply, team leader, someone who's been there and done that and can help guide others in the best way to do it.  At this point, the skills needed are essentially technical and usually just a matured version of those actually crafting the solution. 

Instead of software developers and architects, how about we just have technical craftsmen?  The term is appropriate--we are shaping (crafting) technology for human use; it also scales well--you can add the usual qualifiers like "lead," "manager," "senior," whatever fits your needs.  There's no unnecessary distinction between activities--whether the craftsman is working on a higher-level design or a lower-level, it is all essentially the activity of shaping technology for human use.  Depending on the scale of the team/endeavor, one craftsman may handle all levels of the craft or only part, and in the latter case, the division can easily be made based on experience and leadership.  And finally, it does not introduce cognitive dissonance through extremely-overextended and inaccurate analogy (like developer and architect).

Even if you don't like the term craftsman--we could collaborate to choose another that doesn't chain us to wrong thinking--the point remains that we should recognize that we've introduced unnecessary and unhelpful distinction in our discipline by using the dev and architect terminology.  We could begin to solve the conundrum by abandoning these titles.

Resisting the Urge to Rationalize and Control
Also, by looking at each solution as a craft--an individual solution tailored to address a particular human problem, it becomes clearer that we need not be so ready to try to rationalize all of these solutions into some greater system.  As soon as we do that, we fall back into the engineering and computing mode of thinking that will begin to impose unnatural constraints on the solutions and inhibit their ability to precisely and accurately solve the particular human need.3 

As I suggested before, we should rather treat these solutions more like a biological ecosystem--letting selection and genetic mutation mechanisms prevail in a purely pragmatic way that such systems have so well embedded in their nature.  I believe it is a misplaced good intention to try to govern these systems in a rationalistic, control-driven way.  We deceive ourselves into thinking that we are managing complexity and increasing efficiency when in reality we are increasing complexity that then, recursively, also has to be managed in such a philosophy (creating an infinite complexity management loop).  We also reduce efficiency and effectiveness (well-fittedness) of solutions by interfering with solutions with controls and imposing artificial, external constraints on them to serve our governance schemes.4

Wrapping It All Up
Once we stop trying to align ourselves with a fundamentally different endeavor--physical building--we free ourselves to essentially orient what we're doing towards the right domain--human social problems.  In doing so, we can re-examine our abstraction layers to ensure they most effectively fit that domain at the lowest possible level, and then we can start building new layers as needed to further enable effective (well-fitted) solutions for that domain.  By changing our language, we solve cognitive dissonance and illuminate where distinctions are truly needed, or not needed, and may even recognize where skills that are not inherently technical would better serve our solutions (such as UX pros).  And lastly, by treating the solutions as fundamentally human, we recognize that the most efficient, effective, time-tested5 and proven technique for managing them is more biological and less rational.  We see that they can best manage themselves, adapting as needed, to fit their environment in the most appropriate way possible.

If we're going to have a go at fixing the perceived current problem of complexity in software and, by extension, further understand how to solve it through our profession, I suggest that a somewhat radical departure from our current mode of thinking is needed, that we need to break away from the physical building analogy, and it seems to me that something like what I propose above has the most long-term promise for such a solution.  What do you think?

Notes
1. I should note that I recognize the artistic and ultimately social aspects physical constructions; however, they are still fundamentally physical in nature--bridges are physically needed to facilitate crossing of water or expanse, buildings are needed physically for shelter.  The social aspects are adornments not inherent to the basic problems that these constructions solve.  The same cannot be said of software; it exists solely to serve human social advancement in one form or another.
2. See Eric Evan's "Hands-On Modeler" in Domain-Driven Design: Tackling Complexity in the Heart of Software.
2. As an aside, I truly do wonder why we should have to try to convince businesses of the need for the "architect" role.  If you ask me, the need, and our value/solution, should be obvious.  If it takes a lot of talking and hand waving, maybe we should question if the solution we're proposing is actually the right one.  ?
3. I have to nuance this.  Obviously, if there are governmental regulations you have to follow, some such controls are required; however, if you think about it, this is still adapting the solution to best fit the human problem because the human problem likely involves some need of societal protection.  Certainly not all systems need such controls, and even only some within an organization need them.  Keep the controls scoped to the solutions that require them due to the human social conditions.  On the whole, I'd say that there are vastly far more systems that don't need them, though the ones that do loom large in our minds.
4. By this I mean to say that, according to evolutionary theory, biological processes have developed over many millions of years and have proven themselves as an effective means for highly emergent, living systems to self-govern.  Businesses and human social structures in general, especially these days, are highly emergent, dynamic, and living and need software that reflects that mode of being.

Tuesday, April 15, 2008 4:04:01 AM (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [1]  | 

Disclaimer
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.

Thanks to the good folks at dasBlog!

Copyright © 2014 J. Ambrose Little