C:\Documents and Settings\{user}\My Documents\Seesmic\Seesmic Desktop 2\Plugins\

Now, think about the people that depend on you for the work you do (your employer, clients, fellow team members, family, etc). Do you think they should have the same expectations of you? Should they expect you to be staying current with your industry topics and practices? I believe that answer is Absolutely!

I wouldn’t choose a Personal Trainer that doesn’t research new developments in exercise programs, dieting, and supplements.
I wouldn’t choose a Financial Planner that doesn’t stay up to date on the options available for investing in my children’s education.
I wouldn’t choose a Leader that doesn’t continue to learn about ways to motivate, encourage, facilitate, and resolve conflicts.

So, would you choose you?

What separates these groups?  It’s the presence of four traits: vision, desire to learn, passion, and value of teamwork.

Vision is what keeps these people focused on the big picture in addition to their immediate tasks and surroundings.  They consider long term effects, understand how individual roles fit together, and are able to look at a single issue from many perspectives.  Passion keeps them motivated and always performing at their best.  It’s the excitement and reward they feel every day and is visible in their actions.  The desire to learn makes them ask “why?”.  They want to be taught to fish rather than given a meal.  They work to consume new information every day and grow from it.  Their value of teamwork encourages them to assist others and share information and responsibility.  They wear whatever hat is necessary, and often wear several hats at the same time.  They know that the most ambitious goals are possible with the right group of people.

Focus on creating teams with a majority of people from the left side.  Provide an environment and culture that encourages innovation and risk taking, does not treat change negatively, and invests in its people.  From this you will get processes that work well for your organization, an army of intelligent, productive, and efficient people, and an organization considered successful by any measure.

I approached the entire office with this proposal and was very thrilled to get buy-in from a large percentage of my coworkers.  I volunteered to do the first presentation and asked 2 of my more active coworkers to take care of presentations 2 & 3 just to get things rolling.  Presentation number 3 is next week and after several emails, no one else in the office has volunteered for presentation #4 (or any other future slot).

I found out that for 2 people, the problem was coming up with something to talk about.  I have provided topic ideas as well as offered to brainstorm with anyone that was willing to present but unsure of a topic.  Still… no one has offered to present.

At this point I’m assuming it won’t pan out.  I felt it was acceptable to send a few emails stating that we needed people for upcoming presentations seeing as how I got a large amount of buy-in before this whole thing started, but I’m not going to push it.  If no one comes forward, I’ll just continue giving presentations when I can hoping that maybe someone else will jump in every once in a while.

I have to admit, I’m a little confused as to why so many people thought it was a good idea but then won’t participate.  I even found out that for presentation #2 (I was out sick), no one set up a virtual meeting or conference call for the few remote people assigned to our office.  Furthermore, those remote people never IM’d, emailed, or called anyone asking what number to call in on or for an invitation to the virtual meeting.  Maybe I’m the only one that feels there’s value here…

A:  It’s simple… I want access to my fellow software engineers and technologists that live on the other side of boundaries that get created around other Departments, Products, Business Units, and Acquisitions.

True story. I had to quickly come up to speed on a technology I had not been introduced to previously.  I took the normal approach of aggressively searching online to find examples, white papers, blogs, anything to help.  Time was running out, and while I had learned a lot in a short amount of time, I wanted a little help connecting all of the dots and selecting what I needed to focus on to complete my task in a timely manner.  I needed 15 minutes with an expert in this technology to guide me down the right path, because I didn’t have time to go down the wrong one.

I jumped on Yammer and put out a call for help.  A development manager responded with the name of a person who he knew to be experienced with this technology.  He introduced us over email and a few minutes later, I was getting exactly what I needed.

1. you’re not hiring the right people

2. you’re not hiring the right people

3. you’re not hiring the right people

4. you’re not hiring the right people

5. you’re not hiring the right people

6. you’re not hiring the right people

7. you’re not hiring the right people

8. you’re not hiring the right people

9. you’re not hiring the right people

10. you’re not hiring the right people

Hopefully this comprehensive list will help you and your organization.  Cheers.

LOC

Finding the lines of code:    grep -v -r –include=”*.java” “^[[:space]]*$” * | wc -l

Number of Tests

grep -r –include=”*Test.groovy” “@Test” * | wc -l

Results

LOC: 706, Tests: 82

This yields a ratio of:   8.6 to 1

When filtering incoming mail, if it’s not something you need to read as soon as you have time, just tell it to skip the inbox.  This will cause the email to be immediately archived, but keeps it marked as unread.  This works especially well for many of the automated emails you receive from companies and websites (like Facebook) and gets you one step closer to Inbox Zero.

2. Hide Read Lables

Go into Settings and then to Labs.  Find “Hide Read Labels”, and enable it.  This causes labels that don’t contain any unread email to be hidden from view.  It keeps your screen a little less cluttered and allows you to focus on new emails.  Your labels are still very easy to reach, just start typing the label name in the search bar and it will pop up as one of the auto-fill options.

More to come as i figure them out!

In this situation, I knew what the system must do, but not the exact details of how it would work at the lower levels. I did enough work on a POC interaction with the Web Service to know that the basic direction I wanted to go was possible. At first I took straight to developing the lowest level API, as that’s where I had my most detailed requirements. From the knowledge I gained doing the POC, I had enough to start there. However, in the end this hurt more than it helped.

After TDDing my way through several of the requirements I had of the low level API, I found myself in a sticky situation.
1. Too many tests tied too closely to implementation
2. I felt like I was progressing a little slowly, having to stop and think too long about what needed done next
3. I ended up having to heavily refactor about 2-days worth of code because the tests I came up with, did not reflect the true needs of the system

Luckily at that point, I realized right away that my lack of higher-level tests were allowing me to steer the system off path. I needed these higher level tests to drive the requirements for the behavior of the lower level API. So, I started fresh, writing a single acceptance level test that defined a small feature of the system. I continued to work my way down writing more tests until I couldn’t write a smaller more precise test without controlling the implementation details. That was my cue to start coding, and get all those tests I had written to pass.

The results..
1. Just enough code to meet the requirements. No more, no less.
2. Fewer tests tied directly to implementation details
3. A thin, vertical slice of functionality

First of all, I want to mention that a lot of the conversation went back to the Cost of Change curve. Take my code compilation example. Finding a compilation error in real-time will (theoretically) make the cost of fixing the error cheaper than finding it after a day of coding. The example was that using an IDE that performed real-time compilation was a much shorter feedback cycle than going to a command prompt and running your build manually. The other notable example that builds on the Cost of Change Curve was scheduled code reviews (montly/weekly/etc) vs. pair programming.

One of the final feedback cycles I presented was that of the completeness of an individual feature of the system. We talked about the Cost of Change Curve here as well, but most of the discussion focused on what other things we may get by reducing this feedback cycle.

I began by talking about how a single feature progresses through the Waterfall process. Pointing out that you won’t get feedback on the completeness of a single feature until you’ve reached the Validation phase where your QA has had a chance to test the feature. This gives us a feedback cycle of the length of time between when dev initially started on this feature and when it was tested during the Validation phase. How long are we talking here? Months probably.

So, now it’s time to ask how one would reduce that feedback cycle. In order to do that, we need to bring the validation phase closer to the point at which development began on this feature. Since the traditional Waterfall approach moves the entire software system from phase to phase, it’s not possible without re-defining the process.

We then took a look at this feedback cycle in Scrum. Sometime after the start of a sprint, you start development on one of the user stories you’ve selected (aka feature). Considering the goal is to deliver this feature at the end of the sprint, at some point you’re going to validate this feature, completing the feedback cycle. So, here, the feedback cycle is at most 1 sprint.

We continued the discussion down the path of what things we get by reducing the feedback cycle in this way. The most profound impact is on our feature estimation because the feedback cycle on feature estimation accuracy is directly tied to the feedback cycle on feature completeness. Now that we’re attempting to complete individual features within a single sprint, we’ll also get feedback on our estimation of that feature within the same sprint.

We spent some time talking about what you can do with this information. Essentially it means that you can better estimate the remaining features of the system. This in turn gives you a more accurate project schedule, which in turn allows you to confidently discuss project timeline and budget predictions with stakeholders and customers. Also, when someone asks what features won’t make the deadline, you’ll be able to answer that question and others like it.

Hopefully that’s enough text here for you to get a feel of the presentation. Feedback cycles is a broad topic. In this presentation I hit some things at a very high level and went a little more detailed on others. My goal was simply to communicate that reducing any feedback cycle is beneficial (some to a much smaller degree than others). I also needed to address a wide audience: devs, qa, project managers, etc. While I did get some great feedback from a few of the attendees, I do remember seeing a few faces that looked lost. Maybe I’ll follow up with those people.