Additional Complexity, Enemy of Basic Purpose

Religion rarely intersects with technology. But many years ago, TheHackerCIO was struck by a parable from some religious presentation. It captures a problem and capsulizes an issue in such a striking way, that I mention it today. The author is, apparently, anonymous, so Google for a source:

The Parable of the Lighthouse

The two men stood on the high cliffs, "What do you think John?" The other man listened to the night and answered, "It looks like we might have another one." The first man nodded his head, "Aye. And it's the third shipwreck this month. I'd best get the crew."

He ran down the beach to a small lighthouse and pounded on the door. "Time to be moving boys; there's a wreck up near the north cliffs." The life-saving crew tumbled out of the lighthouse, and plunged their little boat into the waves with amazing skill.

Such tragedies often struck that lonely coastline; a sudden shift in the winds, or a thick fog rolling across the water and an unlucky ship would slam into the reefs, its hull slashed by the rocks.

The cry would go out, "Abandon ship!", but no sooner had these words left the captain's lips than the lantern of a life-saving boat would appear in the darkness, leading the wrecked seamen to safety.

The little lighthouse soon grew famous. Each day, it seemed, there came a new knock on the door: "I've come to help! You saved my son's life and I want to be part of your crew!" or "Please take this small sum as a sign of my gratitude."

The lighthouse was a crude little life-saving station. The building was just a hut, and there was only one boat. But the few devoted members kept a constant watch over the sea, and with no thought for themselves they went out day and night, tirelessly searching for the lost.

Many lives were saved by this wonderful little station. Some of those saved, and various others in the surrounding area, wanted to become associated with the station and gave of their time, money, and effort for the support of its work. New boats were bought and new crews were trained. The little life-saving station grew.

Some of the new members of the life-saving station were unhappy that the building was so crude and so poorly equipped. They felt that a more comfortable place should be provided as the first refuge of those saved from the sea.

So they replaced the emergency cots with beds, and put better furniture in an enlarged building. Now the life-saving station became a popular gathering place for its members, and they re-decorated it beautifully and furnished it as a sort of club. And so the Lighthouse Society was formed.

Less of the members were now interested in going to sea on life-saving missions, so they hired life boat crews to do this work. The mission of life-saving was still paid lip-service, but most were too busy or lacked the necessary commitment to personally take part in the life-saving activities.

The years passed, then one rainy night the Society was holding its annual formal dinner. The guests were dining by candlelight and dancing to a string quartet when suddenly, "Look, a red flare over the sea!"

The hired crews brought in boat loads of cold, wet, and half-drowned people. They were dirty and sick, and some of them had black skin, and others spoke a strange language. The beautiful new club was considerably messed up, so the property committee had a shower house built outside the club where victims of a shipwreck could be cleaned up before coming inside.

At the next meeting, there was a split in the club membership. Most of the members wanted to stop the club's life-saving activities as being unpleasant, and a hindrance to the normal life pattern of the club.

But some members insisted that life-saving was their primary purpose and pointed out that they were still called a “life-saving” station. They were finally voted down and told that if they wanted to save the life of all the various kinds of people who were shipwrecked in those waters, they could begin their own life-saving station further down the coast. So they did.

As the years went by, the new station experienced the same changes that had occurred in the old. They evolved into a club, and yet another life-saving station was founded.

If you visit the seacoast today you will find a number of exclusive clubs along that shore. Shipwrecks are still frequent in those waters, only now most of the people drown.

I particularly love the happy ending!

This is, of course, what has been happening over the last two decades of java's development. We've seen the hyper complexity of the EJB 2.0 grow, then fall by the wayside as POJO simplified things a bit. But we've also seen the hideous addition of Generics with full backward compatibility to nonsense, and with v. 6 we got the fragmentation of annotations alongside of xml.

I hate xml, so I'm not unhappy to see annotations as a replacement. But when everything gets larded in as an option, the complexity just gets harder and harder to track. Used to be, you had a lone web.xml file to grasp, to figure out your deployment descriptor. Now you have to check each web-fragment.xml, together with their "orderings," as well as the web.xml, and it's "absolute orderings," not to mention all of these, in turn can use annotations and the Java configuration API.

Did we really need all those options, just to deploy a Web Application? Or is it just what I call the Creeping Monster of Unnecessary Complexity?

I Remain, Going Back to Basics, as ...

TheHackerCIO

The Tribulations of Developers

... more about the book our GeekyBookClub chose last time around. I'd have voted against it!

DevTalkLA at last Tuesday's meeting wrapped up the last chapter of Data & Reality, a supposed classic by William Kent. The book proved highly disappointing. It's a kind of skeptical look at data modeling. Skeptics are generally annoying. If data modeling can't be done (objectively), what kind of practical advice does he have to offer us for doing it? Why bother?

This, for example, is from his concluding chapter, entitled "Philosophy":

"So, at bottom, we come to this duality. In an absolute sense, there is no singular objective reality.  But we can share a common enough view of it for most of our working purposes, so that reality does appear to be objective and stable." [p. 149]

What rot! If there is no objective reality at the base, how the devil can anyone share a "common enough view" of such a non-existent-thing in order for it to magically appear to be a thing, let alone an objective and stable thing?

And if we operate on the (supposedly naive) view that there is an objective reality at the base of what we do, and we do this because we *have to*, then what is the point of removing the naiveté?

Anyway, luckily, this rubbish book is now behind the group. And, also, the side-bar conversations were stimulating as always.

In fact, the great lament of the book club was related to timing. One member noted that the next book, RESTFull Web APIs, which looks extremely promising, was wonderful, but he needed to have read it several months ago, when he encountered these issues!

And TheHackerCIO, also had similar experience, with the Java Performance Book. I came to know about the book through DevTalkLA, and when I got it I realized that the client I had been building a performance engineering environment for would have gotten an order of magnitude better job out of me, if only I had read the book at the time I began the project!

But, such lamentations, trials, and tribulations are part and parcel of the life of the Hacker. We can only know about what we know at the time we know it.

I Remain,

TheHackerCIO

Continuous Improvement for the Self

Yesterday, in discussing the "Close the Loop" principle, TheHackerCIO touched on how one is worse off for not addressing deficiencies. It's simple, really. Not only do you now have a known deficiency, but you also know that  you are the kind of person who doesn't fix problems. (At least with respect to this problem.) And that is setting you down a course of habitual non-fixing problems, which is nothing but a downward spiral.

Don't go there.

There are many applications. For instance, how many times, O fellow Hackers, are you compelled by deadline-pressure and/or management to employ what we might humorously call a "sub-obtimal" solution or approach. In other words, we put in a hack, or a "work-around," or take on "technical debt."

Now, the reality of life is that this is always going to be there. But it should be tracked and a solution found for the future. This is they way to move yourself toward the elimination of such issues.

I keep a page in my client-journal where I track everything I've done that I'm unsatisfied with. I just label it my "Technical Debt" page, and make sure I log it. And, naturally, from time to time, when time permits, I come up with remediation approaches and solutions. Even if I can't get them into production, I've at least "closed the loop" on the issue. And so, on a personal level, I have improved myself. Which, by the way, is a very selfish thing -- in the best possible sense.

I hope you too choose to improve yourself. You'll find yourself a much better technologist for it.

I Remain,

TheHackerCIO

Closing the Loop

Recently a junior developer asked me one of those rarest of questions: the questions about how to improve. He's a very talented developer; and in a few years he's going to be awesome. But there was one chink in his armor I thought he should address.

And there are plenty of others who would benefit from this advice.

As a matter of fact, I could produce a major list of ex-clients and the vast majority had never grasped it. 

The principle is very simple. But the benefit comes only from the rigorous, regular, -- even habitual --  application of it.

The principle is: always close the loop. 

Here are a few examples.

If you go for an interview, afterwards you must sit down an and write up every missed question and failure. You must assess the gaps in your knowledge, or presentation and close the loop. Closing that loop might involve learning the answer to a question you missed. It might involve developing a small sample program to recursively traverse b-tree, because that's what you messed up on.  It might be a matter of reflecting on all your past experiences and determining what the nastiest bug you ever encountered was -- because you drew a blank when hit with that question. The point is, that you must always close the loop. Address deficiencies so that they are never repeated.  By following this policy, you will root out deficiencies and remediate them. 

If you fail to close the loop, you will undercut your self-confidence. Your own mind will know, implicitly, that you didn't take care of business, and that you have a deficiency of which you have not undertaken remediation. That means, without closing the loop, you are worse off for your bad performance. Not only do you have a flaw, but you know it, and you didn't care enough to fix it, or start fixing it.

The violation of the closed-loop principle seems institutionalized in many companies. "Let's move on, " they say. "There's no point in doing a full-blown investigation of why this happened." No?  Seems like the point would be identification of the problems that led to the debacle, followed by instituting a plan to avoid it in the future. Without closing the loop -- doing a post-mortem examination of failure -- assigning blame, where blame is due -- every future action is subject to the same causes. And, naturally, the same effects. 

So alway, always close the loop. And of course, you can use your techno-journal to help.

I Remain,

TheHackerCIO

I'm not asking *For* a cable; I'm asking *About* one

Ahhhh, The trials of boutique consulting!

Upper Service organization management decreed to TheHackerCIO that "You are to make no further requests for anything, until further notice. Just keep your head down and do your work. Let us make the requests for things to the end-user." So, all requests for things ended.

But progress was most crucially being held up for want of an ethernet cable! It went like that nursery rhyme:

• for want of a cable, the device to server went unconnected ...
• for want of a connected server, the testing became deferred ...
• for want of testing, the delivery was impeded ...
• for want of delivery, the project slipped ...
• for want of completion, (not the battle, but ...) the contract was lost!?!?!?

TheHackerCIO is not for losing a contract. Not on my watch. So he bought one. But he made a crucial mistake ... 

He mentioned in an email that he already had a hub and cable to resolve the connectivity issue. 

So another edict came down "All devices installed on the network must be approved first by the CTO." Damn. He was now forced to reply, "The devices which would resolve this issue are now locked away in my desk, unopened and not to be used until further notice." Double Damn.  Even just the cable would have helped, but now it was out of bounds. 

This is why people hate the pathological politics of the Bloated Behemoth Enterprise!

Luckily, a friendly network tech stopped by in the break room as I and an honorable colleague were getting a cup of coffee. "Anything you need?" He asked. So TheCraftyHackerCIO replied as follows:

"We could really use an Ethernet cable. But we have been instructed not to ask for anything. So I'm not asking for an Ethernet cable; I'm asking about one. What do you think?" He nodded with a grin. And so the problem was solved. 

The immediate problem, that is. The problem of Bloated Behemoth Enterprise pathology remains. Always. 

I Remain,

TheHackerCIO