Pages

Saturday, October 5, 2013

The Love-of-my-life asked me, "Don't you run out of things to write about? How do you pick what to blog about?" And TheHackerCIO replied to her, "I write about whatever pisses me off!

"And that's an renewable resource."

Inexhaustible.

To adapt the banner tag from the New York Times, TheHackerCIO blogs "All the News That's Fit to Piss Me Off."

One of my business development partners told me, "At client X, it seems that the every project originates from anger! Someone important gets upset and then a project to correct it is started."

It might not be the best way to organize development management, but it definitely ties requirements back to values and priorities.

These two stories illustrate a central point about development. It is the frustration of values that brings about the need for creativity and work. That's why requirements are inexhaustible. So long as not everything imaginable is now achievable, we have work. We have requirements. We have User Stories; and a Product Backlog. And the only way to level these requirements to the time available for programming is by the mechanism of cost. The inexorable law of supply and demand is what reduces the infinite demand for new features to the limited supply of programmer labor. The Agile technique of bidding points -- a form of estimation -- against User Stories is a wonderful mechanism for directly linking the demand for requirements to the supply of programmer labor.

Since programmer's backgrounds are not all created equal and since the "requirements" are not standardized commodity contracts, like Pork-Belly Futures Contracts on the Chicago Mercantile Exchange, we need a way to standardize them and price them. And this Agile technique is the best such pricing mechanism I've seen in any methodology. It directly addresses all the issues, and with a direct tie back to the bidder. The programmer has "skin in the game." The winner, after all, must deliver the User Story in the time he bid.

But this doesn't reduce the total anger, because every new feature leads to the imagination of ten more! Or a hundred!

Friday, October 4, 2013

This blog is all over the place. One day it's about Startups. Another, on Strategy. Then it's Clojure, followed by the Java Garbage collector. But it's all about technology. In one way or another. That's because technology is all over the place! In our time, it is the Great Enabler. As well, as the Great Disrupter. And its pace of growth, rapidity of change, and breadth of spread is truly breathtaking.

Even six or seven years ago, who would have thought that they could with one Git Push command spin up a web-site complete with a database backend and configured, in turn, to spin up possibly thousands of servers to handle a spike in popularity, then shut them down as the spike ended and bill only for the amount used. Yet that is what I saw done in a under a day at a Hackathon a few months ago.

It wasn't that long ago that everyone was impressed with million row tables in a relational database. Now companies routinely process data that makes that seem puny by comparison. Most every reader knows that a Terabyte is a thousand Gigabytes -- soon they'll be getting Terrabyte drives in their laptops. And of course a Petabyte is a thousand Terabytes. And Google processed 24 Petabytes of data every day. Furthermore, that was 4 years ago!

About a decade ago, it was cutting edge to have systems with millions of users. Now, TheHackerCIO has been brought in to architect systems that would scale to hundreds of millions of users!

TheHackerCIO is the Universal Man of Technology. And beyond! He has to be. Because to rise to the senior level of a CIO, that is, to employ a Karate metaphor, the level of "Grandmaster," one must master many styles, many techniques, many forms. Technology can not be compartmentalized.

Those who remember their history lessons will recognize this as the renaissance ideal of a "Universal Man." And we are definitely in a revolutionary period. Not the Renaissance revolution of learning; not the Scientific Revolution; not the Industrial Revolution; but the culmination of all these: the Technological Revolution. This revolution is similar in many ways to the revolution of the Renaissance -- we're in a similar growth period today. It's not a rebirth, because it has never been born before. But technology is disrupting every area of business and culture. It's even disrupting itself. How many technology companies have become sleepy backwaters, while free services (i.e., Google, Facebook, Twitter) have overtaken them and become dominant technology innovators? But that's a topic for another day, another blogging.

So this blog must track all of the dizzying, changing technology. But at least it's fun! And interesting!

Thursday, October 3, 2013

Yes, I know there are more in South Bay. There are more in Pasadena. There are more in Santa Monica, who never actually meet, anymore. But I challenge anyone to total the numbers, adjust them for population and offer me a comparison as a counter-example. I'm not holding my breath.

Then examine the schedule of talks, activities, Hack Nights, and meetings in London and compare it to what is available in the superset of Java Users Groups in LA.

Now you will understand why I rave about the vibrant Technology scene of London.

I've worked in London twice, for a total of about 3 years, and as a Technologist I've never had a better experience. When I convince someone in the UK that my approach is superior, even if it is marginally more expensive (anywhere up to 25%) or will marginally set back the delivery dates (again, anywhere up to 25% slippage), then my case is concluded. The decision is almost automatically in favor of the superior approach, because of the long-term benefits.

Has anyone ever experienced this in the US? I only ask for information, as Marvin would say.

I've often heard that in LA it's too difficult to commute to the other side of town for a technical presentation. But in London, the commute isn't all that easy. No one actually lives in London, and clearly the Java Meetups are not that convenient for everyone. And it doesn't take any effort to click a few buttons and at least join the Meetup, getting your name on the list.

But there is the hard, numerical evidence right for everyone to see.

LA does have a lot of interest in the User Experience Meetup: 2943 Members. Which means that LA has a peculiar interest quite different from London.

Wednesday, October 2, 2013

TheHackerCIO is fluent in Spanish. So Azul Systems is "Blue" to him. Last night at the LAJUG we were amazingly lucky enough to get a tremendous presentation on Java Garbage Collection from the CTO and Cofounder of Azul Systems, Gil Tene.

Azul, for those who don't know, make a JVM which, while it costs money, resolves a lot of the performance problems commonly encountered in Java environments.

TheHackerCIO is never tempted to Lionize anyone, or write puff-pieces about any product. What set this presentation apart were the following:

factual information about all available GCs was the main thrust of the talk.

Zing (Azul's product) was only mentioned briefly at the end.

Basic terms were defined, some in cleverly clear ways that made for greater retention

Basic principles were developed.

Principles of GC operation were then examined in the context of those basic terms and principles, so that everything was brought into a coherent whole.

The focus was on understanding the Mechanism, not on explicating the JVM flags. As Gil put it "Once you understand how it works, you can use your brain" to figure out the flags. TheHackerCIO likes that. Always use your brain.

A lot of misinformation and fallacies were debunked. Turns out, surprise, surprise, the Conventional Whiz-Dumb is wrong much of the time.

The presentation was so superior to the Performance book, that in my mind it formed a perfect contrasting concrete. If only the Performance book we are studying had been written in this manner, we would have all been happy campers.

I took pages of notes, and I suspect that I'm going to have to break them out over several days. But, you have to start somewhere. And what better place than his attention step?

He began by claiming that most of what people "know" about GC is wrong. Then he told a story

Early in Azul's history they encountered an application taking 18 second pauses. This was somewhat embarrassing for a pause-less JVM, so they investigated. What they found was that every class had a finalizer that set all instance variable references to null.

Notice that this is the right discipline for a C++ environment. But it's dead wrong for Java. Dead objects cost nothing to collect! Except, when you put finalizers on them! This is a perfect example of how people fail to rethink new technology in the context of it's own spirit and intent and continue to use it in antiquated, outdated manner. But that is a major topic for yet another day's blog, and was not a topic of Gill's talk.

So, despite the Conventional Whiz-Dumb:

GC is extremely efficient. Much more so than malloc().

Dead objects cost nothing to collect (Except when you put finalizers on them!)

Those pauses you eliminated from your 20 minute test are not really gone. They just got pushed out to 30 minutes. Your times may vary, but the pause just got pushed out to a later time!

There will be a 1s per live GB pause. This is not really tunable. The only way around it is Zing.

No, GC doesn't mean that you can't have memory leaks.

Even I fell for some of these in times past. But this is getting long.

I would say in conclusion that rarely have I been so impressed by a company's values. The talk we scored came from Azul honoring the commitment of a junior sales engineer to speak to us in October, but who had left the company. In the absence of anyone local to fill in, the Cofounder/CTO hopped on a plane to give us the promised presentation. TheHackerCIO deeply respects keeping commitments and can't think of a more paradigmatic example. More on GC will follow.

Tuesday, October 1, 2013

A friend expressed sorrow, the other day, that they had revealed their "idea" at a Hackathon. Now, it was in the public domain. Now the idea was available for anyone to steal.

This was the common, conventional Whiz-Dumb, back ten years ago.

But it's very wrong-headed. It's an outdated way of thinking.

Ideas are easy to generate. They're a dime a dozen. Some are good, some are bad, most are in-between. But none will generate a successful company without an enormous investment of sweat equity. And it's unlikely that anyone is going to invest that amount of work into something that they are not passionate about.

Now, in my experience, the people who pitch their ideas at Hackathons, or for that matter anywhere, lack sufficient passionate commitment to their own ideas! How easily they give them up. I'm not talking about tweaking them. I'm not talking about pivoting into a slightly different market. I'm talking about completely abandoning one idea in favor of another. This may not, necessarily, be a bad thing, if the idea was not good enough. But it clearly shows that a single-minded commitment to make something, and make it work is a rare commodity! And if even the originator scarcely has it, how likely is it that someone else will steal it?

That's why "stealth" is a thing of the past.

If you want your idea to succeed, you're going to have to get your idea out there in front of lots and lots of people. The more you hide it away, the less likely you are to engage others in your behalf to help further your idea. Especially in todays tight capital market, where most startups need to be "lean," you're going to need to count on the sweat-equity factor to protect your idea.

You're going to have to accept that others know about your idea, but that they are unlikely to invest their lives in stealing it away from you, because they have cool ideas of their own!

So, stick to your idea (assuming you believe it's good), and prove it out by getting it in front of as many people as you can. If you're lucky, you'll excite enough passion in a few that they will join you and together you can invest your life-blood in making your idea a reality!

Monday, September 30, 2013

TheHackerCIO isn't known for pulling punches. When he spars, he tends to spar hard. Especially when shadowboxing!

You should know in advance that there is a clearly defined audience for this blog. That audience is TheHackerCIO, and TheHackerCIO alone. So, nothing written here should be taken to apply to every member of a roasted group.

I'm sure that there must be bloated, hidebound, Behemoth corporations which are not Pathological. Where the bureaucracy is easily sidestepped in favor of accomplishing real change. Where employees are passionate about their work and product. Well, maybe I have my doubts. But you get the idea. Please don't take offense and go complaining about these opinions to TheHackerCIO.

Likewise, not every MBA is an MBAhole. Not every Big Four Consulting Group is completely useless and inept. Well, OK, in the case of the Big Four, yes every single one is useless and inept. Because it's structured to be so. The people they have who are awesome technologists are shills in a mighty Bate-And-Switch con-game. These groups use their legal departments as profit centers! So, yes, all of these people should take offense and quit reading. Your values -- if you have any -- are not my values.

But, any of you out there taking offense at these passionate, deeply held values, you are actually kind of a voyeur or Peeping-Tom for reading this blog! This is written primarily for personal consumption. If you're here, it's by permission only.

I can tell you that the intended audience for this blog has given it a 10 star rating! Every time TheHackerCIO reads a blog entry he heartily enjoys it. He's never laughed so much in years. It must be adding years and years to his life, as well as enriching it in new and varied ways.

Sunday, September 29, 2013

The larger the company, the greater the likelihood of pathology. Something about bloat leads to it. It's almost a disease of obesity. Or at least it has a co-mordibidity with obesity. A colleague who works at one of the behemoths where the bureaucracy is beyond belief recently experienced a merger: Ferile Hangman [names changed to protect the guilty] merged with Bank of the Universe and became a doubly bloated blighter. When I spoke to this colleague, I asked how the new situation was post merger. "Even worse," came the reply, boggling the understanding.

This is a company which worked on one system for over a year and never saw it move into production. The hurdles to comply with were simply too great. Whether or not a system goes into production is irrelevant to those who move at the speed of glaciers. Of course, my colleague moved the code into a production region -- there were just no users! That way he could (without lying) put on his resume that it went into production and was completed.

These are the companies who hire Accounting Firms to help them construct computer systems! The philosophy goes like so "No one ever got blamed for hiring the big Four." I'm sure it's true, but avoiding blame is not a worthy pursuit for a technologist. Or any kind of executive. And going to someone who specializes in financial audits as an extension of the Government Regulatory Apparatus to ensure compliance with all their ridiculous nit-picking rules is hardly the way to attain competitive advantage through innovative use of technological systems. All I can say about these organizations is that fortunately they have been decreasing in number: 8-6-5-4, and I hope the trend continues and approaches zero asymptotically, so that in the limit we have exactly none of these abominations in the technology side of the business.

For those who haven't experienced the bureaucracy of a pathological behemoth, TheHackerCIO can only communicate a smidgen of a taste for the kinds of daily insults and silliness. At one of them, a major HealthInsurance company, for instance, Disunited Healthcare, there were plenty of documents everywhere explaining how they were an "agile shop."

Agile! They don't even know the meaning of agile. I'd term their development process "Hidebound." If the standard method of years past was "Waterfall," then they were the Angel Falls of the development world. I never saw a standup meeting ever in the place. There were no points assigned, no scenarios, no User Stories, no pair-programming. When I had been there for a few weeks and come to understand their system, one of the project managers led me to a surprise meeting to review his Waterfall style project plan. At the end of presenting it to me for the first time, he asked if I had any comments.

TheHackerCIO replied, "Yes, my first comment is that I am down on this plan for a number of deliverables, some of which I have no idea what they are. So I want to first of all understand what these represent, and then I'll comment on the plan." We then spent a good 20 minutes discussing what the deliverables were for which I had been assigned without ever being told. After which I said, "Now that I understand what the plan refers to I have a few comments on the schedule. First of all, this one item was due to be completed yesterday, and I only came to understand its existence a moment ago. That isn't going to be completed by yesterday, as it hasn't even begun."

At this point all hell broke loose with the PM. "This will throw out all my completion dates, if I change that one."

I said, "We can play this two ways. Is this meant to be a work of fiction? Or is it meant to represent reality? If it's a work of fiction, then it's fine to put whatever you like. You don't need my comments. They will only upset you. But if it's meant to reflect reality, you'll need to revise the dates to the possible. The last time I checked, I was not God. So, I'm not able to complete a task in the past. In fact, a lot of theologians believe that even God cannot change the past, so the only thing open for alteration is this plan you're reviewing with me."

TheHackerCIO doesn't fit in well in The Pathological Corporation. He's not a "team player." Which is to say, he's not a bullshitter.

This is a company whose CIO told the IT department -- at a Town Hell Meeting -- that they were "just a cost center." Well, I'm sorry. But Management is the cost center. And it damn well need eliminating.

I use postings like this to remind myself when I get tempted to go back to a large Enterprise, by some exciting project of Enterprise Architecture. Because it's all a ruse. They don't really want to transform their systems. They only want the appearance of it, to put in their glossy literature for the shareholders meeting.