Thanks for the comments. I really appreciate your final comment! I'm a big proponent of good engineering practices over bureaucratic engineering processes!

True enough: the article on Kuro5hin is very old... I've often thought of writing an update to take in to account some of the things you mention. (Actually, it's hard to believe I wrote that 11 years ago!)

Still, I feel that most software architects really inflate the importance (and time) of their jobs. It's true that there is some amount of legitimate research to be done in exploring the broad outlines of your solution. However, most of the time those solutions are dreamed up by the architect in a few hours and then they spend months doing confirmatory biased research to flesh out the justifications for their original idea. That's the waste. As the plover said, all that knowledge about design patterns, etc. is still applicable. Just don't do it in a big up-front fashion.

Two articles that I wrote about this:

The Software Construction Analogy is Broken

and

Technical Push-Back

I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.

I'm not confused. I just assumed that people could make a small mental leap: Working software = (functionality + quality + ease of use) whereas comprehensive documentation = waste in order to accommodate for lake of ease of use or poor quality. I hoped that the functionality and quality part of working software would generally be understood without me needing to be pedantic.

I'm guessing that there aren't a lot of people on Slashdot who are both users and developers for Odoo / OpenERP. I am. I am also formerly a UX expert (late 90's, but I keep somewhat up-to-date), and I am currently an active developer and consultant. I have some very specific views on this based on my background.

1. In the Agile manifesto it says "Working software [is valued] over comprehensive documentation." That has always meant, to me, that UX takes priority over user documentation. I've seen Agile teams kick the snot out of competitors by focusing on UX and foregoing nearly all user documentation. When I say "nearly", I mean that a very high level (well written) orientation document, is sufficient.

2. For this system itself which is a complex ERP system, there are four levels of "documentation" possible: a) User Documentation b) Configuration Documentation c) Customization / Plug-in Developer's Documentation and d) Internal Development Documentation. Since Odoo is open-source, in a way, all of these levels are "user documentation".

3. UX absolutely needs to be the one and only factor in considering the end user experience of an already-configured system. There shouldn't be any need for an end user to go to a user manual unless an organization has done extensive configuration / customization (in which case that organization has the responsibility for the documentation, not the Odoo organization. Likewise, UX should be the main approach to making configuration easy, but there may be some scenario-based examples documented to help orient those who are doing the configuration. These are your day-to-day admin users. The marketing automation module is a good example of where UX sucks and the documentation is poor. Given the choice, I would much prefer the UX to be improved!

4. For customization and internal development, there is still a role for UX to play, but (knowing the actual state of the documentation) you must improve that documentation dramatically. It is sparse and hard to follow, hard to find the right information, and often has very old / outdated screenshots. Although what information there is seems to be accurate, there are often huge gaps, and many undocumented api's and options. I know this because I have had to struggle through creating custom modules by reading through reams of source code in other modules. Love that it's open source, hate the quality of the developer documentation :-)

As a sideways promotional plug, our Scrum Team Assessment tool is built on OpenERP 7.0.

That's a veiled ad hominum argument - a logical fallacy. Just like you have asserted that someone should read Coyle and Dawkins, you in turn might consider setting an example by examining the arguments of Dr. Goswami.

FWIW, I haven't read any of these references, but I have read extensively on all sides of the argument including evolutionary biologists, intelligent design proponents and other non-standard models for what we observe. I've read other Dawkins books and found them to be just as weak as many of the ID books. As far as I can tell, it's all still philosophy, and the science that we have, namely molecular biology, breeding and the fossil record do not show evolution as the conclusive final word on how life works.

I have no idea if this would help, but with developments in solar technology, would it make a significant difference if the tops of the wings, fuselage, tail and fan ducts were all solar panels? Seems like a simple thing to do to help with range... maybe not done because it's not reliable.

I've been faced with this kind of decision a number of times. I always remember: if I'm not filthy stinking rich right now, then I'm probably bad at predicting the future. Any attempt to do so should be taken with a huge dose of scepticism.

That said, I think that the practical answer is simple: invest a bit of time doing a bake-off of the likely candidates. Try to choose some real high-priority business features, and then get very small teams of 2 or 3 people each to use each of the frameworks to build production-quality functionality for those business features. Don't take more than a week to do this. To use your example, Flex vs. HTML5, you would get two small teams to try to build the _same_ functionality using the two different frameworks.

Evaluate your results based on how much the teams actually got done. (Remember: production quality, not prototype quality.)

Since you can't predict the future, I also strongly recommend good Agile Engineering Practices to help to build a system that is not just change-tolerant, but is actually easy to change.

That is cool! I'm sure that in the distant future when we get to actually explore these places (probes or human explorers), that we will find all sorts of nifty things... and probably discover all sorts of ways in which we are wrong :-) I wish I could see that future!

I'm curious: what are the likely elements and molecules that would cause the blue reflection?

Here is an article I wrote a few years about about this. Probably helpful: http://www.agileadvice.com/2012/01/08/scrumxplean/seven-options-for-handling-interruptions-in-scrum-and-other-agile-methods/

This is a great way of describing Scrum, but I would be more clear about the fact that Agile != Scrum. Agile is the abstract base class (or maybe even just an interface/protocol) described by the Agile Manifesto: http://www.agilemanifesto.org/ and Scrum is a subclass that implements/extends Agile.

That said, the yardstick analogy is great and I'm going to use that right away in a class I'm teaching about Scrum!

Thanks!

PS. BSP below...

I agree that it is a long process... possibly centuries (although I hope just decades). I'm an optimist at heart! One quote that I have found particularly inspiring is:

"The betterment of the world can be accomplished through pure and goodly deeds, through commendable and seemly conduct."

To me, that means that all the people who are trying to improve the world (the environment, politics, community life, etc.), and even my own modest efforts, are having an effect.

In our culture, we are afraid of abuses.... legitimately! Having this information for sale can easily be used for such obvious purposes as rejecting a job candidate because their past salary is "too high". Stronger privacy protection is generally considered the antidote to such potential abuses. However, more and more regulation leads to greater and greater bureaucracy and therefore the cost of government increases.

Another solution is a longer-term solution and that is to address the underlying cultural assumptions and shift the world to a more positive outlook based on the idea of the inherent nobility of humans. Our bureaucracy has grown as we have moved away from a perspective on the noble human to the animal human with greed motivating our every move. In fact, this is a cultural choice, not a foregone conclusion.

At some point, I hope that we (culturally) will start responding to these sorts of crisis with a long-term view to improving humanity rather than reacting to the down-side.

I was wondering what axioms you hold to be true? Any rational system has a set of axioms that are the unprovable foundation of that rational system. What do you believe on faith?