Some favorite portions:

“A mess is a reckless debt which results in crippling interest payments or a long period of paying down the principal.”

“The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small – such as if it were in a rarely touched part of the code-base.”

“Not just is there a difference between prudent and reckless debt, there’s also a difference between deliberate and inadvertent debt. The prudent debt example is deliberate because the team knows they are taking on a debt, and thus puts some thought as to whether the payoff for an earlier release is greater than the costs of paying it off. A team ignorant of design practices is taking on its reckless debt without even realizing how much hock it’s getting into.”

“while you’re programming, you are learning. It’s often the case that it can take a year of programming on a project before you understand what the best design approach should have been. Perhaps one should plan projects to spend a year building a system that you throw away and rebuild, but that’s a tricky plan to sell. Instead what you find is that the moment you realize what the design should have been, you also realize that you have an inadvertent debt.”

The document is approaching 150 pages and beginning to approach something that properly describes the vision and needs so that business and technical folks can have a solid understanding of scope, requirements, priorities and how it will work (plus general direction on how it will be built).

It takes a lot of effort and time to sit down and not only read, but understand the scope of this system. It’s not a simple thing. As much as we try to keep it conceptually simple, there’s a lot going on and a lot of details.

In a few weeks I’m to sit down with a partner team to review and collaborate. My plan was to send over the detailed document for review so we could have a productive meeting to truly discuss missing requirements, strategy, execution planning etc.

However, I’ve been told they don’t “want” to read the detailed version — just a summary — bullet points with perhaps 10-15 pages.

These are senior developers and architects. Not high level business folks.

Attention to detail is in my opinion an absolute requirement for technical people. Decision making without details is dangerous and fairly useless.

My opinion is not high for people who do not care or have the attention span to be detail oriented.

An executive who’s not directly involved in the operations of something – a summary makes sense.

A team or person who is supposed to directly impact the design and delivery of something and its ongoing operations – if the details aren’t part of their focus, they don’t deserve to be involved.

If they don’t have the time to be detail oriented, then either they shouldn’t be working on the project, their time needs to be re-prioritized, or the project isn’t worth doing.

I have read comments from companies such as Google and Amazon how the performance of an application can dramatically affect how much people use it. I agree. The slightest friction in searching makes me search less, or shop less, etc.

This past week I’ve been using the new iPhone 3GS which is at least 2x faster than the previous iPhone 2G I had. In some cases it’s 4x and 6x faster.

I already used the iPhone a lot. The increase in speed has further reduced the “friction” of use to the point that if I even have a thought of quickly looking something up or performing some other action, I am much more likely to do it.

On my last iPhone, I consciously chose to not bother at certain times because of the time it would take. Yes, I’m talking in seconds and even milliseconds here — but when it’s a “thought”, if the tool doesn’t work at the same speed, then it’s friction. Same goes for another application I use which involves looking up reference materials and documents. Before I kind of had to avoid “flipping around’ while someone was referring to things. It was actually faster to use the paper documents. Now, I can keep up or be faster with my iPhone than the paper version ‘users’. Therefore it encourages use.

The new user experience of using the iPhone 3GS, so significantly improved just by the performance improvement, has reminded me as a developer and architect how critical it is to design, plan for and develop to achieve high performance. Functionality isn’t enough — we should be aiming for the “speed of thought”.

Interestingly, Google has just launched a new site just for “speeding up the web“.

The following video shows “the experts” talking about how the human mind perceives changes of 100ms (one tenth of a second).

It’s my belief that this isn’t just a “nice to have” feature. If a product, service or application wants to be adopted and deemed “necessary” by its users, its performance must reduce friction as much as technically feasible to the point where it approaches or achieves “speed of thought”.

IBM Support Link

Two JVMs with different contexts but the same domain now use the same jsessionid so they can talk back and forth in the same browser without jsessionid schizophrenia.

• Purpose of this Document – why write the doc
• Stakeholder Chart – whose needs are being met with the solution
• Signoff Chart – timestamp and id of person who signs off.
• High Level Platform Capabilities – the solution capabilities demanded by the business
• Business Drivers for the Capabilities – the list of business programs or business teams that will use the system
• Capability Demand – which business are asking for which capabilities. An interesting grid.
• Technical Interdependencies – what other systems rely on this solution. What other systems does this solution rely on?
• Enterprise Architecture Concerns – what agreements have been made with EA to get alignment of the solution to EA standards.
• Architectural Context – one or more diagrams showing how the solution platform will evolve over time.
• Methodology – how this document and concensus was created. What meetings were held. Who was in the room. (it matters)
• Roadmap schedule – what timelines everything thinks are reasonable for delivering the needs to different business customers
• System Quality Attributes – what quality attributes will be stressed in each of the iterations.
• Alternatives considered – what alternatives to this roadmap were considered and why this one was chosen.
• Roadmap Risks – what could go wrong and who is assigned to watch for it
• Platform Historical Narrative – previous decisions and narrative so that we can always answer the question: how did we ever get in a bind like this?

I’ve been playing with Magnolia and so far am fairly impressed with how it works — though not so impressed with the backend repository which in this case is JackRabbit, the open source reference implementation.

It appears though that for a fairly reasonable price I can get the Enterprise version of Magnolia that uses the commercial JSR-170 compliant repository from Day (http://www.day.com/site/en/index.html). It sounds like it should be MUCH better … and is very likely what all the big name companies use that Magnolia lists on their site. I’ve requested them to contact me but haven’t heard back yet.

JSR-170 definitely is sounding nice … though it seems like it still has a way to go before it fully matures as it’s quite new.

Also, the opensource community obviously has not had enough time to make a decent enterprise implementation, as Jackrabbit doesn’t cut it. For example … I have the system running with JackRabbit … it only support filesystem persistence right now, so I try to connect another client to it and …. it doesn’t work ( the files are locked) …. so that means it won’t work so well except for small things.

Also, I see no nice way of connecting remotely to the repository using the open source version of Magnolia.

I’ll continue researching this in the coming week.