Showing posts with label CIA. Show all posts
Showing posts with label CIA. Show all posts

Monday, February 19

Cheating

 











The Peacock and the Sparrow by I.S. Berry is set in Bahrain in 2011-12, with the Shiite-majority population energized by the Arab Spring, restless under a Sunni-minority monarchy. “The government does not publish statistics regarding the breakdown between the Shia and Sunni Muslim populations.  Most estimates from NGOs and the Shia community state Shia Muslims represent a majority (55 to 65 percent) of the citizen population,”  reports the US State Department. Bahrain's population is small, 1.4 million, or as many in San Antonio, Texas. The US Navy's Fifth Fleet, based in Bahrain, is a non-NATO ally, but stability with the king and regional security take priority over human rights.  

Protagonist Shane Collins works for the Central Intelligence Agency, and like most spies, regularly lies, a habit that seeps into his personal relationships. He manipulates informants, colleagues and lovers for his own purposes, at one point smugly noting: “A spy was a spy, and at fifty-two I could still lure a fish into my net.” 

Collins poses as a diplomat, a role that should raise eyebrows among any of his contacts. His third month into Bahrain, he is unhappy: “The point where any extant novelty or exoticism has worn off. Where you sink deeper into foreign soil but it repulses and rejects you, shuns your alien roots. Where you become trapped in the amber of the transplanted elite.”  A slacker, lacking self-esteem, he fails to rise through the ranks over the years and works for a polished and younger boss with Ivy League credentials. Collins centers his life around alcohol and when he plays music for a lover, it “like I was hearing it myself for the first time, its euphony fresh, a first sip of whiskey before it descends from pleasure into routine into necessity.” 

The writing is strong, the noir tone compelling, and it’s hard to believe the book is the author's first. Still, the book has problems. 

First, Collins engages in excessive stereotyping, about gender and nationality. For example, he describes his love interest, Almaisa who is an artist: “She had none of the triviality or false femineity of American women; neither did she have the humorless affectation of European women.” He goes on: “A feminist some might call her (though one, I learned, who recoiled from the label.)” Such labeling often leads to cliches: “She was the living product of East and West, a combination that often seemed as fraught with conflict as the two hemispheres.” 

Collins prides himself on breaking down Almaisa's Muslim sensibilities, convincing her to ride in a car with him, try some wine, discard the veil and spend nights in a secluded place. She wears colorful hijabs and he gets her to admit: “mother had never worn a hijab, that it was nothing more than custom, the Quran silent on the subject, that she mostly wore the garment to blend in rather out of religious conviction. Despite Almaisa’s disdain for Western mores, her aversion to becoming like my female compatriots (whom she accused of hedonism and exhibitionism – and was she in truth so far off?), she eventually gave way.” 

He assumes that he is in full charge of the relationship: “Not so different, after all, from the delicate give-and-take dance with an informant, an unending alternation between obeisance and control.” 

The book fictionalizes details and damages of the Bahrain uprising. The plot also takes a long, strange turn as Collins travels to Southeast Asia, raising questions for this reader about why any supervisor would send or trust him. Collins meets reader expectations by transporting a packet for an informant, scheming against supervisors and arranging documents that later assure his own survival.  

Collins as spy becomes target. Belatedly reaching this conclusion, the character escapes the destruction unleashed by his actions and that of US policy, but not without betrayal on multiple fronts. In his world, everyone cheats.

Tuesday, March 7

Lessons for all

Many of the more than 8,700 documents on CIA hacking tools released by WikiLeaks are technical. But not all. Among the files is a quick summary of Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt, a book readily available on Amazon. The advice is timely and could be useful for any leader. 

Practice #1 – Work for Outcome

Blame does not fix bugs. "Instead of pointing fingers, point to possible solutions.  It is the positive outcome that counts."

Practice #2 – Quick Fixes Become Quicksand

Beware of land mines such as quick fixes and shallow hacks Do not code in isolation to ensure more than one person knows about a certain piece of the project...

Practice #3 – Criticize Ideas, Not People

Negativity kills innovation... Take pride in arriving at a solution rather than providing whose idea is better. "There is no absolute best, only better.  Despite the popularity of the term, there is no such thing as 'best practices,' only better practices in a particular situation."

Practice #4 – Damn the Torpedoes, Go Ahead

You definitely need to read this section for yourself - basically admit your mistakes and back up your opinions with facts (pros and cons). "Do what is right.  Be honest, and have the courage to communicate the truth.  It may be difficult at times; that is why it takes courage...."

Practice #5 – Keep Up with Change

Learn iteratively and incrementally. Get the latest buzz.... Read voraciously. "Keep up with changing technology.  You do not have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly."

Practice #6 – Invest in Your Team

"Raise the bar for you and your team.  Use brown-bag sessions to increase everyone's knowledge and skills and help bring people together.  Get the team excited about technologies or techniques that will benefit your project."

Practice #7 – Know When to Unlearn

"One of the foundations of agility is coping with change.  Given that change is so constant and pervasive, does it make any sense to keep applying the same techniques and tools you have always used?"  Expensive mental models are not discarded lightly: "Learn the new; unlearn the old.  When learning a new technology, unlearn any old habits that might hold you back.  After all, there is much more to a car than just a horseless carriage."

Practice #8 – Question Until You Understand

 The best question to ask – Why ...? "Keep asking Why.  Do not just accept what you are told at face value.  Keep questioning until you understand the root of the issue."

Practice #9 – Feel the Rhythm

Agile projects have rhythms and cycles.... Time boxing – setting a near-term, hard deadline for an activity that cannot be extended. "Tackle tasks before they bunch up.  It's easier to tackle common recurring tasks when you maintain steady, repeatable intervals between events."

Chapter 4 – Delivering What Users Want

Quotable Quote – "In warfare, as in software development, the situation can change quickly and drastically.  Sticking to yesterday's plan despite a change in circumstances is a recipe for disaster."

Practice #10 – Let Customers Make Decisions

Decide what you should not decide: "You do not want to have to make decisions that are business critical by yourself.  After all, it is not your business."
"Let your customers decide.  Developers, managers, or business analysts should not make business-critical decisions.  Present details to business owners in a language they can understand, and let them make the decision."

Practice #11 – Let Design Guide, Not Dictate

 Design should be only as detailed as needed to implement. Strategic versus tactical design – strategic is the up-front design before requirements are known "A good design is a map; let it evolve.  Design points you in the right direction.  It is not the territory itself; it should not dictate the specific route.  Do not let the design (or the designer) hold you hostage. "'No Big Design Up Front' does not mean no design.  It just means do not get stuck in a design task without validating it with real code.  Diving into code with no idea of a design is just as dangerous.  Diving into code is fine for learning or prototyping, as long as you throw the code away afterward."

"White boards, sketches, and Post-It notes are excellent design tools.  Complicated modeling tools have a tendency to be more distracting than illuminating."

Practice #12 – Justify Technology Use
  • Blindly picking a framework is like having kids to save taxes. Pick technology and frameworks based on statements like – "It is too hard to ..." or "It takes too long to ..."
  • Does it really solve the problem?
  • Will you be tied to this technology forever?  When technology changes, will you be able to change the design to match technology?
  • What about maintenance costs?
  • Do not build what you can download – reinventing the wheel
  • "Choose technology based on need.  Determine your needs first, and then evaluate the use of technologies for those specific problems.  Ask critical questions about the use of any technology, and answer them genuinely."
Practice #13 – Keep It Releasable

  • Checked-in code is always ready for action... Check out the latest source.  Run your local tests.  Check in.
  • "Keep your project releasable at all times.  Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment's notice."

Practice #14 – Integrate Early, Integrate Often
  • Never accept big-bang integration
  • "Integrate early, integrate often.... start integration early and continue to do it regularly."
  • "Successful integration means that all the unit tests continue to pass.  As per the Hippocratic oath – first, do no harm."
  • "For prototypes and experimental code, you may want to work in isolation and not waste effort on integration.  But do not stay isolated too long; once you learn from the experience, work toward integration quickly...."
Photo of young girls learning to use computers in Eastern Afghanistan, courtesy of Todd Huffman and Wikimeda Commons.