The Future IT Executive

Catching up on my NLP, wikipedia found what I was looking for

Jerome Gagner — Mon, 28 Sep 2009 05:09:26 +0000

http://en.wikipedia.org/wiki/Natural_language_processing

I was trying to figure out a sentence that demonstrated to my less software development inclined friends that explained some of the mature problems with computers understanding human communication. Wikipedia has a nice example (I particularly like the “I never said she stole my money” example):

Some examples of the problems faced by natural-language-understanding systems:

The sentences “We gave the monkeys the bananas because they were hungry” and “We gave the monkeys the bananas because they were over-ripe” have the same surface grammatical structure. However, the pronoun they refers to monkeys in one sentence and bananas in the other, and it is impossible to tell which without a knowledge of the properties of monkeys and bananas.
A string of words may be interpreted in different ways. For example, the string “Time flies like an arrow” may be interpreted in a variety of ways:
- The common simile: time moves quickly just like an arrow does;
- measure the speed of flies like you would measure that of an arrow (‘time’ being an imperative verb and ‘flies’ being the insects) – i.e. (You should) time flies as you would (time) an arrow;
- measure the speed of flies like an arrow would – i.e. Time flies in the same way that an arrow would (time them);
- measure the speed of flies that are like arrows – i.e. Time those flies that are like arrows;
- all of a type of flying insect, “time-flies,” collectively enjoys a single arrow (compare Fruit flies like a banana);
- each of a type of flying insect, “time-flies,” individually enjoys a different arrow (similar comparison applies);
- A concrete object, for example the magazine, Time, travels through the air in an arrow-like manner.

English is particularly challenging in this regard because it has little inflectional morphology to distinguish between parts of speech.

English and several other languages don’t specify which word an adjective applies to. For example, in the string “pretty little girls’ school”.
- Does the school look little?
- Do the girls look little?
- Do the girls look pretty?
- Does the school look pretty?

We will often imply additional information in spoken language by the way we place stress on words. The sentence “I never said she stole my money” demonstrates the importance stress can play in a sentence, and thus the inherent difficulty a natural language processor can have in parsing it. Depending on which word the speaker places the stress, this sentence could have several distinct meanings:
- “I never said she stole my money” – Someone else said it, but I didn’t.
- “I never said she stole my money” – I simply didn’t ever say it.
- “I never said she stole my money” – I might have implied it in some way, but I never explicitly said it.
- “I never said she stole my money” – I said someone took it; I didn’t say it was she.
- “I never said she stole my money” – I just said she probably borrowed it.
- “I never said she stole my money” – I said she stole someone else’s money.
- “I never said she stole my money” – I said she stole something, but not my money.

VMWare Acquires SpringSource

Jerome Gagner — Mon, 10 Aug 2009 21:56:55 +0000

http://blog.springsource.com/2009/08/10/springsource-chapter-two/

WMWare is looking to acquire SpringSource. This is huge. I’m very excited to see what happens as a result, and think it will become a very worthy competitor with Microsoft’s .NET/Azure platform. I think their next step should look towards buying Terracotta and putting another barrier between them and Microsoft.

However, what I personally find to be the most exciting thing is what this will do for the Grails framework. I believe this will bring legitimacy to the Grails framework. Hopefully the guys over at VMWare realize the opportunity to bridge the gap between “Agile Frameworks” and the enterprise that is inherent in the Grails architecture.

I hope to analyze this a bit more tonight, I just wanted to get my thoughts out there and see if anyone agrees.

The Agile Team Room: A Breakdown

Jerome Gagner — Tue, 30 Jun 2009 22:57:22 +0000

For the last couple months, the Lean Promotion Office (which so happens to include myself) has been working diligently to get our collocated “Agile Team Room” up and running. A lot of thought went into how we put it together, so I’d like to share the result with you.

We’ll start off with my office. As a software engineering manager here, I have to give reviews, set pay, fire and make tons of phone to our office in Wisconsin so I need an office. However, I’d rather been in the trenches with the team, and honestly spend a good 70% of my day out there pairing with them.

My Office

As we step out of my office, we see a large open room, capable of housing two teams. Right now we only have one team in the Seattle office.

Team of 4. 2 Devs, 1 QA 1 BA

Next we see an office reserved for anyone to use the phone and a RDC capable computer. We don’t have phones for those in the team room (too distracting), but we do want to allow them to communicate with their counterparts in Wisconsin, or even step out for a private phone call.

Computer and Phone

Next, we have the breakout room. Still waiting on a whiteboard to go in there, but this rooms allows devs to go have a private impromptu meeting, without having to book any of the formal meeting rooms.

Breakout room

Here is the close-up for the beginning of our team’s self-prescribed charter. What goes up there are rules for the team, that the team decides, not management. Currently the only thing that has been decided are the core hours, as we’re still in Iteration 0 (doing a spike with a few technologies to decide on our stack).

Team Charter

These next two pictures are of our new cool pieces of equipment. In our old meeting rooms, we have a projector and a video conference system. We determined that purchasing the “LifeSize” unit and gettnig two large HDTVs actually saved us money on the set up, compared to the projector/video conference combo. Also, it’s really neat.

Andy, Mike and Paul

Andy

Although it’s not too clear, up there is a power outlet and a RJ45 (ethernet) jack. We plan to mount a projector there and project our Mingle card wall 24/7. Since we do have distributed work still, a tool is needed (as opposed to a “normal” cardwall). The cardwall isn’t present yet, because: the projector hasn’t arrived, and since we’re in iteration 0, all we have are a list of tasks to complete, no stories as of yet. The tasks are on the whiteboard, though.

Finally, the storage spaces. We spent a bit of cash to make sure that we have room for everyone’s personal things that works in the team room. We chose one with doors so it would still look clean. We actually have a lot of motorcycle (myself included) and bicycle riders at the company , so we felt this was important. Finally, the last image is the storage closet. Not too interesting, but I uploaded the image so why not.

Storage Cubbies

Storage Closet. Wee.

Overall, I think the team put a lot of thought and work into this room. Other than picking up some plants and a projector, I think it’s pretty complete. It even has transformers.

Weekly One-on-Ones

Jerome Gagner — Mon, 20 Apr 2009 17:47:31 +0000

I read “Behind Closed Doors: Secrets of Great Management” by Johanna Rothman and Esther Derby (Amazon link) a couple weeks ago. I am amazed at how much I learned from this relatively short book.

One of the practices I adopted from “Sam” (the character which we shadow during the book) is the weekly one-on-one. In which I:

Ask how they’re doing. Make a bit of smalltalk. This makes a huge difference, I learn a lot about my devs by doing this.
Check progress on last weeks goals. For the most part, the devs are very happy to report status as they’ve accomplished most of them.
Set S.M.A.R.T. goals for the next week. (OK, not always SMART goals, but we try our best to make them SMART goals)
Ask about obstacles to meeting any new or unfinished goals. I then ask if there’s any way I can help. I make sure I can actually provide help before I commit to helping. Often it’s just encouraging the developer to think about it a bit more, or to come up with two more alternatives.
Talk about career goals and how I can help. Most of that so far has been just loaning out books from my personal library.

I must say, in just two weeks, I have seen rediculous progress. I think overall I am much happier with my devs (because I know what they’re accomplishing each week) and they are much happier with me (they know what I expect them to accomplish). Keep in mind, we don’t neccisarily break it down to which tasks/user stories they’re working on. The goals are usually much more generic.

I try to keep the one-on-ones short and pointed. Last thing I want is for us to sit staring at each other.

Some things I’m working on with my team in on the one-on-ones as well:

Finding multiple solutions to a problem, not just jumping to a conclusion
Finding a way to report status without being cumbersome

I’ve also loaned out quite a few of my books to my devs. I have them optionally preparing “Brown bag lunch” presentations based off the books I loaned them out. These are 30-45 minute presentations that the developers prepare themselves on a topic. The presentation is given to all of the tech team during lunch

Overall I’m very proud of the progress my team as made, and I hope they’re happy with the progress I am making as a manager. If you have any suggestions on anything else to include or to work towords in weekly one-on-ones please comment. I always welcome suggestions and critism.

The Four Stages of Competence

Jerome Gagner — Wed, 25 Mar 2009 05:29:22 +0000

One of the reoccurring themes of the engagement with ThoughtWorks that I’ve found interesting is the concept of the four stages of competence:

Unconscious Incompetence – The individual neither understands or knows how to do something, nor recognizes the deficit or has a desire to address it.

Conscious Incompetence – Though the individual does not understand or know how to do something, he or she does recognize the deficit, without yet addressing it.

Conscious Competence – The individual understands or knows how to do something. However, demonstrating the skill or knowledge requires a great deal of consciousness or concentration.

Unconscious Competence – The individual has had so much practice with a skill that it becomes “second nature” and can be performed easily (often without concentrating too deeply). He or she may or may not be able teach it to others, depending upon how and when it was learned.

- Wikipedia

I’ve begun categorizing things I’ve done at this job and previous under the first two classifications. I’m seeing a lot of items that are stage 4, and perhaps I’ll talk about those in a later blog. That blog will be mostly bragging

The unconscious incompetence items are pretty easy to identify after you’ve been told you’re doing it wrong. However, I’m constantly mulling conscious incompetence items over in my head and trying to identify solutions, trying to get to the third stage. I just don’t see a clear path to correcting those actions. I find the things I’m doing that are conscience are done because I don’t think the situation permits fixing those. A lot of the excuses are along the lines of “Yes, I’m doing this wrong, but the way the project/organization/team/internal political climate is set up, I can’t fix it” Is that a valid excuse?

Prime example:

A coworker and I have made a valiant attempt to ease our organization into a more Agile project structure, at least within the development team on a project we run. We’ve done what we can with having a big upfront design. I’ve found it very hard to estimate, and done my best to break them down into INVEST (“Independent, Negotiable, Valuable, Estimable, Small, Testable”) abiding stories. However, the way the application specification is defined, along with the release expectation of the application being as close to spec as possible (read: not negotiable), really prevents me from doing what I consider a good job. Consequently, I consciously make the decision to “cheat” with the stories, and cheat with the point estimation, all with the intent of just trying to get it done (fortunately because of the amazing team, it is getting done).

I also know that cross-team interaction is fairly limited by resources and engagement, so I consciously allow (read: allow, not encourage) infrequent communication. Best attempts are made at doing a retrospective as well as a showcases, but I know that it’s almost impossible to do one properly with the current state of adoption and the amount of resources made available.

One could venture that I know how to run an agile team, and those things aren’t conscious incompetence, merely resultants of circumstance. I would consider understanding that these things are a problem, but not knowing how to fix them would classify as conscious incompetence.

A lot of the road blocks in the way are largely cultural, or things I don’t have the power to correct. How do you fix those things? How do you, in effect, override the “upper influence” and correct things outside of your circle of control?

An interesting point was made by a coworker of mine. He brought it to my attention that it’s not just your circle of control, but your circle of influence (I think he read it in “The Seven Habits of Highly Effective People”). How do you grow your circle of influence without crossing your political bounds?

I’d like to expound on that idea bit more, but unfortunately I’m dead dog tired. I just want to get these things out there, and possibly start discussing them before the thought gets lost in the clutter. I’d appreciate comments if you have them, and perhaps examples of how you’ve used your circle of influence effectively to change those things that are classified “conscious incompetence”, but outside of your immediate control.

Disclaimer

Jerome Gagner — Wed, 25 Mar 2009 04:55:36 +0000

I’d like to make a bit of a disclaimer here. Most of the ideas I’m going to write about are largely not my unique ideas. They are likely going to be my interperatations on information and knowledge I glean from others. I’m still in the learning and adoption stage, with a glipse of innovation here and there. When I come up with my own ideas and theories, I’ll make sure to make it apparent that I am generating theories.

Also, in order to protect the innocent some names may have been changed. I also will switch around “a current” and “a previous” randomly so you really have no idea what employer I’m talking about.

Finally, I’m going to try very hard to keep this blog from turning into a “complain about your previous/current employer”. These are blogs about what I learn, and what I consider my weaknesses to be. I’m very thankful for every company that I’ve worked for, and am working for.

Featured WMRRA Racer Today

Jerome Gagner — Tue, 24 Mar 2009 15:36:28 +0000

Doesn’t actually mean anything because it’s just a random rotation through the racer list, but it always makes me feel kind of cool. I’m actually an impressively mediocre racer, but I like the attention Check the screencap.

My Calendar is Ridiculous

Jerome Gagner — Mon, 23 Mar 2009 16:19:40 +0000

Quick post. My calendar is ridiculous. Friday is deceptively clear, it’s only monday and I’m sure it’ll fill up. I feel sorry for anyone trying to get time with me. Those small gaps will inevitably shrink as these meetings run over. Also note that I am in Bellevue, and my work day starts at 7 am (9 am Madison time). What I’ve found with schedules like this is that I feel like I was busy all day, but didn’t get anything done. In reality, I got lots done, just none of it tangible.

My Brief Experience With Lean Software Development

Jerome Gagner — Mon, 23 Mar 2009 01:46:34 +0000

I have learned a ton in the last week. I’ve had the privilege of working very closely with a ThoughtWorks organizational transformation team. We’ve gone through and analyzed our company’s value streams, and done some pretty extensive retrospectives on projects that we’ve done. I’ve learned some very good techniques for root cause analysis, most of which I’ve done some research on and found out that a lot of them are actually Six-Sigma techniques.

Most of the things I have learned in the last week have focused on “Lean Software Development”. I’m fairly impressed how nicely Lean lends itself to Agile principles, and even, as stated by Mary Poppendieck, serve as proofs for a lot of the practices. I’m personally very excited about how well Agile translates into higher level concepts proposed by Lean Product Development. I definitely feel this is the right direction to go for our company, and will carry these principles onto whatever lies in my future.

Over the next few weeks, I hope to do some more learning, and perhaps write about these techniques.

I’m also reading “Lean Software Development: An Agile Toolkit ” by Tom and Mary Poppendieck. I’m learning a lot from this book as well.

Here’s a list of the topics I have notes on.

Writing Agile Stories
Value Stream Mapping
Types of Waste from a Lean Software Perspective
Operational Development Streams
A3 Reporting
Management Metrics
Practices and principles of lean development

I’ve got a host of sub-notes and various other things. If any of these topics strike your fancy, leave me a comment or send me an email. If anything I want to write about them as to solidify what I’ve learned.

Finally, I’d like to attach a few pictures I took in the conference room where we’ve been working. From them it should be pretty evident the amount of work that’s going into this. It’s very exciting to us, because the progress and knowledge gained is all visible and for the most part, tangible. I’m such a nerd, I see these things, and find them very exciting. Everyone is so engaged, and everyone feels apart of the work going in, because they can very easily see the output, and make corrections where they see appropriate. It makes management feel good, because to be quite honest, it even *looks* like work is being done.

The business traveler

Jerome Gagner — Mon, 16 Mar 2009 05:05:38 +0000

Heading out for a business trip to wisconsin. Continuing to find improvements for our processes. I should have a few blogs to write when i get back.

I’m posting this from my iphone so please excuse any errors. I took a quick shot of the travel gear. Note the “I mean business” shoes. Also attached a picture of the sporadic weather forcast.