With the economic downturn, financial pressures increases on technologuy budgets (whether commercial, large / small enterprise, startup or non-profit).Increased productivity + open source + prevalence in the ‘cloud’ (regardless of your definition of ‘cloud’) bodes well for the Rails + Ruby eco-system.I’m biased, as are the rest of us at FiveRuns - but we’re not the only ones saying this. 

So I’ve made the plunge and bought an iPhone. Half the joy is in using such a beautifully designed product – every aspect of the experience shows so much thought. I can only add my kudos, and continue to be frustrated at how low the standards are for so many products.

So in the physical world, there’s tremendous constraints placed on a system by existing infrastructure. It defines and limits what can be done without significant extra resources expended – which means cost, complexity, risk, etc.

In a recent issue of Wired, there’s an article about how a new city in China is being designed with what amounts to a well thought out infrastructure optimized towards energy use

It’s an interesting contrast between that approach and the agile software approach of evolving the infrastructure (and the approach to infrastructure that’s true for most cities as well). Of course, the infrastructure in software is much more malleable than the physical infrastructure of a city – yet there are still great costs and challenges with evolving software infrastructure.

Why haven’t we figured out how to make this easier?

Ok – so maybe it’s a sign of just how much a shiny-gadget-geek I am, but I love what’s possible with MacFuse (and MacFusion). For example, I have an existing website (at omnis.com) that doesn’t have a ssh account, so the only way to deploy / work on what’s there is via FTP. So when I need to work on it, I have to use FTP to push & pull code & data, but I don’t do it that often – so I’d have to right FTP client to do bulk transfer was a pain, etc. So now, turn on ftpfs via MacFuse and woila (as my 4 yr old says) – there’s the shooting match. Now, it’s an easy matter to bring it all back down locally, put in SVN (as it should have been years ago) and re-deploy to my new account at dreamhost.

No new functionality, just a greater ease of use – esp. since my muscle memory knows how to use either shell or finder interfaces to work with files.

Some ramblings on software development

A useful perspective on software devleopment is as an ‘integrated discipline’, i.e. a perspective that recognizes that software development is actually composed of three domains:

• Business – this is the domain of the problem
• Technology
• People – all the people involved, e.g. development team, customers, users, support staff, marketing, product management, etc.

Nothing here is new, e.g. Weinberg, Catalysis, Scrum, etc. all include some notion of these domains in their models. However, what’s confusing for me is how rarely this is recognized on all the different projects I’ve been involved. I don’t think this is just a function of how I choose a project – as I hear this from others as well. Typically, the recognition of this varies depending on who I’m talking with – e.g. developers recognize technology and business, but rarely the people; product owners recognize the business and technology, but rarely the people.

Why is this important? Primariliy because problems often creep in from the unrecognized (or recognized but less important) domain.

I’ve noticed that in the many organizations I’ve talked with, I’ve never really found any job titles that consistently appear to acknowledge this perspective. Occasionally, encounter some positions can described that way (e.g. architect, senior management, CTO), but there doesn’t appear to be a ready made & well recognized title.

Perhaps it’s a result of the perceived complexity of each domain, where the approach is to ‘divide and conquer’ the work into seperate roles. Personally I believe that this is an incomplete answer. The ‘divide and conquer’ approach works well for specialists that need to become strongly fluent in the extensive details in each domain. In this case, the differences are important – i.e. the patterns of action and subjects of action are unique within that domain. However, I believe that spanning all the domains there are patterns of action that are common, and that the unique aspects of the subjects of action are less important. Put another way – there are common patterns of doing things that can be usefully applied across multiple domains.

One concrete example of where this shows up is the role of architect. In software development, this is an overloaded term. For some, an architect (e.g. a J2EE Architect) is someone fluent with the unique aspects of J2EE. For others, an architect is soomeone fluent with the common very high-level design patterns and priniciples, which can be applied to different technologies as well as to businesses.

As a personal frustration, I often encounter the two being mixed up, e.g. in conversation expecting that they need an architect that spans multiple technologies and possibly business as well – and the conversation turns to how-to questions for a language specific library.

All the different levels are important, however I believe we need to revisit how we’ve ‘sliced the pie’. Specicically, I beleive we need more emphasis on the common aspects that span technologies as one ‘bundle’ of patterns; the common aspects that span technologies, business and people as another ‘bundle’, etc. The increased emphasis on these patterns willl create opportunities for greater breadth the roles (i.e. not tied to one technology)

As I interpret it, the agile versus formal debate is generally treated as an either or question. For instance, in any given software development situation there may be an assessment that it would have worked better if only an agile approach was used or for a project like this, you must use a formal approach. Only rarely does there seem to be an advocate that suggests integrating aspects of both approaches.

Inevitably, this has resulted in religious arguments about which approach is better, and religious arguments are usually from an absolutist’s perspective.

A funny thing happened on the way to resolving this issue; some folks with poor practices attempt to partake of any legitimacy that the agile approach offers by reinterpreting their practices as agile. Their approach is to elevate any poor practice they have as really being agile. Equally confused, other folks have taken genuine successes from the agile approach and reinterpreted them as luck, hacking, or some other variant of happenstance. Their approach is to reduce any agile success to at best the results of wishful thinking.

What do these two different groups of people, the elevationists and the reductionists, have in common? Both of these groups have a perspective that only allows for two levels of software development: lets call them conventional and non-conventional.

• Conventional: formal or heavy approaches, e.g. Rational Unified Process (RUP), CMM, etc.
• Non-Conventional: anything other than conventional.

My argument is that one significant limitation to resolving this issue is the two-level model, and that by reinterpreting the evidence using a three- (or more) level model, a path towards resolution becomes visible.

In addition, this re-interpretation can be shown to be an instance of a concept identified by Ken Wilber and named the ¿pre/trans fallacy¿. While this think piece is about software development processes, the subject area that the pre/trans fallacy originally referred to is much more universal and significant, that of human consciousness (e.g. Ken Wilber Online: Introduction to Volume 1 of The Collected Works). The pre/trans fallacy is part of a larger model called the Integral Model [need citation].