Add another to my bounty of reasons for avoiding Javascript. This is not a problem with Javascript as such, more-so a problem with web functional testing tools. Still if you don’t use Javascript, you won’t have these and many other problems the most notably being cross-browser compliance issues.

So, to the problem; In my efforts to grow a virtually non-existent set of acceptance tests, I was after a way to disable Javascript in JWebUnit. Google told me this:

HttpUnitOptions.setScriptingEnabled(false);

Great, that was easy.

It seemed to work. Then enter ludicrously complex Javascript date selection pop-up. It appeared as if scripts were running again, so I investigated and discovered on each of the following WebResponse methods HttpUnit reloads all page elements, including attempting to load and execute scripts *Deep Breath*:

getForms, getLinks, getApplets, getImages, getTextBlocks, getTables, getElementsWithName, getElementsWithAttributes, getElementNames, getElementsByTagName, getElementsWithID, getFrames

Phew! That’s plenty of opportunity for a page to get reloaded. Given it’s possible to invoke these many times interrogating the one web response, how can this strategy be a good thing? Why re-assemble the entire page just because I want to retrieve elements by id for instance? If the answer is ‘Just in-case Javascript has done it’s dirty-work in the meantime’, damn, I hope there is a better way. Surely the performance effects are very significant. Significant enough to at least make you think twice when tempted to use these methods.

So add another to my pile of reasons for hating Javascript. Oh, and does anyone have any idea why disabling Javascript in HttpUnit does not disable this reloading feature? Any answers much appreciated.

Serial circuitry is simple but very fragile, a failing link causes the entire circuit to fail.

A serial circuit operators life is made that much more difficult by the added maintenance burden this imposes – of having to check each component to ensure the circuit does not fail. Essentially it’s a dumb circuit that requires constant management. An operators time is quickly consumed managing the circuit.
What if the circuit components had added intelligence allowing them to diagnose their condition? The simple circuit model is still in-tact, each component relying on the others, but the operators life is made that much easier.

This theory is no stranger to the automobile industry. For decades they have provided facilities for vehicles to self-diagnose problems in all aspects of vehicles, from engines to tyre pressure.

Why hasn’t this theory been applied to software? How much easier would administrators lives be with self-diagnosing software, applications that can express their condition through a convenient interface? I’ll make some analogies between the software and automobile industries to highlight how we’ve dropped the ball:

• Applications are diagnosed by simply starting the engine and seeing what happens.
• Applications are typically more complex in nature than automobiles. Interestingly though application administrators are usually as ignorant as automobile operators when it comes to inner workings.

This is an intriguing topic. Why haven’t tools surfaced that more easily provide this capability to applications than via custom development? Perhaps software is less prone to failure than vehicles? As intriguing as it is, I digress from the main point of this entry.

The basic theory behind the chain and link analogy is that each link knows itself best. Each is best at informing the other links of its condition and its connecting points (interfaces). It’s classic OO theory – data is held, managed and encapsulated by each link to form the chain.

10 years ago Brooks made reference to this principle in the context of management styles – he titled his section on this topic as The Power of Giving up Power. The theory was that management should delegate as much as possible to its subordinates. He highlighted the net result is increased morale, freedom, creativity, productivity and a greater capability of management to manage the whole operations as it’s less concerned about the inner workings of its parts. Indeed, management has more power in managing the organization as a result. I couldn’t agree more. It’s a very generic, simple theory that applies to life in many ways.

For software project management, I see these subordinates as groups of analysts, developers and testers. Each of these groups knows best how to efficiently integrate with the others. Why not trust in their knowledge? Rely on them to integrate with the other groups in a way which best suites them. Let them tune their practices in-line with the overall methodology in a way that’s best for them. Give others the opportunity to advise and negotiate especially on the touching points with other groups, but never dictate. That is a sure recipe for disaster leading to probable inefficiencies, distrust and disenfranchisement. Management should clear it’s vision of ‘this group should do A, B and C to produce X, Y and Z’. Instead management should be concerned about articulating what needs to be produced and leaving the groups to decide how best to produce it. Let them hopefully reap the benefits Brooks mentioned as a result. This principle should be the guiding principle when formalizing any methodology.

And if you’re inclined to dictate to a link because it is not smart enough to know, then perhaps that link needs an upgrade – they may lack the experience needed to do their job well.

Why make life hard for others without good reason? It’s just plain old negligence!

Consider the metaphor used by Brooks regarding essential and accidental activities from the point of view of an employees day-to-day tasks.

The essential tasks are those that are an employees primary concern. For a developer this is as simple as correctly expressing requirements in code in an organized fashion. Any tasks that are a consequence of the essential are accidental. For a developer fixing technical bugs would be accidental. Consider it wheel spinning.

The more time consumed on accidental tasks, the more ineffective the employee. It’s a sure sign that something is wrong either in process or personnel.

If an employee is aware that a decision will generate accidental activities then there better be a damn fine reason for it, otherwise cry negligence! Sometimes being unawares of this is bad enough as some accidental activities are simply unacceptable, for instance fixing transaction ACIDity post-production. In such cases if you are aware of these problems and your position suggests you must act on it, doing otherwise is the grossly negligent and your neck should be at risk.