Release the Kraken ... I Mean, The Hackathon

TheHackerCIO always wanted to say that, "Release the Kraken." So, now he got the chance. Actually, I say it each time I release the newly washed Chihuahua into the house, but that's a separate story.

What actually got "released", or kicked-off was a Hackathon. I must be the luckiest technologist in the world, because my company board actually backed my participation. It's a kind of sabbatical! But I'm not sure that it's at all a restful one. Of course, I have a lot of influence with the board!

The Hackathon this weekend is a Startup Weekend, and this one is centered around the theme of education.

I went, uncertain whether I would pitch or join a team. And, while I've done Hackathons, I've never done a one of the Startup Weekend variety. There were a few interesting twists and turns along the way, and I want to point them out, especially focusing on my reactions and impressions.

After pizza and coke, we filled into the room for the "Pitchfire" presentations. 60 seconds only is permitted to specify the idea. They suggested that the pitch cover these 4 things:

1. Who are you?
2. What problem are you solving?
3. How will you solve it?
4. Who do you need?

I'm not so sure that I agree with that list approach, but then the presenter/organizer went on to say that most people fumble #1, and waste too much time on it. And, as I've blogged before, I couldn't agree more. In general, I'd try to avoid #1 entirely, if possible, unless it somehow organically fits in with the rest as somehow relevant. But we can deal with that later. 

After this presentation they played a game of rock-paper-scissors, where the winners kept competing against other winners, and the losers followed along until there was a final winner. I hate crap like this, all psychobabble bullshit, trying to get people to "loosen up." 

So, I was less than favorably disposed when they began yet another game. This time it was called Halfbaked. But, although I went into it with a bad attitude, it turned out to be a good game. The purpose was to get teams used to thinking about how they were going to pitch things. Groups were formed, and two words at random were distributed to each team. Everyone got 5 minutes to come up with a product offering, using the two words. Ours were "Cocaine," and "justified." 

So, our group spent 5 minutes discussing this and we came up with the idea of "Ethical cocaine; perfectly natural; cocaine in the raw -- i.e., just the coca leaves, like the natives used in the Andes, as a stimulant, superior to coffee."

So, we thought we were set. But then, they made us exchange one word with another team. So, now, we ended up with "Baby" and "Cocaine." This was to emulate the "pivot," which is so central to the Startup world.  5 more minutes of discussion. For some reason, the team chose me to present. I honestly don't know how they could figure that out so quickly, but anyway, I did my best. 

Our presentation centered around "Cocaine, ... Baby!!!" A product for fathers with young newborns, who need to go a level beyond coffee." I'll try to post the footage later here. 

After these play pitches, I decided to go ahead and try to pivot my idea into the educational realm. The idea I had come with was a pure technology play. You read about it here, this week. I called it "DataStory." And, if I hadn't pivoted,  I would never have made it past the judging anyway, since "educational impact" was 25%. Remember, that the decision and ability to do this Hackathon was a last minute one. I barely had time to skim all the posted materials prior to arriving. And if I hadn't come up with an interesting idea on Tuesday, at the Geeky Book Club, I wouldn't have had anything to pitch at all! But that's quite in the spirit of Hackathons. 

I'll try to post the footage of my pitch later, and I'll analyze it for what was good and bad. Since I pivoted, I think I didn't do as well as I could have, but ..

Then we went into the foyer, and attempted to solicit votes for our teams. Only the top teams were allowed to compete. I managed to get 13 votes, indicated with post-its:

And that was enough to get into the running! So, I'll have to blog about my idea later, because for now I'm too tired. But tomorrow I'll continue this saga, probably many times during the day, so check back early, check back often, as I attempt to develop an MVP and code DataStory.

I Remain, Exhaustedly,

TheHackerCIO

Mastery of the Details

The devil is in the details. So they say. And so it is. TheHackerCIO believes that two forms of mastery are crucial to a successful technology career:

• mastery of the technology medium (i.e., java, C#, php, ... whatever), and 
• mastery of the business/analysis details. 

If you haven't mastered the details of the requirements and become fluid and easy about all the interrelationships and cross-requirement implications, you won't create a good solution. Incidentally, no methodology or process will automatically guarantee that you do create a good solution.

This isn't to put down process or methodology. They are very important. They can be tools to achieve a good solution. But it must be remembered, always, that they are tools. They are not an end in themselves. When they become too entrenched, they become sclerotic, bureaucratic. Ultimately, they become an impediment to achieving a good solution.

The other form of mastery required for a successful tech career is mastery of the technology medium itself. I feel another posting on techno-journaling coming on! So far, we have covered techno-journaling from the narrow standpoint of on-boarding a new client. It is a technique well suited for rapidly grasping all the myriad details involved in a complex project, and mastering all their implications and interrelationships.

But we did mention, also that techno-journaling can be used for domain/technology mastery as well. And that usage requires a different form of journaling.

The interesting thing about journaling, is that it is a methodology, or technique that is entirely focused on details. And on mastering them. And on letting nothing escape the net! I don't know another technique with such a focus. People pay lip-service to "attention to detail," but how many have a systematic, rigorous approach to actually doing this? I leave the answer as an exercise for the reader.

We'll put that other form of techno-journaling, the one focused on the technology itself, down on the "forthcoming" list. Stay tuned!

For Now, I Remain,

TheHackerCIO

Geek Cage Fighting

Last night I spent with a few honorable colleagues cage-fighting.

The cages were at a co-lo center in El Segundo, where my colleague has a rack, 4 servers, some firewalls and a switch. The fight was not MMA, but to configure the kit so that we can get up private-cloud virtualized environment. Now that's a real fight. And there's not much chance of a knockout. But you know that already, if you fight with technology regularly.

TheHackerCIO is going to have to dust off his hardware and networking skills. But that is a wonderful thing, not a burden! We are so studiously kept away from the datacenter by clients and employers, that we start to lose touch with the blue-collar side of our art. I realized at the last big Hackathon -- the one with a "wearables" (i.e., hardware) theme -- that it was time to find some hardware hackers to start hanging out with. And now I'm making a move in that direction.

Luckily, we have a very serious member of our Technology Radar Group, who is now determined to set up a lab where we can all work to our hearts content, without management oversight and without fear of messing up production. And most of this is donated equipment! I've never attempted to solicit donations, but this is a charity cause that TheHackerCIO can unabashedly support!

So, if you're in Silicon Beach (for now), please take a moment to check out Richard Parker's Meetup, the Cloud Engineering Group Meetup.

I Remain,

TheHackerCIO

Cucumber Sidebar Conversations

Last nights Geeky Book Club continued on with the Cucumber book. These chapters didn't elicit earth-shaking insights. However, the sidebar conversations were wonderful.

One of the special pleasures of having such a great group is that you get to find out about all kinds of things you've never heard of. It's almost an unofficial Technology Radar.

The big one I discovered last night was Liquibase. This is almost like a Git repo, but for your database. And these discussions led me on to mention to the group an idea that had been brewing in my mind for a while.

Relational databases are based around a few simple concepts:

• The concept of a table: rows & columns, almost like a spreadsheet.
• A few relational operations, with an underlying mathematical model.
• Set processing of all data.
• Metadata (the catalog) for discovery/documentation and enforced at creation automatically.

But an enormous complexity arises from these.  Maybe not with the canonical example from Date's book of the Employee and Department tables. But when you get up to ten tables with foreign key constraints, and then move up to hundreds or even thousands of tables (as in Peoplesoft), all with complex relationships -- the complexity is very hard to manage. It's also hard just to grasp.

This is fairly common. The idea in Finance of Options is very simple. Two types: calls & puts. Two sides to each type: long and short. But the complexity that results from this resulted in a Nobel Prize for Fisher Black! And I've read many a neuron-busting treatise about valuing such options, back when I consulted for Wall Street Derivatives traders: the gamma-neutral strategies, delta-neutral hedging, etc. etc. etc.

My idea is that just as we have tools like Cucumber to store our scenarios and link them to our code, so also we need such a tool that shows the database transformations that come from each step of our scenario.

This would be both a documentation tool, a tool for systematically collecting and creating test-data, and educational tool for new developers, or those who want to understand the system. In short, such a tool is most earnestly to be desired.

So all of this crystalized in my mind as I put it forth to my honorable colleagues, last night. And they agreed that such a system would be very useful.

If any of my readers want to help me work on it, TheHackerCIO is now set up on Github, and I think I'll begin hacking ...

Now if only I had a catchy name ...

I Remain,

TheHackerCIO

OAQ: Are All Clients This Pathological?

"You've been doing this a long time. Are all consulting clients this pathological?" This was the question of a colleague and newbie consultant. "Unfortunately, yes," I reluctantly, but honestly had to reply. "This is normal, then?" He continued. "No," replied TheHackerCIO, "it's not normal, but it's usual."

Unfortunately, what is usually seen is far from normal. It's, in fact, pathological. And it seems to be omnipresent: both in startups (where it seems to center around a co-founder) and in the Bloated Behemoth Enterprises (where the pathologies seem deeper seated and rooted, and generally have metastasized more pervasively).

I wish I had an easy guidebook, something like Harrison's , which could point out all the pathology and it's etiology. But no such resource exists.

Financial institutions are highly regulated, and like all regulations, imposed by force of law, they cause what the economists euphemistically call "dislocations." But aside from the effect on the market, where misallocation and bad signals result, there are also the internal "dislocations" within a Company. These are very highly pathological.

I've always wanted to have a client who was privately held, just to validate this theory. In theory, a privately held company should be less subject to the whole apparatus of Government bureaucracy. And it would be fascinating to see if the pathologies were less manifold.

On the other end of the spectrum, startups, it's quite commonly known that VCs (Venture Capitalists) often view it as their mission (or what value they can add) to force out founders. I used to hate this about them, but I've come to see that many times founders are not the best people to carry forward a company. It's not so much that the VCs are heartless, as that they can excise a pathological person who has insinuated himself at the very root of a company. If they can successfully do that, and substitute a proper, well-suited replacement executive, then they have increased the valuation of the company by an order of magnitude.

I'm sure there are many, many other sources of pathology. And consulting is not the only place where the effects are seen. Dilbert is predominantly read by permanent employees, after all.

At least this can be a starting point for attempting to develop a taxonomy of pathology in the technology industry.

And, in case you were wondering, OAQ stands for "Occasionally Asked Question."  ;-)

I Remain,

TheHackerCIO

Comment Away, My Friends!

A reader asked me why commenting was not possible here.

The short answer was "Isn't it?" That's not really an answer; that's a question.

Feedback is essential for anything. And for TheHackerCIO, blog-readers are the end-user. So please let me know if there are problems! I thought it was my lack of familiarity with Google+ and that my readers likewise were not on G+ which had kept the commenting down.

But after the query, I poked around a bit deep in the bowels of the settings, and discovered that disabling the Google+ commenting led to a much easier comment link at the bottom of each posting.

So, thanks to that Biotech-Startup cross-reader who made me aware of the issue! (It wasn't even an IT-techie!)

And ... let's get interactive.

Let's call this unofficially, an RFC.

Laughing, I Remain,

TheHackerCIO

The Way of the Master

A recent article (here) about the Documentary Jiro Loves Sushi points out the notion of "falling in love with your work." But TheHackerCIO always likes to go back to primary sources. So, today, I began watching the documentary for myself.

The notion of falling in love with your work is fascinating. But the notion of mastery is equally fascinating. We can see it in our Grandmaster at the Karate Dojo. But seeing it spelled out, by a different profession, in a documentary is somehow specially enlightening. I took the liberty of copying down this statement verbatim, given by a Sushi reviewer who has visited hundreds of Sushi bars to compare them. So substitute your favorite technology in for "chef," on this quote:

A great chef has the following five attributes:

1 First, they take their work very seriously and consistently perform on the highest levels,

2. Second, they aspire to improve their skills.

3 Third is cleanliness. If the restaurant doesn't feel clean, the food isn't going to taste good.

4. The fourth attribute is impatience. They are not prone to collaboration. They are stubborn and insist on having their own way.

5. What ties these attribute together is passion. That's what makes a great chef. Jiro has all these attributes. He's a perfectionist.

Americans might question #3. What is the importance to me of cleanliness? But there is a certain discipline required to have your cabling neat, which reflects itself in the overall quality  -- an reliability -- of the racking.  Frankly, the same goes for the desk. TheHackerCIO many years ago achieved a "clean desk" policy. I only keep the documents and work products I need on my desk during the day; by night, everything is neatly stored away in the desk. It leaves a more professional impression on clients, but more importantly, I avoid the continual "hunting" and "searching" for that lost document, which is so common.

The fourth attribute, of course, is precisely attacked and rejected almost universally in American corporate culture. There the God of Consensus reins. Only a "Team player" is desired. A Jiro wouldn't stand a chance.

There's more, but for now,

I Remain,

TheHackerCIO

 

 

 

Beyond "Show, Don't Tell Me"

The Principle "Show Me, Don't Tell Me" is extraordinarily important.

But one can go even deeper, to an even more crucial principle.

That principle is ... well, let's do a case study.  The study is using unusual printer and reader devices associated with magnetic stripe cards.

Today TheHackerCIO saw a Zebra P330i Magnetic Card Printer/Encoder at work. Cards were loaded in the hopper. An attached laptop running Visual Studio was opened. Code pointing to an image, text and numbers was run. The printer whizzed a bit. Out came a card printed with the image. We then opened a 3M document reader, which can perform the OCR on a passport as well as the MSR (Magnetic Stripe Reader). We ran the newly printed card through the reader and voila! In Notepad, we saw the data wonderfully displayed.

Zebra P330i Magnetic Stripe Card Writer

Being shown a new technology is great.

It's so much better than if I had just been told how it worked. In fact, seeing it proved to me that the devices were working. Almost. To really be certain, I'd want to see another test where the data was changed and the changes reflected in the reader. And to be really thorough, before I went to production, I'd need to test that every track of the three available would properly encode data and that the text and image would print properly on the front and back of the card, as expected. But we covered this yesterday, under "Show, Don't Tell Me."

But what is really fascinating was what happened next.

TheHackerCIO didn't just remain satisfied that he had seen how to encode a mag card. He said to the demonstrator, "Let me drive." Thus, taking the Conn, I sat in the Captains Chair, seized the keyboard firmly, and began telling my demonstrator what I wanted to do.

The first thing that became apparent was that I couldn't even find Visual Studio. With a little help from said demonstrator, I found it was listed under "M," for Microsoft Visual Studio. Then, there were several versions, such as Express, 2010, 2012, etc. I had no idea which one to use!!! I discovered that the project had been built using 2010, not 2012, which was more web-oriented.

With this open, I was now able to familiarize myself with the code.

Then I realized I better load up a card. I pulled up the protector, and dropped in a card, face up. My gentle guide pointed out that there was already a card there, mentioning that the device fed from the bottom, and so I corrected my error by removing both cards, setting aside the one that had been on the bottom, and placing my new card at the newly opened bottom position of the hopper.

Returning my attention to the code, when I began to make a change, I attempted to put my name into the code as "James^Rothering." (The caret is used as a separator, I am told)  I got an error when I attempted to build it. Lower case is not permitted, as I discovered. Upon changing my name to "JAMES^ROTHERING" [the ISO 7813 standard uses the "caret" as a field separator] the code compiled and prompted me to enter various fields. I didn't know which of the many drop-down choices to select for the "Printer", but upon asking, the demo-meister told me to choose  "Zebra p330i card printer USB (copy2)". Why copy2 and not copy1 we didn't go into. I also selected "front" for print selections, and too quickly, I hit enter. I had not checked the "magnetic encoder" check-box. I knew this was an error an eyeblink after I did it and exclaimed to the demo-meister that I "messed up." He said, "Yes, I would expect that it will print the card, but not encode the changed data you typed in."

I agreed, and said that I wanted to view the card anyway, to ensure that it had failed as we expected. I then attempted to find the 3M card reader in the Start | Programs and had no luck. Demo-jockey pointed out that he simply had placed the binary in a directory under Downloads. After starting the ".exe" from that directory, I went to swipe the card, but found myself stopped. Demo-jockey said I could now minimize the panel displayed by the 3M reader program, but needed to have Notepad open, having focus at the time I swiped! So, I performed those actions and ... lo and behold. The card was erroneously encoded as it had been before I changed the data. That was expected, as you will recall.

So I went back through the steps of loading a card,  invoking a print, but this time carefully checking the box that caused it to actually encode the track. And this time .... ta da .... In Notepad I saw my beautiful name exhibited just as I had typed it in! Success at last.

The point of recounting this story is to illustrate the importance of taking the conn. Of moving rapidly beyond "Show, Don't Tell Me" onto "Walk Me Through, please!" The learning acquired by actually doing something, with a knowledgeable guide present is incalculable.

Walk Me Through, Please!!!

Walk Me through, now ...

I Remain,

TheHackerCIO