Reactionary Code

Posted on May 8, 2013 by JD

Well I spent several hours this evening coding and hacking away at scripts after an issue kick me in the goolies today. After several hours I had a fully working set of scripts that humming away. Yet I also had created a monster which I will have to slay tomorrow morning.

An all too often as developers we get to the point of understanding the problem and simply dive into well.. “a” solution..

And all too often this results in the “Big Ball of Mud.” We have a problem but do we have the end goal in mind. Like many things it may be static right now but what about the next release? When would this goal be changed and how might it change? With these in mind we start adjusting our solution – abstracting out areas that may be subject to future changes trying to make them as easy as possible.

Taking the time out to properly analyze the problem and expected solution will save headaches and scraping old code. The bigger the problem, the more important it is to analyze and re-assess periodically. Do the assumptions still stand, has the goal altered enough to require another look at the design?

Coming over from the entrepreneurship side and the agile sessions is to also concentrate on the Minimal Viable Product and to code for now since your expected future assumptions may change. So abstract out but only build the interface that you are using right now.

Well wrecked out and not looking forward to the cleanup tomorrow that my rush created this evening created..

Strategy or how to avoid trying to be everything to everybody and ending up as nothing to nobody!

Posted on April 25, 2013 by JD

I went along to a talk by Author Roger L. Martin, HBS Profssor Jan W. Rivkin, and moderated by HBR Editor Adi Ignatius and this was hands down the most entertaining talk about strategy I have every attended! This was to coincide with Roger’s new book Playing to Win.

We dove right in to the keep issue that cropped up again and again during the talk – that there is no common language when people talk strategy! People need a shared understanding, they must be able to comprehend how their part in the grand plan integrates with everyone else.

This follows one of Roger’s earlier articles published in the HBR, The Execution Trap. Here he describes how implementing a top down strategy plan is inherently wrong and designed to fail. By making the plan at the top and distributing it down to the lower hierarchy to execute it raises two major problems:

Executors have no choice
Yet, there are a huge number of choices that must be taken at all levels of an organization to implement a strategy

This then railroads in to Dr. Steven Kerr’s Reward Systems: Does Yours Measure Up? where you need to look at what your compensation system is trying to drive your employees to achieve. By forcing your strategy downwards, employees are left with two outcomes:

The make bad choices, the strategy does not get implemented, and the employee is blamed.
The correct choices are made but it is the strategy planner who gets the kudos for thinking it up.

Talk about the world on your shoulders… The crux of the problem is that strategy must make a loop. There must be feedback and feed-forward so that there is one overarching consistent view with choices synch’d up.

Jan related a method fantastic story about how the FBI went about their strategy change after 9/11. There was initial a lot of push back to any change as people at different levels did not understand their role. As a result they broke down the strategy to every group, personalizing it for every level. People could see exactly what was expected of them, where and who it integrated with, and the actual impact they would have. Everyone owned the strategy.

To finish this off with two important quotes:

”Couple a deliberate process and an emerging process”.

- Jan Rivkin

This was Jan’s take on planning a strategy and reevaluating it constantly against the assumptions it was based on

“Strategy is about making choices and the two most important choices to make are where to play and how to win.”

- Roger Martin

And Roger compressing his book into one sentence!

Oracle Monitoring Part 1

Posted on April 23, 2013 by JD

An important part of development is understanding the impact your changes are having. To achieve this we must vigorously monitor the system and over a series of posts I hope to pull together a robust database monitoring framework. There are products produced by Oracle that already achieves this – AWR within OPE and the older STATPACK. The benefit of coding it up from scratch is the wisdom you earn.

System

The first step of this is obviously understanding the requirements and how you expect the logic to change to satisfy them. We create unit tests and regression test and god knows what other tests to ensure that the logic behaves the way we expect it. Yet there are still other considerations outside of the straightforward logic that should be examined, and examined on a continuous basis to catch any unwanted impact as quickly as possible.

Basics

Of the first few tests we best check if the database is actually up – slight important.

1. Check if Oracle database is up:

Source code

ps aux | grep ora_
ps aux | grep tns

2. Check if the Oracle listener is up:

Source code

lsnrctl status
netstat -an --inet --inet6 | grep 1521

And obviously the best method to confirm the database is up is to connect to it!

Source code

sqlplus /nolog
CONNECT / AS sysdba
SELECT * FROM DUAL

Alerts

So Oracle logs all errors and messages to it’s alert.log. This log file is located by default in:

Source code

cd ${ORACLE_HOME}/rdbms/trace
ls -ltr alert*

But if it is not there, you can query the database for the location:

Source code

show parameter BACKGROUND_DUMP_DEST

The alert log contains the following messages:

startups and shutdowns of the instance
Messages to the operator console
Errors causing trace files.
Errors when a materialized view is refreshed.
ORA-00600 (internal) errors.
ORA-01578 errors (block corruption)
ORA-00060 errors (deadlocks)

From here let us concentrate on some of the errors:

Source code

grep ORA- ${ORACLE_HOME}/rdbms/trace/alert.log
grep ERROR ${ORACLE_HOME}/rdbms/trace/alert.log

Trace

Whenever the is an issue, Oracle creates a trace file and notes it in the alert log. To really dig down into an issue you need to analyze the trace file. You can find the trace files with the following query:

Source code

SELECT      u_dump.VALUE
         || '/'
         || db_name.VALUE
         || '_ora_'
         || v$process.spid
         || NVL2 (v$process.traceid, '_' || v$process.traceid, NULL)
         || '.trc'
            "Trace File"
  FROM            v$parameter u_dump
               CROSS JOIN
                  v$parameter db_name
            CROSS JOIN
               v$process
         JOIN
            v$session
         ON v$process.addr = v$session.paddr
 WHERE       u_dump.name = 'user_dump_dest'
         AND db_name.name = 'db_name'
         AND v$session.audsid = SYS_CONTEXT ('userenv', 'sessionid');

I will work through the trace file in the next post.

The power of “Priming”

Posted on April 22, 2013 by JD

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

– Norm Kerth

After a bumpy release and before a retrospective was held, a couple articles were sent around about what a “Blameless Post-Mortem” really is. In our previous retrospectives our team would come together and draw up an action list to resolve our main (top 4-5) issues/pain points. In terms of agile development I think it is the best feature of the methodology.

A lot of features of a retrospective require a lot of team sensibilities as described in Patrick Lencioni’s The Five Dysfunctions of a Team. The team must not be afraid of digging into issues and discussing how they we could have managed them better. A key component of the blameless post-mortem is not to attack people but to discuss how to help in the future. We see this all over the place where egos get wrapped up in something and any critic is felt as a personal attack – code reviews can sting.

With the strong team we can work over the issues without being emotionally run ragged defending ourselves.

Still detaching our emotions and egos is incredibly difficult. I initially laughed in derision at Patrick Kua‘s suggestion on how every retrospective should consider the Prime Directive:

Whoever reads it out should do so as enthusiastically as possible and, even better, leave it hanging in the room to give participants a visible reminder of the statement’s powerful potential.

Yet Martin Fowler points to Daniel Kahneman’s Thinking Fast and Slow as an example of how the simple act of priming the group does have a physical impact on the attendees.

In an experiment that became an instant classic, the psychologist John Bargh and his collaborators asked students at New York University—most aged eighteen to twenty-two—to assemble four-word sentences from a set of five words (for example, “finds he it yellow instantly”). For one group of students, half the scrambled sentences contained words associated with the elderly, such as Florida, forgetful, bald, gray, or wrinkle. When they had completed that task, the young participants were sent out to do another experiment in an office down the hall. That short walk was what the experiment was about. The researchers unobtrusively measured the time it took people to get from one end of the corridor to the other. As Bargh had predicted, the young people who had fashioned a sentence from words with an elderly theme walked down the hallway significantly more slowly than the others.

– Daniel Kahneman

Stepping back, I wonder how else this can and should be applied to other facets. How could we prime different meetings to achieve the outcome we wish. Pushing the desired persona onto the people present. At a hackathon just before people started talking about their ideas the organizer mentioned a crazy thought:

I want a chewing gum that, by chewing it, I get a taste of the company. Where is it positioned, what the cost and risk is in it. Then I can try half of company A and half of company B and get a flavour for my actual portfolio.

This off the wall idea was so far fetched that it changed and encouraged people to push the boundaries, not to go for what is known to be possible but try to find a way to make the impossible.

In conclusion, you need to prime to really get the desired result.

Trusted Networks on the Intertubes

Posted on March 28, 2013 by JD

We have been thrown a challenge by our lecturer, Scott O. Bradner, on coming up with a project for Security, Privacy, and Usability. One idea we kicked around in college was to design a network that would ensure all users had met in real life. Our view was that it had become too easy to pass invites to some unknown person and compromise a network, that requiring a demonstration of physical contact would show a greater familiarity.

The real hang up was on trying to figure out how to demonstrate that the physical contact actually occurred. Getting pictures of people together and doing facial recognition has to be immediately discarded – the thought of keeping everyone’s picture is distasteful plus it would make the entire network insecure if the server was exploited.

On the technical side also, images can be doctored. Sadly most of our thoughts on the technical side could be duplicated and transferred online. Even integrating some aspect of custom hardware into the mix would just be a delaying tactic. Eventually someone would examine the input/output and figure out what algorithm had been implemented.

And so the project had languished till now. With the class and my many hours of 24/NCIS/CSI and other shows I’m wondering if there is some tactic used by clandestine cell systems that permits new members being validated by a trusted 3rd party.

The first aspect, introduction, appears to require several things:

1. The member who extended the invite and invitee meeting up.

2. Having another trusted 3rd party proximity.

3. The 3rd party should not know who the member and invitee are, and vice-versa.

4. A method to confirm the member and invitee are both the two people in the presence of the 3rd party.

A type of one time private network that can be established between the three with authentication is required. How to get around the problem of the member simply operating two laptops or having a person impersonate the invitee are still unknown. The resources to vet the person is beyond the network’s capabilities – so in effect we are still relying on one person’s judgement. The requirement for physical contact would hopefully ensure that the two people do know each other rather than being #randominternetperson.

Once a person joins the network we would have to examine how cells interact. Some thing like only permitting you access to contacts where you have a intermediate contact you both have met – very linkedin. More random thoughts on this later – there may have to be alcohol to get the creative thoughts flowing…

John Doyle

Tech Beers for the Creative Process

Reactionary Code

Strategy or how to avoid trying to be everything to everybody and ending up as nothing to nobody!

Oracle Monitoring Part 1

System

Basics

Alerts

Trace

The power of “Priming”

Trusted Networks on the Intertubes