Opportunities arising in fall 2013

Working on a new project using cutting-edge AWS stuff and iOS 7, I note some opportunities.

1.  A really good Ruby library for working with AWS.

Although Amazon really should hire more Rubyists, this could also be done by outsiders.  AWS is powerful and Ruby is powerful.  Hooking them together properly would be sooooo nice.

2.  An iOS module or framework for higher-level use of Amazon Persistence for Core Data (APCD)

APCD is intriguing but Amazon has a lot more work to do.  For example, objects can only have one properly-persisted relationship between them.  You can't synch an Event object with an "organizer" relationship to Users as well as a "creator" relationship to Users.

Whether Amazon does more work here or not, there's opportunities for people to build on top of this service, because it doesn't address problems like version skew between mobile app instances.  For that matter, I'd like some explanation what it's for -- a real-time background table synch service is good for something but what exactly did the architects have in mind?  Without knowing what it was built for and tested for, it's hard to know whether the service will work smoothly for the applications I'm thinking of.

3.  Documentation and examples for the new XCode unit testing

There's vast amounts of information out there on unit testing with Java, Python and Ruby.  There's blog posts upon blog posts of best practices, and many great questions and answers on Stack Overflow.  But when it comes to XCode, I can't successfully google for "unit test method for filling in a text field in ios".  Apple, why do you hate Web searches?

Ok.

Would somebody get on these please?

Thank you.

Systems thinking vs algorithm thinking

I was chatting with another programmer about our different styles.  He's an incredible algorithm solver.  He's done compression and encryption algorithms in school, and codecs and video processing and GUI animation effects since (he's 23).  I tried to explain the kind of problem that I'm attracted to, which none of those are, and used the word "systems problems".

"But isn't everything a system?".   Only in the most trivial sense.

What I was trying to distinguish by talking about systems problems and systems thinking in programming is modeling independent and interconnected agents.  I'm not the only one with this kind of definition.  In an interesting publication on managing social change, I saw the definition "Systems characterised by interconnected and interdependent elements and dimensions are a key starting point for understanding complexity science."  Very close.  Is there a better phrase for system-style solutions as opposed to algorithm-style solutions?

Another way I explain this approach when I'm being self-mockingly post-modern is to say "I'm interested in the liminal spaces in computer architecture", which is an arty/jargony way of saying I'm interested in the interfaces between agents: APIs and protocols, typically.   I also hear the words of a British-accented UWaterloo professor from 20 years ago, saying "Modularization!" and "Information hiding!" over and over.  (Systems thinking supports object-oriented design.)

I've worked with a ton of people who have the same mental models because I worked a lot in the IETF for ten years.  It's a necessary part of communications security in particular, because in addition to thinking of each client and each server as ideal agents, one must always think of bad actors and flawed agents.

Coming back to startups, I'm always surprised in a way when I talk to a programmer who doesn't design and implement protocols and APIs because they think so differently.  It's more justifiably shocking when I meet people who know about and implement REST and aren't used to systems thinking!

I'm reading Don't Make Me Think by Steve Krug, and just read the section on home page messages.  That's why I laughed out loud (surprising my cat) when I saw this home page:

Amazing, huh?  It's got simple pricing!  Free, pro or on-premise!  What does it do?  Not important!

If you scroll below the fold -- I swear this is exactly what I see above the fold my very first visit to the site -- there's a "Full Feature List".  Now (and you really can't make this stuff up) I can see that Teambox supports

• Capacity (this is a header)
• Users
• Projects
• Storage
• Organizations
• Hosting
• Support
• Premium Features (this is the next header)
• Group Chat

In other words, I still have no clue except that Group Chat is apparently a premium feature.  Wow.  At this point I don't even want to know.  I feel like knowing what the service or product is would only detract from the delicious infinite possibilities of Teambox.  I don't want the service, mind you -- I'm happy with the inscrutable mystery of Teambox.  Some things are not meant to be known.

Kevin Liddle makes a case against cucumber in his blog post.  Since he doesn't have comments, I'll basically comment here.

I agree with Kevin that the idea that product managers will write cucumber tests is pretty weak.  They might well read them and understand them however.

I think, however, that the value of cucumber and its gherkin syntax are, as with many things, not exactly in the place where the designer thought the value would be.  The value is in using anything but ruby to describe what you're trying to accomplish with ruby.  Every so often I'll write or encounter a test written with the same narrow view with which the programmer wrote the code. Such a test verifies that the code reliably does the wrong thing in the larger sense.  Using ruby to test ruby also encourages trivial tests where the implementation detail is verified, not the application logic (see Don't Unit Test Trivial Code  )

My science-based (but not scientific) theory is based on how low-level thinking impedes high-level thinking.  As an example, this happens when you're driving, thinking about something low-level like adding distances, and get distracted and miss your freeway exit.  Cognitively,  when you're in the middle of writing Ruby code and thinking about how to write Ruby, it's harder than normal to think "what should the code do".  Switching to another language, gherkin or anything else, prompts the programmer to go meta. Going meta means repeatedly re-loading the mental model of how what i'm doing is fitting into a larger system and goals.

This effect is known in a couple different fields:

•  Learning math: "Good problem solvers possess metacognitive skill, the ability to monitor and assess their thinking" (ref Support for Learning)
• Corporate strategy: "A strategic thinker has a mental model of the complete end-to-end system of value creation, his or her role within it" (wikipedia Strategic THinking)

So besides just changing to another language to avoid ruby-testing-ruby circularities, Gherkin is designed to make the programer think in terms of wants and fulfilling user expectations.  The syntax "Given I am a new user, When I go to the home page, Then I should see the zero-content display" helps the developer pop from what she's trying to do to how she's trying to do it, and back, without losing the big picture.

An information coordinator is useful

An information coordinator is a useful person, and after two years of working with a partner or alone, this weekend was a nice reminder of that.

The classroom camping trip was Saturday night, and since I haven't been working full time this summer, I volunteered to organize it.  What I did:

• Printed out last year's camping duty list, announced that I was posting it two weeks ago.
• Collected the duty list and sent out email for the last few needed duties.
• Advised the shopping volunteer what to buy
• Sent out a public email answering the questions individuals had asked
• Kept track of which spots were free and directed arrivals (sounds like work, but wasn't really, more like socializing)
• Triggered volunteers when to begin lighting the grill, and the campfire
• Approved people's suggestions (people wanted to know if a suggestion would interfere with other plans so wanted some kind of coordination check, not really approval)

This didn't seem like work to me but it met with widespread gratitude.  An organized point of information exchange is really what I was, timekeeper, and a maker of trivial decisions.  Software projects call these people project managers, but they exist in all kinds of domains, sometimes with different names, sometimes with specialized expertise.  Sometimes the project manager is just an organized person holding the clock, the task list, and the notebook.