It really impressed me to find out our managers were applying SEP’s Envision discovery practice techniques to help understand what we needed to do. They worked with personas (see pictures for examples). One represented the client (Cam) and the other an SEP project manager (Pete).

The team is running through the Envision process doing measurable product goals, personas, story-boarding – whatever makes sense.

It is interesting to me that processes we have come to trust for software product development to ‘build the RIGHT product’ should and could be used to help us build better practices, tools, etc. It is a validation of the principles behind the approaches:

- Engage as many different types of stakeholders in the process as you can
- Concentrate on the end user and the end result
- Follow the value
- Be prepared to increment/learn
- Build it in paper first
- Stay visual

First, write tests that fail…wait, what!?!
Brian took an interesting approach to the problem.  No, he didn’t open up the code and try to walk me through the method calls…instead, he opened up our test project and showed me the tests we already had written for the scheduler.

Next, we wrote a couple of unit-tests to cover the new behavior.  As you can expect, our tests failed.  To be honest, I didn’t really understand what Brian was trying to do…I _knew_ the tests would fail.  In reality, though, now we both understood exactly what the problem was, and we both knew exactly what the new behavior should do.

By writing our tests first, we both had a shared understanding of what the new behavior should be.  I still didn’t know everything about the scheduler, but I knew everything about the change we were about to make!

Next, isolate the issue…
Now that we had tests that were failing, Brian and I added a couple of methods to our scheduler that we thought would achieve our desired behavior.  We wrote enough code to satisfy our unit tests.  And then we ran those tests again.

As you’d imagine, now our tests are passing.  And honestly, I don’t think we saved any time by doing things in this order.  However, what we did do, was isolate the issue.  Our changes were minimal, and we simply added some methods to exercise the new behaviors we wanted.  Pretty simple.  But unit tests don’t tell the whole story, right?

Then, wire up your changes…
The last thing we did was wire up our new methods in the appropriate places.  For example, we simply added the new checks to our scheduler before we  actually displayed a notification to our users.

Finally, relax…
Not only is my confidence extremely high that our changes are working, I’m also confident we didn’t change any of the existing behaviors (because we already had tests for those behaviors).

Ultimately, if you want to be confident in your changes, write your tests first…go ahead, I dare you

The trend? Our managers are applying some of the awesome agile/lean principles we use in software development to management areas. I have several examples to write about. The first is the most noticeable to us and perhaps the simplest.

Recently a large diagram appeared on a hallway on our fourth floor. It is hard to see its size in the picture. It is VERY large – 6’ x 19’. SEP is in the process of re-looking at its practices for proposal development, client relations, high-level project tracking and business development. These areas interact with software development and project management. It all has to integrate and it all has to add value.

The task was daunting considering the breadth we needed to consider and our desire to get input from a lot of people. So this wall shows up. At first it just hung there and it was pretty overwhelming with a lot of empty space. We haven’t had any stand-ups around it yet and so far there hasn’t been a lot of talk about it.

Slowly people with an interest in these areas began to post notes on the board in pencil. Recently pictures were added that represented topics that need to be considered: networking, conferences, business development and marketing. It was interesting to me that the addition of these pictures really made the board more engaging.I mentioned that this was a simple example of Agile/Lean principles – ‘make the work visible’.

As time goes on this simple visual tool will become the central focus of a team of people working to make these areas better. If we just let this map alone, unaided and supported I suspect that a team would self-organize around it. That is the way it works.

The main goal of Envision is to develop a shared vision for a product. The process is very visual so it is easy to include both technical and non-technical representatives and stakeholders.

Envision also helps prioritize product features. This yields much leaner product footprints tightly matched to the targeted markets and users. The result is a shorter and less expensive path to market.

Envision also supports a multiple release strategy for product deployment that is so key in developing products for the new, developing markets we are seeing. For example, look at mobile device applications. Users expect frequent updates with new content. We have seen that it often take several releases to the market to get to a successful offering.

Envision begins by first getting everyone together. SEP provides the discovery team including the facilitator. We like to get a broad representation of people to participate, really anyone who can bring value and input.

The SEP facilitator leads the group through a series of exercises that result in a strong common vision for the product. We use visual models that anyone can be taught to understand. As the sessions continue we move from high-level product goals, to user personas and storyboards.

Seeing the visual model of the system and its potential features the discussion moves to “right scoping” and release planning. This is where the group takes a hard look at the potential product features, deferring, removing and prioritizing them.

At a high level, we are planning feature-dense releases of the product designed to fit the marketing approach and product goals. Between each release to the market we assess market response and this input is used in planning the next feature-dense release of the product.

The goal is early and often releases to the market with quick response to market/user input.

This is really the future of software product deployment and it is the direction SEP is committed to taking.

Instead, I’m going to focus on the User Experience and ways to improve your lists.

To see a really well implemented ListView, take a look at the contact list on your phone.  It is consistent, generic, and responsive.  You can fling the list, and it glides smoothly.  You can easily follow down the left side until you see the name you’re looking for.  And you aren’t distracted by any rows that stand out like a sore thumb.

In this post, I want to talk about ways that you can make your ListView as good as  the contact list.

Patterns for responsiveness:

First, let’s talk about some of the “crunchy stuff” – the code.  There is a lot you can do to make your Java more efficient, but that’s not where the bang-for-the-buck is at.  You really need to take advantage of some of the tools that Android has put in place.  Namely, the convert view and the tags.  Below are 2 patterns that you can use to improve the responsiveness of your list.

Recycling pattern:

The recycling pattern makes use of the convert view.  Inside your ListAdapter, there is a method called “getView()”.  You may have noticed that one of the parameters in that method is called “convertView”.  Making use of the convertView can significantly reduce the number of calls that are made to the LayoutInflater.  The way that Android wants you to use the convertView, is to recycle the views contained in each row.

This is important because as the user scrolls, many rows are coming in and out of the screen.  Because this is a list, the views should largely be the same components, just with different data.

Going back to our reference from above, the contact list simply has an image, name, and description.  That translates to one ImageView component, and 2 TextView components.  Each row is identical in structure.

Below is an example of how to use the convertView in your ListAdapter.

In this example, we only inflate the view if convertView is null.  Otherwise, we simply set the text to “foo” without inflating.

Biggest bang for your buck, right there.  A simple null check before inflating, and that’s it.

Holder pattern:

The holder pattern uses a class to hold references to your view.  Just as inflating a view is expensive, so is calling “findViewById()” each time you want to access a widget in your view.  This pattern is a solution to a common problem in most UI Toolkits…getting references to a widget.

The normal way that you would get/set data in a widget is by finding the view by ID, and then calling the appropriate method on that object – e.g. when we called setText(“foo”) in the above example.  As you can imagine, in a list this gets very expensive.

Below is an example of the Holder pattern.

So, in this pattern we are using tags, instead of IDs.  The holder is responsible for holding the tag so that you only ever have to make 1 call to findViewById().  We still use the convertView as we were previously.  And finally, you bind your data through the holder, instead of directly to a specific view object.

There’s always an exception…

Now, these patterns are great…but these patterns don’t fix everything.  They only help address the responsive aspect to your list.  In fact, they lose a lot of their impact if your view is not generic.  If different rows of your list have different items in the view, then both of these patterns will only have minimal impacts because you won’t be able to recycle views (convertView will be null each time the view changes) and the holders will get updated regularly.

Simplicity wins

The biggest improvement you can do is to actually make your list generic and consistent.  Below are some less crunchy ways to improve your design.

Generic views – defer secondary content

Use the fewest pieces of information to identify the item, and use a dialog to display more information if the user is interested.  Defer all of the secondary content and additional actions to another screen or dialog.  The more content you put in a view, the more work you are doing with binding and updating data.

Again, the contact list simply has an image, name, and description…that’s it.

Consistent – don’t conditionally modify the view

Unless you absolutely need to uniquely identify a row…don’t!  Don’t worry about modifying the views in each row.  It actually causes more problems for the user if items are not consistent in a list.

Adding small tweaks here and there add up quickly and become noisy distractions (e.g. color-coding backgrounds, re-arranging items, or adding/hiding items).  The more inconsistent your views are, the more conditional display logic you’ll have to write.  And the more conditional display logic you write, the slower your scroll speeds…not to mention the more confused your users will be.

In Summary

The biggest increases you can get are actually in making your view hierarchy as simple as possible.  It increases usability, and decreases complexity of your code.  The next time you’re implementing a list, give it the “fling” test, and see if it is smooth and consistent as it scrolls by.

Remember, your aim should be to create a product that is both simple and elegant, as well as, a product that is desirable to use.

The above patterns and snippets are based off of the sample List14.java from the SDK samples.

This time, let’s take a look at the Android AsyncTasks.

AsyncTask enables proper and easy use of the UI thread. This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers.

The AsyncTask class takes care of all of the hard work for us!  Because the AsyncTask runs in a “worker thread” as part of the UI Thread, you are not guaranteed that it is running in a multi-threaded model.  Instead, it is executed in an asynchronous way.

Knowing how your application lifecycle impacts your user interface plays a big role here.  Typically, using an AsyncTask is appropriate because your application is likely the only foreground Activity.

While the details of this post rely on using an asynchronous model, I’m not going to cover the details of process/thread models.  Instead, I recommend taking at look at this introduction to asynchronous programming.  The author, Dave Peticolas, has some great graphics to illustrate the differences between those models – single-threaded, multi-threaded, and asynchronous. (Thanks @_swanson for sharing this!)

So, what does it look like?

An AsyncTask is actually really easy to implement.  The AsyncTask goes through 4 steps

• onPreExecute() – called immediately after the task is executed, used for setup
• doInBackground(Params…) –  used for long-running tasks
• onProgressUpdate(Progress…) – used to display progress to the user, for example “On step X out of Y”
• onPostExecute(Result) – called immediately after the task is finished

The interesting steps are “doInBackground” and “onPostExecute”.  Below is an example that covers both of these.

That’s all it takes to implement your AsyncTask.  Simple, right?

The beautiful part about AsyncTasks is, the “onPostExecute()” method is able to update your view.  This is powerful because you don’t have to worry about some of the issues we talked about with Handlers, where the view elements might return a Null Pointer Exception.

The 3 generic types that are used by the AsyncTask make it very flexible, as well.

So, how do I use it?

Using the AsyncTask, is even easier than implementing one.  All you do is call “execute()” on your task.

You don’t have to make any calls to the 4 steps mentioned above…calling “execute()” will do all of that for you.

I recommend waiting to execute your task until your view has been loaded.  That means, normally you can execute that task as early as in your “onResume()” callback.

However, you may have other dependencies, like a database connection or a service connection, that require you to wait until that connection is established.  In those cases, I recommend using a BroadcastReceiver and executing your task once that receiver is called.

If you find yourself struggling with finding the right time to execute your task, or perhaps you have multiple tasks getting chained together, or maybe you have implemented some handlers to execute tasks (or vice versa), you should consider looking at one of the many Android Service types.  I will cover services in the next post.

Android Thread Series:

1. Overview
2. Handlers
3. AsyncTasks
4. Services and Messengers
5. Conclusion

When the question comes down to which matters most — skills or education — we have to break it down a bit more. It’s hard to downplay one or the other; obviously a balance is good.

We don’t specialize in one technology or one product here at Software Engineering Professionals. In fact, I have already mentioned that variety is not an option; it’s a requirement. If you don’t have a good foundation for learning new things, it would be difficult to keep up with the variety at SEP.

In the book Apprenticeship Patterns, the author focuses a lot on how to “empty your cup” and learn new things.  This is where education plays a role.  Education is a great foundation for you to fall back on.  Most colleges/universities require you to take many classes that are not related to your core focus – software development.  I studied Computer Engineering in college, and I really only knew one programming-language before I started working here. But if I hadn’t pursued the education I did, it would have been harder for me to learn new things and understand the new technologies I’ve learned since joining SEP.

Formal education won’t get you everywhere, but it’s certainly a good basis for learning new things. There is a lot of professional maturing that happens once you enter into the workforce, but being in school to build that foundation and learning how to learn is the most important first step.

So in the matter of skills versus education, I say that both are important…but education comes in first.

Okay, I hope you enjoyed the video.  That video inspired me to write this post.  For those of you that know me, I’m an eternal optimist – I try to find the positive in everything.  For me, to learn that there is research that supports focusing on the positive is great.

Re-live Positive Experiences
Shawn recommends journaling about at least 1 positive experience each day, so that your brain can re-live those experiences.  According to Shawn’s research, your brain performs significantly better when you are being positive – you are 31% more productive.

Imagine if an entire team was sharing positive experiences, and the entire team was re-living each of those experiences.  This could drastically change the productivity of the entire team.  And by doing so, we can create ripples of positivity and productivity.

Finding Positive
If you have a lesson-learned that you would like to share, talk about it as if it is a fact (it is history, after all), and try to avoid stirring up unnecessary emotions from the past.  Instead, talk about what you learned, or how you overcame the issue.  It’s easier to find the positive when you focus on what you learned, instead of the problem.

Another approach is to try and “right-size” the problems.  Mark Nepo has a neat story about right-sizing your problems - a handful of salt in a glass of water, the water tastes salty; whereas, a handful of salt in a lake, the water tastes fresh. When you right-size the problem, you realize that it isn’t the end of the world, and it is easier to find the positive.

How to Practice Positive
Let’s take baby steps.  Start by talking about something positive that happened earlier that day, or the previous day, so that the entire team can re-live that positive experience.

If your team meets on a regular basis, like a stand-up meeting, perhaps you can recommend that each person shares a positive experience.

I am going to channel “Amy-the-unicorn”, and start practicing positive…what about you?

One way to show that you are capable in a certain skill-set is to get a certification.  Of course, there are plenty of discussions already about the value of these certifications.  And besides, how do you _really_ prove that you have this certification?

Well, Mozilla’s solution to this problem is similar to merit badges, but with a secure infrastructure around it.

Learning today happens everywhere. But it’s often difficult to get recognition for skills and achievements that happen online or out of school.  Mozilla Open Badges helps solve that problem, making it easy for any organization to issue, manage and display digital badges across the web.

However, will this catch on?  Can these badges be standardized?

It’s already happening
Of course they can, especially in an industry with a long history of standardizing certifications. We already see this in the knowledge industry…we have had certifications as long as I can remember.

So the idea of a standardized approach for recognition isn’t new.  However, what _is_ new is that this type of infrastructure makes use of gamification to recognize, motivate, and award people.  Instead of simply rewarding you with a piece of paper, and sometimes adding some cool acronyms after your name, you can now display your badges wherever you want!

<tangent>
For the record…gamification isn’t new either.  Joey Strawn has been talking about gamification for a while (and has lots of good articles about it, too).

Companies have been successfully using simple gamification techniques in order to motivate customers to return to their shop/restaurant.  Just think of all those loyalty cards, stamps, and contests that your favorite restaurants have!

Also, you may recognize a website where Joel and Jeff (from codinghoror) used gamification to innovate the industry back in 2008 as well. *cough* Stack Overflow *cough*
But let’s save gamification for a different blog post, at a different time, I have enough to talk about already here!
</tangent>

Certificates are already a big deal
You can get CompTIA A+ certified for PC support. IEEE offers Brainbench exams for its members to earn certificates in a number of areas, from design and media to databases and programming languages. Microsoft Certification is another huge one…I’m lucky to be sitting right next to a Microsoft Certified Professional Developer at work every day.

My point is…there are already plenty of examples of companies and organizations offering proof of knowledge, or a level of experience…and some of those certifications are pretty elite! (For the record, there aren’t many developers with the MCPD certification.)

So why Merit Badges?
Merit badges are a likely next step for standardization. Instead of having a formalized certificate that most people file away and never show (except for a line on a résumé), you’d have an iconic, graphical merit badge that’s simple to display and also better visually communicates what you’ve accomplished. Show them on a visual résumé, or display them on a personal website. Maybe even LinkedIn could let users start including badges on their personal profiles (similar to the group icons already).  And heck, maybe even motivate people to keep learning!

How cool would that be?

Admittedly, standardization will take work.  Especially as the knowledge industry grows and changes. New certifications are already added rapidly as technology changes, so creating and certifying badges can probably be part of the same process. The important thing is that the association responsible for administering the certifications/badges also offers some kind of guarantee that if someone uses it, they actually do have that badge.

We will just have to see how Mozilla handles the “guaranteed” part of it.

Differentiation is important
These badges could also help differentiate yourself from others.  Let’s face it, doesn’t everyone have Microsoft Office listed on their résumé?  Couldn’t we all join the same LinkedIn groups/associations?  These badges would be a way to differentiate.

I really like what Mozilla is doing with the badges.  I hope it catches on, and I really hope the badges can become the new standard.
I hope it goes above a standard, and encourages all of us to continue learning!

What are you waiting for?  Head over to Open Badges now, and earn some badges!

As a leader you must earn the trust of those who you entrust to do the day to day work. Trust must first be given before you can expect to receive trust in return. Gaining trust has a fairly simple formula:

• Let your actions speak for themselves
• Hold yourself to a higher standard than you hold those who work for you to
• Never ask them to do anything that you wouldn’t do yourself
• Nurture them
• Give honest feedback
• Reward them

Rewarding your people starts with honest feedback. Congratulate them for a job well done. Words of praise go quite a long way. Rewarding your people, however, is an interesting double edged sword. Reward too much and you make it commonplace. Reward too little and they feel unappreciated.

I have struggled with rewards over the years. I expect a lot out of people who work for me. I hold them to high standards. Each and every person who works for me has met or exceeded my standards. They are some of the best people that I have ever had the honor of working with / for. With holding people to high standards, rewarding them becomes difficult. Even the amazing becomes commonplace and an expectation after a while.

When I returned from my hiatus in January I realized that I had a problem. It took me a while to see the root cause of the problem but the symptom was as plain as day: I did not have a way to reward the people who worked for me.  The problem, as I realized after a few weeks of working on the symptom, was that I now had a significant number of people working directly for me ~24.

As I worked to figure out the root cause of the problem I decided that I would address the symptom as a stopgap measure. The stopgap measure, which turned out to be the right answer, was to create a simple currency: Pieces of Charles™. (Not my choice on the name) They have a humorous design (see below) and aren’t really worth much other than the fact that they are a symbol of recognition. Recognition of greatness is a powerful thing.

I realized that I couldn’t reward people anymore because I could not see what they were doing to the same degree that I could before. I did not have that insight due to the sheer number of people that I was working with. So, I print-minted 70 of the Pieces of Charles™ and handed them out to the only people who really could see the day to day MOGs: the team leads. Pieces of Charles™ were to be given out as on-the-spot rewards for moments of greatness (MOGs).  I empowered the team leads to reward the extraordinary, and they have. I have also empowered the teams to let me know if there is someone going above and beyond so that I can recognize them as well. It has worked out surprisingly well.

Now, I know when people are doing great. I know the people who are exhibiting the behaviors we want to encourage. I know that my team leads are able to reward those who need it.

You may be curious as to what would warrant a Pieces of Charles™ and I will provide several instances where people have shined below but this is not an exhaustive list:

• Trevon Sutton – He has worked tirelessly on making the client better and raising the bar for testing in general at the client site. He has put in a significant number of extra hours as well as his own free time to this effort. He is one of the clients main go-to guys now for testing.
• Trevon Sutton & Chris Pierce – These gentlemen have created a testing framework which will help the client to handle internationalization issues for a product which already has several thousand tests written against it. The majority of this work was done on their own time.
• Chris Pierce & Allen Cummings – These gentlemen have worked incredibly long hours with the client to fix a broken network over the past two months. They have done this in addition to their regular work, resulting in long hours and difficult product deliveries for the team.
• Jen Dillon – She has helped the client to improve their traceability from requirements to test. In this effort she presented her findings, defended her results, and provided a good path forward to members of management at the client which were several levels above where we normally step. I was in the meetings and the questions directed to her were extremely direct and at times callous. She acquitted herself well as both an engineer and as a SEP employee.

Throughout all of this the teams have continued to do great and in fact may be doing a little bit better than before. The weather ahead looks good.

Like any recruiter, I focus my search first on people who have worked to earn their degrees in engineering, computer science, mathematics and other related fields. But holding the perfect degree isn’t a hard and fast rule. We also look for a good GPA and strong involvement in campus organizations, extracurricular activities and other things that make candidates more well-rounded.

What is better than just a degree?
Better than just a degree, we look for passion. I know that sounds a little clichéd, but we don’t just say it to wear out the phrase!

What we look for above all things is someone who’s a hobbyist. I want to hire someone who loves the work they do and has pursued their passion outside their normal coursework. I want to see someone who’s contributed to an OpenSource project, created their own mobile app, turned out some product that they’re proud of and ready to spend a few minutes presenting to us to show us they’ve gone above and beyond.

Bonus points – community involvement.
I want to see a candidate who’s spent time browsing topics and questions on Stack Exchange/Stack Overflow, provided good answers to other users’ questions and earned a good reputation among members of those communities.

Simply doing well in classes isn’t enough anymore. Textbook-learning alone can be outdated, and technology progresses much more quickly than textbooks can be updated and printed.  You can get bonus points by being active in the software community.

I’m looking for people who are applying what they’ve learned in school and gone beyond their traditional education, people who would be programming and working with computers even if they didn’t make a career of it. We are hiring for passion!

This is my slide-deck from a BrownBag @_swanson and I gave late last year.

Recap of presentation:

• Lead with some common language, to get everyone on the same page
• Tried to draw analogies between git and TFS
  • covered many of the features and actions that our team uses in git
• Talked about our team process
  • both local process and remote process
• Talked about how git saved our bacon
• And of course, our great finale was a demo
  • demo of both CLI and GUI

Finding the Right Resources

This is all about bringing in the right combination of talent with the right type of skills when you need them. Many times, companies use outsourcing because it can fill in gaps where they are trying to get something done and they do not have the right resources or the right amount of resources (or the time and money to track them all down). Resources can be people or equipment.

Energy/Leadership Conservation

One reason outsourcing is superior to hiring contract employees is it conserves energy and leadership. When you are outsourcing with a good partner, being a leader should be one less thing that you are worried about. You can devote your energy to other needs. You should not have to manage it – the outsourcing partner provides most of the leadership and energy in managing a project. Not all of it, mind you, but a large chunk. Outsourcing takes the headache of insuring a project gets done and off of a manager’s plate.

Protection of Focus

It is very difficult to be top-of-class in more than one area, and very few can maintain two core competencies. When you are outsourcing, you can outsource to a partner whose core competency is software development. Those companies that try to do too many things really well don’t do anything well. A lot of larger companies can understand this from experience and often startups have to consider outsourcing. Startups can free up their focus by outsourcing non-essential functions. So many companies whose background is not software development are finding themselves deploying software products. It can be much more effective to work with an outsourcing partner than to add another core competency.

Get Unstuck

For many companies, there are a number of projects that are on the books, waiting to be finished or something they want to put in place; however, it seems as though it never gets done. When managers take time to actually sit down and look at the project, it is usually a combination of things that are blocking it from being completed.

Maybe the company does not have the leadership. Perhaps the company does not have the right resources. Or it may be that the project just is not the company’s primary focus. One of the primary benefits of outsourcing is that you can get things done that have been stuck in the queue for a while.

Get Fast

Many companies are used to churning out a project slowly – maybe once a year. This approach doesn’t cut it for the new fast-paced consumer markets developing.

We have found that even when a large organization has a software development capabilty, their teams were not designed to move fast and adapt quickly to change. Bringing in a specialty partner can cut cost and time to market significantly.

We like to encourage companies to consider the complexity, volatility and domain knowledge of a project when deciding whether to do it internally or not. Fast moving, complex and changing projects are often best done with an outsourcing partner.

Part of the reason why I used to struggle so much was because I would basically wing it when I finally sat down with the other person.  And let me tell you, winging it was not the best approach.

Inspired by Raman Ohri and Tom Sant, I wanted to share how I approach difficult conversations, now.

Having a difficult conversation can be hard.  (Duh.)  In order to organize your thoughts, it helps to have some structure. Without a structure to lean on, it is more difficult to have a healthy and constructive conversation.  Your intentions may get missed, or people may get hurt.  Ultimately, you may do more harm than good.

So when you’re in the difficult position of having a difficult conversation, remember this familiar little acronym – S.O.S. (Symptoms, Outcomes, Solutions).

Symptoms

Take a snapshot of today, and describe (from your point of view) what you see.  Keep it about you, and your point of view, though.  And try not to project a perceived behavior or motive onto the other person.

An example of projecting would be “You aren’t doing X”.  When the symptom is actually “I don’t know what the status of X is.”

Outcomes

Forecast a little.  Describe how you see things turning out if we don’t address the symptoms.
Outcomes are helpful to paint a picture of what is not acceptable to you. They’re also helpful in exposing differences in context and perspective – maybe the bad outcome you fear isn’t actually a big deal or isn’t something anyone thought about. You won’t know until you have that conversation.

Solutions

No, you shouldn’t expect to come up with the solution on your own.  But you should think about possible solutions and offer them in an emotionally detached manner – “here are some things that might work, but I don’t know if they are the right solution”.  At the very least, try to get some of your assumptions validated.

Another “trick” is to write each of the Symptoms, Outcomes, and Solutions out in complete sentences.  By writing them down, you’re forcing yourself to put enough thought into it to have a discussion.  It has the added benefit to keep you on track during your discussion, should you get side-tracked.

So, when you are about to have a difficult conversation, just remember S.O.S.

Utility is your table stake.

Without utility, you don’t have a product worth using.  In addition to utility, there are things like usability and aesthetics.  I’m not going to cover those in detail in this post.  However, both usability and aesthetics can be summed up into one word – desirable.

Imagine driving on a road with the below sign…

…probably not your favorite interchange, right?  What if it was someone’s first time driving in this area?  Or worse, what if the driver was a teenager who recently got their driver’s license?  This would be a nightmare.

Imagine driving on a road like this…

…this road _barely_ has utility, if you ask me.  While you could drive on this road, you would have to slow way down and dodge this rough patch.

While both of these roads have utility (they are both passable), neither road is desirable for most drivers.

This picture of potholes is a good reminder that you can’t construct a road and then forget about it either, you have to maintain it.  Quick-dry patches over a long period of time result in a less-desirable road.  Ultimately, your users will find a different route.

Product engineering is no different.

Ultimately, you have to build a road that people want to drive on.  It has to be desirable!  Meaning, you have to build a product that people _want_ to use.

For example, this is the recently renovated Keystone Ave. here in Carmel, IN…

…this is my preferred road for many reasons.

Just as drivers choose roads for their daily commutes, users choose products for their daily uses.  Make sure you’re building a product that people would find desirable, in addition to your table stakes.

Ask yourself – Is your product desirable?

Well, it looks like Git Extensions grew some sweet new toys that take advantage of Windows 7.

If you haven’t played around with some of the advanced features in Windows 7, I highly recommend it.  The JumpLists are probably my favorite new feature.  There are 2 different JumpLists that I use on a regular basis – in the Start Menu, and on the Taskbar.  They reduce context switching, and allow me to do activities quickly.

Here is a snapshot of using the JumpList in the Start Menu…

…it allows you to jump directly to a recently used repository.  Very handy!

Here is a snapshot of using the JumpList in the taskbar…

…it allows me to commit, pull, and push from the taskbar.  This is extra awesome because now I don’t actually have to pull up Git Extensions.  Instead, I just keep it minimized now, and even _more_ out of the way.

Do any tools you use regularly have some cool/awesome/fun features that integrate with your OS?  If so, what feature and how does it impact how you use the tool?

Read about it here.

Follow us on twitter.

Ever find yourself in a rut?  You just can’t crank anything notable out this week.  It’s so obvious that even your teammates start placing bets on the over/under of you meeting an estimate.  (No seriously, it’s _that_ obvious, and it is happening right now, for me.)

Okay, maybe your team handles it differently than my team.  We’ve all been there, though – more refactoring than normal (sometimes all on the same blocks of code); less functional changes; and ultimately, less value added.

It sucks.  It’s a tough place to be, and you feel like you aren’t pulling your own weight on the team.

The longer you stay in your rut, the harder it is to get out.  These ruts are a dangerous place.  A rut can drain your energy and hinder your performance.  If you don’t find a way out of your rut in a timely manner, you can dig yourself so deep that it seems impossible to get out. We’ve all heard it – “I’m stuck doing [blank], even though I’m not interested in [blank].”

So, to get out of your rut, you need to build up momentum.  Let’s look at what momentum is…

Well, mass is negligible, right?  It’s the knowledge you’re dumping into your IDE, or the weight of the paper you’re doing some discovery on, or conversations/emails you’re having with other people.  Effectively, we are left with…

With that, we know that velocity isn’t just your speed, or how fast you’re typing.  It is a vector…it has to have a direction.  If you aren’t moving in a direction towards the end goal, then you’re not moving forward.

This means that momentum, in our world, is essentially how well you can move towards your goal – whether your goal is developing a feature, fixing a bug, writing an email, or something else.

And according to the law of conservation of momentum, once an object has momentum it will continue to have momentum.  Or in more laymen’s terms – once you get the ball rollin’, it’ll keep rollin’.  So to get the ball rolling, you have to continue making strides towards your end goal.  If you run into a road block, pivot on what you’re doing, and try not to let that wall stop your momentum.

If you take into account Newton’s Third Law of motion, each action has an equal and opposite reaction.  So if you find yourself running into road blocks, you have to change directions.  If you don’t constantly change directions with each road block, you’ll stop having velocity, and effectively stop having momentum.

So the key to overcoming challenges with momentum is to remember your laws of physics – pivot when you are presented with road blocks.

Read about it here.

Follow us on twitter.

My weapon of choice is an assumption. It’s so much more efficient for me to just assume I know what’s going on around me, and to move forward working with the assumptions I’ve made.

Wait…are you still with me? Obviously that couldn’t be any farther from the truth.

Unfortunately, a common weapon I see people using is an assumption – and that’s a weapon that has the tendency to backfire. It’s like playing roulette with a 6-shot that has 1 blank, and 5 live rounds.

Just the other day, my wife and I were out shopping. Normally I open the door for her, but this time there was something that made it awkward for me to open the door, so I just went around to my door.  As I unlocked the car, I noticed her make a face – and quickly I assumed she was upset about me not opening her door.  There was no reason for the false assumption.  In fact, after asking about the reaction, I found out that it was about a strange old man in a vehicle next to ours.  Someone looked like a donkey, and it wasn’t the strange old man.

Making assumptions can create turbulence, hurt feelings, and create unnecessary delays.  An unfortunate reality for us engineers is that we dive deep into our assumptions as well – which makes it even more of a problem.  Even as I’m writing this, I’m making assumptions about what the other SEP Blog Battle bloggers are going to write about.

Let me be clear, forward thinking is not a problem.  The problem is when you make an assumption and it becomes a live round in your game of roulette.  Here are 5 approaches that I use to turn those live rounds into blanks…

*do some homework and validate your assumptions before investing in those assumptions
*force yourself to believe that people generally want the best for everyone
*take a walk in their shoes, and ask yourself what you would do
*ask questions and be curious – not doing so can put someone on the defensive
*prepare for both extreme scenarios – best case, and worse case

And never forget that old assumptions adage…

Read about it here.

Follow us on twitter.

Many times, I’ve heard the cliche – perfect is the enemy of good enough.  I agree with this, for some definitions of the phrase “good enough”.  But that definition changes for me.

How do _you_ define good enough?  My guess is that it depends.  It likely depends on your current problem, project, client, or more.

While I agree that aiming for perfection isn’t ideal – it’s likely not efficient, it likely is over engineered for the current problem, and it is likely going to take more time than it needs to.  However, I don’t believe that we can define what “good enough” for the full product looks like on day 1.  The reality is, we aren’t going to build out 28 web services because we need to write 1 service to return a data set.  You can’t even plan what the perfect web services would look like.

This doesn’t mean that you can simply hack something together and effectively under-engineer a solution.  Instead, converge on what is “good enough” for your current, self-contained, problem.  While implementing your “good enough” solution, use good practices, be heedful, and use design principles.

As you build this product, you will (hopefully) iterate often.  Each time you iterate, your definition of “good enough” will change.  Your design will evolve as you iterate.

Instead of taking bets on what is “good enough”, plan on evolving your design.

As someone who was working solo for over a year, one of the biggest problems I ran into was the lack of external influence to get better.  Even with the reasons above to get better, I was comfortable with my own pace, and being comfortable means you aren’t growing.

Today, I’m fortunate to be on a great team!  Sure, sometimes being on a team is uncomfortable for me, especially when I feel like I’m light years behind.  It’s a big change from being on my own pace, to keeping up with an entire team.

I’ve learned that in order to get better, you have to get outside of your norm, and make it uncomfortable.  Pick up a new SCM tool and pound through it.  Go through some new Katas for a development environment or language that you don’t know very well.  Practice Pain-Driven-Development to reduce pain points in your daily routine.  And spend some extra time helping solve problems that the team is having.

By practicing any of these and pushing my comfort zone, I continue to get better.  I make it uncomfortable.

You can read about it over here on @_swanson’s blog.

During some discussions, the idea of adding in a weekly challenge came up as well.  So you’ll see all of us with the same title show up in a blog post, but the content will vary based on the blogger.

Blogs to follow during this competition:

• swanson
• fuller
• terry
• ball
• trimble
• moseng (??)

The biggest challenge here is to recognize when you’re being asked to be a waiter.  The second challenge is how to not be a waiter.

If you find yourself only implementing what someone tells you to implement, you might be a waiter.  There is definitely a time where this is the right thing to do.  However, if you want to be more than a waiter, just remember that you are trying to help.  Find out what the goal is that is trying to be met, and help brainstorm ideas of how to achieve that goal.  As you diverge, keep as engaged as possible, and never judge the ideas that are being brought up.  As you converge on an idea, make compromises and remember to keep an open mind as you critique ideas as a team.

What you’ll find out is, as you earn respect and trust, you’ll be given more creative privileges, and you’ll be less of a waiter and more of  a doctor.

Just for the record, Jeff Patton agrees.

http://www.slideshare.net/macterry/patterns-for-getting-your-ideas-heard

What went well in the brown bag:

The information, discussions following, and using my phone as a PowerPoint remote all went well.  I would definitely do this type of brown bag again!  I also really enjoyed being able to share something that I’m excited about.

What didn’t go so well:

I didn’t engage everyone in the beginning, and I blitzed through the presentation.  In the future, I could definitely do a better job of asking questions up front, instead of waiting until the end.  And I need to practice leaving a small gap between my transitions to allow for others to have questions.  A 30 second gap might feel like an eternity, but the 5 second gaps I was leaving weren’t conducive to discussions.

Recap of presentation:

I started off by listing 2 rules that make these patterns work – “be curious”, and something I like to sum up as “Happy Spouse = Happy House”.

Being curious means that you will  try to do the following things at all times when working with others:

• ask questions and/or restate the problem
• don’t make any assumptions without confirming them
• make sure you understand where the other person is coming from

“Happy Spouse = Happy House” basically comes from the fact that human interactions are relationships, and in relationships you get what you give.  Consider the following when working with your “spouse” (peer, manager, client, etc.):

• pick your battles – don’t stand up against every “bad” idea, make sure it’s worth fighting for in the grand scheme
• don’t become a downer that only points out flaws, you should also practice supporting good ideas as well
• practice the principle of reciprocity – you get what you give
• being a control freak isn’t automatically bad…it’s the out-of-control freaks that are bad

After talking about the rules, I talked about 6 patterns that make up a recipe for success…for me.  These are patterns that I’ve leaned from seeing others in action, read about, or just developed from my own experiences.  I like to refer to these patterns as Jedi Mind Tricks…because they are that powerful in my daily life.

It’s all about me users

• Shift the focus off of MY ideas, and onto YOU, or the USERS, or the CUSTOMERS
• By shifting the focus, arguments against the idea I’m bringing to the table have to be much stronger
• Because you are talking about an idea, and not about roles/responsibilities of implementing an idea, it is not weasel-speak to remove the first person speech

Authority

• If you are bringing ideas to the table, establish yourself as the figure of authority on that matter (even if you aren’t the “boss”)
• Be confident, you want to be perceived as an expert of this matter
• Remove the emotion – there is a fine line between having ownership and being emotionally attached
• Be honest – it’s okay to say you don’t know, but let them know when you will know and follow through

Social Validation

• It’s easy to adopt something that is already being used, or that people like
• Use open source projects to confirm architectures, or designs
• Refer to other projects (current or past) where something did or didn’t work
• Reference professional studies and/or research that are applicable (I find myself referencing Nielsen’s group a lot)

Power of Because

• The word “because” is the most powerful word in the English language, use it to your advantage
• Our brains are wired to think in terms of cause and effect
• Reduces fluff – adds concrete substance to an otherwise empty claim or opinion
• Use this to accent goals or constraints

Lead the Blind

• Ask questions you already know the answer to in order to guide them to come up with the idea themselves (and therefore makes it easier for them to buy into)
• Ask questions that allow you to dig deeper and find out the root problem, higher goal, or something else entirely…which means we ultimately solve the correct problem.

Restate the Problem

• If the other person knows that you understand their problem, then they are more likely to hear you and your ideas, instead of always trying to tell you their problem.

I wasn’t able to quickly find any documentation on the Java SimpleDateFormat strings by locale…so I did what any Passionate Programmer would do, and I wrote a method to do it for me.

Then, I needed to get this file off of my emulator. To do that, I opened the DDMS perspective, selected my emulator in the Devices tab (emulator-5554), and navigated to data\data\(applicaton name)\files\(file name).

We all live in a world of scarce and limited development resources. (If you don’t call me.) At the same time the pressure to deliver more, and faster is increasing.

We jam ideas into the pipeline looking for resources to perform and often the items all look the same. There is uncertainty. Everything gets back up. The portfolio is “bloated” and that’s exactly how it feels.

There is a lot we can do in the upfront planning and discovery phases to better use our resources.

We need something to digest smaller pieces and not have so much in the pipeline. We also like to have a little slack in the system so it’s not running at full capacity all the time.

SEP has a product envisioning practice that can help in these situations. It serves to break up and soften projects into more digestable pieces while also identifying items that shouldn’t be pursued in the first place. This creates value flow and slack.

How’s this for a marketing slogan:

SEP Envisioning – the laxative for Project Portfolios?

By default, Android apps run solely in a single thread – the UI Thread.  For most applications, this is perfectly fine.  There are, however, some good reasons that your application needs to be multithreaded.  For example -

• lots of data access – reading/writing to a database is slow
• download information from the internet – mobile networks can be spotty, or slow
• sync with other components – for example, performing Bluetooth pairing or communicating with a service

If you want your thread to be able to interact with the UI and still perform operations in the background, then you’ll need to use some Android specific classes.  The simplest form in Android is the Handler.  A Handler allows you to send/queue messages, execute Runnable objects, and even perform some fine grained scheduling.

One of the best uses for a Handler is for displaying progress.  When communicating progress via a dialog, or progress bar, or whatever, it is good to use a Handler because the user can still interact with your UI.  For example, if the user decides they don’t want to wait, they could press the back button.  Or, perhaps the operation you’re doing doesn’t require the user to wait, they can continue to use your app while information gets updated asynchronously.

Thinking of the G+, FB, or TweetDeck apps that try to backfill your stream…if those apps blocked your UI, and made you wait, you’d most likely never use those apps again.  Or worse, you might go as far as leaving negative feedback in the app store!

So, MaTT, how do we do this?

The example below uses a Handler to set the progress on the UI.  So while the Thread is doing some lengthy operation (mProgressStatus = doWork();), the Handler is able to update the UI by calling the Post method, and setting the progress.

The reason you NEED a Handler here, is because you can’t access the UI from the Thread object.  The Android UI toolkit is not threadsafe by default.  If you try to access the View to update it, there is a good chance you’ll get some amazing Null Reference exceptions.

Each Activity only needs one handler, so you can use that Handler for different tasks or for updating multiple UI components.

So, MaTT, when do we use this?

This approach is great for simple, yet long, operations.  You are still able to show progress to your user and you don’t block the UI while it happens.  Using Handlers won’t give you 5 stars in the market, but it can help keep you from getting 1 star.  Handlers are ideal for one-off situations where you need to do something, but don’t want to interrupt the user.  The other beautiful part about using a Handler is, you don’t have to worry about creating some complex messaging architecture that takes a week to develop and test.

If you find yourself putting Handlers all over the place, consider using a more robust solution like AsyncTasks which I will cover in more detail in my next post.

Android Thread Series:

1. Overview
2. Handlers
3. AsyncTasks
4. Services and Messengers
5. Conclusion

Along the way, we had a critical and (in hindsight, obvious) revelation: these apps are already out there. The applications you have in production are already available to mobile device users. Tablet web browsers are nearly on par with desktop browsers. VPN from a device is easy. 3G and WiFi coverage are excellent. You can put digital certificates on a device, so two factor authentication is no barrier. Even desktop apps can be accessed by a plethora of remote desktop technologies.

This turns the whole topic on its ear. Your app is already out there. Does it look the way you want? Is it accessible in physical locations that are security hazards? Is it frustrating users in new and terrible ways when they access it on their iPad or Galaxy Tab?

The news isn’t all bad – this is opportunity. In some cases, we may not need mobile apps at all, just some refinement of existing systems. Most importantly, we don’t have to build mobile apps to start learning what we can do with mobile. It’s time to re-evaluate your portfolio of unintentionally mobile applications!

SEP has spent the better part of 20 years getting good at software development.  Throughout those 20 years, SEP has sought to improve or methods and processes.  In 2004, we began using Agile practices.  In 2007, I introduced Kanban and eventually lean.  These practices helped us to become more predictable, more reliable, and produce higher quality software for less money.  Our customers will tell you that we are very good at what we do.  Even so, I feel there is more we can do to help our customers build great products.

All of these newly introduced practices did very little to ensure we were building the right product.  And, like the pizza delivery guy, on-time and predictable is great, but it’s what inside the box you care about.

So, over the last year and a half, SEP has spent considerable time considering this idea.  We feel that it’s imperative to not only build great software, but to help our clients ensure they are building the “right” product.

Over the next several blog posts, I am going to talk about the why, how, and what SEP is doing in this area of product design to specifically help our customers achieve greater success.

What Flare seems to do best is allow you to publish different views of the same document for various users.  For example, my current application has three user levels; basic, intermediate and admin.  I can write the help for a particular web-page and annotate it with ‘admin only’ tags to hide specific sections from the other user types.

It’s mostly simple to use.  The authoring interface is a lot like Microsoft Word.  It talks directly to Team System’s configuration management, so keeping the help up-to-date in source control is trivial, once set up.  I have used it to publish my help files to the web, to MS Word and to PDF format.

My time is valuable, I don’t want to waste it with mouse-clicks.  I don’t want to waste it by pulling on a push-door.  I don’t want to waste it by spending 10 minutes figuring out which of the 15 buttons on the stereo console in the car displays the odometer.  I think everybody is becoming more impatient with poorly thought-out designs.  This – I find thrilling.

Looking forward to a usable 2011.

The people deciding what should do into a product development process are assisting in planning it is releases to the user base. The batch sizes are smaller and only what we know we need at that time. We work in input from the users and increment with a next version.

Incremental product development at a higher level.

The first fork in the road… how many engineers does it take to stay on the right path?

While we didn’t see any turkeys, we did meet a large-ish (to me) rat snake.  He was probably 3 or 4 feet long.

I had runkeeper running while we were out there to track our hike (would we be a real group of nerds in the woods without at least one person tracking ourselves via GPS?)… here’s the results:
http://runkeeper.com/user/jonfuller/activity/16692844

Recently this question arose so many times in the projects that I have been working on that I decided to investigate the options more closely.  I found that some subtleties of the approaches have not been explained anywhere, so decided to summarize the available options here.  There appear to be four different ways to specify library settings, each with its own benefits and failings.

1. The settings can be created in the class library by adding them to the ‘appSettings’ element of the app.config added to the library project (see figure).

This is a very simple way of specifying settings, and can be accessed in the library code as shown below:

The drawback of this method is that every calling assembly has to duplicate this setting in its own app.config (compiled into a .exe.config or .dll.config), since that is the only place searched by the code above.  The situation becomes cumbersome when the number of settings required by the library increases.

2. The settings can be created in the class library as custom settings, by adding a settings file to the project (http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx), and specifying the settings to be used in the Settings designer of Visual Studio (see below),

or by manually entering them in the custom section of app.config as shown below:

Visual Studio conveniently generates a class to access the settings (see below):

The settings can be accessed in the library code as follows:

Once again, if the setting is to be provided by the calling assembly, it has to be included as a custom setting in the exact same format in the calling assembly’s .exe.config.  This is fairly cumbersome as the number of settings increases.  However, an advantage (or disadvantage) of this method is that the default value of the setting is compiled into the library code via the ‘DefaultSettingValueAttribute’ in the Visual Studio generated code (see above).  Hence, if the calling assembly does not provide the setting, the default value is used.  This appears desirable only in a test context, as in production code, the user has no way of knowing the default setting that was applied in the library unless explicitly specified in a document or config file supplied with the library files.

3. A third way to provide the configuration settings for a library, is again via the ‘appSettings’ section of app.config, compiled into the library .dll.config.  The difference here is that the library code used to retrieve the settings is as follows:

This code looks for the settings in the library .dll.config placed in the same folder as the library .dll.  The advantage of this method is that the configuration settings need not be copied into the calling assembly’s app.config.  It is sufficient to place the library’s .dll.config file provided with the library, in the same location as the library .dll file.  The disadvantage is that the library files cannot be placed in a central location (if different settings are to be applied) or in the global assembly cache (GAC) to be used by several calling assemblies.

4. A fourth way to provide the settings is to define them in a custom configuration file of any name, and retrieve them using the code shown below:

This code looks for the settings in the ‘appSettings’ element of the file called ‘custom.config’ in the calling assembly’s executable folder.  The advantage here is that the library .dll can be placed in a central location or the GAC, and still use different settings based on the values specified in ‘custom.config’ placed in each calling assembly’s executable folder.  Further, the settings do not need to be duplicated in the calling assembly’s own .exe.config or .dll.config.

I’ve been on this quest before, to simplify this a bit, but it was still a little hackety, and limiting.

This time, I set out to do it right.

I’ll spare you most of the technical details, but it’s backed by Castle’s DynamicProxy project, and there’s some integration with StructureMap to make it super easy, though you don’t really have to use StructureMap if you don’t want to.  [note:  I’ll probably add more container support as I find time.  If you have a specific need, let me know, or submit a patch.]

Here are the codez to show it in action:

Basics

Using it for a class with an interface

Using it for a class

The previous example shows how to get the event to fire only when the value is different also.  It defaults to always firing, whether the value changes or not.  It’s also important to note that your properties need to be virtual so the calls to the setter can be intercepted.

Dependent Properties

Sometimes (usually) you’ve got calculated properties that need to fire the notified event too, these usually turn into WET mess as well.  We’ve got the problem solved, and you’ve got a few different options, hopefully one of them suits you.

Dependency Map – DependsOn

You specify the type that defines the DependencyMap on the attribute, and then set up your dependencies in that type’s constructor.  This style is somewhat influenced by the FluentNHibernate API.

Dependency Map – Updates

If you’d rather express your dependency the other way around, that’s fine too.  The two are equivalent.

Dependency Map – UpdatesWith

If you want to stick with an auto-property, and leave the calculated property logic somewhere else, you can hook it in via your dependency map too.  This example, again, is equivalent to the previous two.

DependsOn Attribute

If you don’t like any of those options and are looking for something a little more simple, maybe you’ll like this one.  Just specify which things your property depends on in an attribute.  You lose your 100% static typing help, but it’s more concise.

Containers and otherwise

Hooking it into StructureMap

There are a couple conventions you can use to hook into StructureMap.  There is the attribute convention (which is what you’re seeing above), and there is a generic predicate convention that you can use any predicate logic.  Below you can see the attribute one getting hooked in.

Using it without StructureMap

If you’re using another container, or no container at all, but want to use some other factory or something, you can do that too.  This example is for something with an interface.  It’s very similar to do the same for a concrete class… you just don’t instantiate the object first.  You also have an opportunity to hook into the dependent property structure here as well with the DependencyMap parameter.

Whew, done

So… that’s a lot of ‘how to’, but hopefully it’ll be somewhat complete introduction to get you working with it.  I really don’t see much of any reason to ever implement INotifyPropertyChanged ever again (unless you are in an environment where you can’t use DynamicProxy).  It can automatically be done for you from now on.

The code is up on github, and there is a gem up on rubygems if you’re using nu or noodle+bundler.  Fork it, send me a patch, use it, send feedback, etc.  I hope you love it!

EVERY time I do a technical presentation I need this.  Usually I resort to taking a screenshot, or finding an “export to html” type plugin for the editor I’m using at the time (Visual Studio, Vim, IntelliJ IDEA, etc.) and then try to get that somehow into my slides.

The problem I usually run into, is that while I like coding on a dark background with a 14pt font, that’s not usually that great for presentations.  So I switch to my “presentation settings” that has a light background and bigger font size, and then switch back once I’m done taking screenshots or outputting to html. [ugh, what a pain… terribly manual].

Then what happens when I spot a bug in code that’s in PowerPoint, or I want to add a comment, or I need to change the syntax highlighting theme of the entire presentation because it doesn’t go well with the lighting in the room.  UGH!  What a disaster.

Basically, it’s always an uphill struggle, and it really bothered me… so I decided to fix it once and for all.

Solution

I’m going to solely discuss PowerPoint (for Windows or Mac) here.  I don’t have a copy of iWork, and I’m too cheap to buy one.  The reason I have Office for the Mac, is because I got it for free… KeyNote/Mac zealots: feel free to be zealous, but don’t hate on me because I’m frugal… unless you want to buy me a copy of iWork.

First, download: http://www.andre-simon.de/doku/highlight/en/highlight.html

Windows Solution

The highlight tool can output many formats, but the important one for Windows is RTF.

So something like:

highlight < infile > outfile –-rtf –syntax=rb  –style=vim –font=”Lucida Console” –font-size=18

This will  take the source code file ‘infile’ and syntax color it as Ruby to an RTF file and output it to ‘outfile’.  The text will be 18pt Lucida Console and syntax highlighted with the “vim” color scheme.

There are lots of themes included, you can ask highlight for help (highlight –help), and it’ll tell you all the options available, as well as all the options available for output, and for languages that it supports.

Next, in PowerPoint, do “Insert Object” on your target slide, and choose “Create from file”.  Make sure you check the “Link” checkbox before pressing OK.

Now, whenever your source changes, re-run your command line, then you can choose “Update Link” on your embedded object in PowerPoint, or if you close and then re-open PowerPoint, it’ll give you the option to update all your links.

Mac Solution

My version of PowerPoint for Mac doesn’t like being able to link to RTF files, but it does allow linking to images.

Highlight can output to SVG, but my PowerPoint doesn’t like that either.

Now download inkscape, if you haven’t already.  It will allow you to rasterize the SVG into a PNG, which PowerPoint does like.  You can export your PNG from inkscape from the command line like this:

<path to inkscape> –export-png=<png file> <svg file>

The path to my inkscape command line runner is at:

/Applications/Inkscape.app/Contents/Resources/bin/inkscape

It turns out that inkscape doesn’t like external CSS files, which is what highlight gives you with your SVG, so you can merge your CSS file into your SVG file with a little script.  The other cool bit about SVG, is you can tweak it, if you want, since it’s just XML.

Now, in PowerPoint, choose “Insert Picture” and browse to your newly generated PNG.  Make sure the “Link to File” checkbox is checked.

I wrote a script to do this for the latest presentation I did on dependency injection.  You can take a look at the script here [source.rb].   It’s Ruby, and you can see where I merge the CSS and SVG files together, and where I mess with the line spacing as well (I wasn’t happy with the default line spacing, so I tweaked it to my preference).  All the source/images/PowerPoint for that presentation are available here [dependencies presentation] if you want to check them out to see how the whole process works.

Now, when I need to change the font and syntax theme throughout my entire presentation because it doesn’t match the lighting in the room, it’s super-simple: I change the configuration, re-run my script, update PowerPoint, and chill.

What’s the point? Learn how to do usability testing yourself to gain most of the benefits of hiring someone to do it, and losing most of the negatives (e.g. Big Honkin’ Report, $$$).  The book’s other motive is to make sure you start doing some kind of usability testing.  ALL of our sites/applications have usability problems.  We could eliminate the big ones just by spending a little time on it.

How was it? A pretty quick read.  I’m a slow reader, and I made it through it in a couple hours a night for 3 nights.  This thing is a prescriptive manual for conducting usability tests on a product you have (or on your competitors products, if you’d like to do that).  It covers recruiting participants all the way to fixing the problems they discover.  Usability testing doesn’t need to be a big production, hard to do, or scary.  He lays it out step by step and give you (as the guy running the tests) guidance each step along the way, complete with checklists and scripts (I know, that sounds hokey, but I think it’ll actually work).

Who should read it? If you’re reading this, you probably ought to read the book.  Realistically, anyone remotely interested in having a usable application and is actually partly responsible for said application (PM, Tech Lead, Dev, Designer, Marketing, Tech Writing, Tester, etc.).  Even if you aren’t going to be the one running/moderating the tests, it’s good to know what the participant’s are going through, what the moderator is doing behind the scenes, and what your role is as an observer.

How was it? Originally I was hoping to find parallels that could be used during our software processes. The concepts presented in the book made sense for software at a nebulous level but the actual implementation proved to be very elusive. The book is a nice side note to be taken as a historical fact alongside software Lean processes but should not be used as a comparative basis in my opinion.

Who should read it? People who want an idea where Lean came from and see how it can be applied to other industries.

How was it? I thoroughly enjoyed the book. I thought that the insights presented and the strategies detailed in the book could be easily applied to my current position. The book provided several good ideas on how to approach the same problem, tailored to the individual.

Who should read it? People who manage others, from LSE to EMs.

How was it? I thought that the first quarter of the book was recap of things that I have picked up or used over the years but it would be a useful basis for someone unfamiliar with user stories and how to use them. What I found very useful was the explanation of how to use the user stories in iteration planning. I found that the book read faster and faster as I approached the three quarters mark and I read on until the conclusion.

Who should read it? Anyone that would be writing user stories should read the first half. Anyone planning iterations and releases should read the entire thing.

The Problem

In this example, we’ll be pulling a command out of the container.  The important part is the optional constructor parameter (level), and it’s default value (Level.Info).

Here is your basic usage, but doesn’t work since StructureMap doesn’t know how to take advantage of the optional parameters with default values.

The last line results in an exception because StructureMap doesn’t know how to fill in the level parameter.

The Solution

We can solve this by adding a new convention.  One that adds information about default constructor arguments.  Here is the implementation of the convention:

Note: GetGreediestCtor, HasOptionalParameters, and GetOptionalParameters are extension methods.  We’ll see their implementation shortly.

The convention inherits from the IRegistrationConvention, which is how you implement new conventions in StructureMap.  It has only one method: Process.  We filter out types that are abstract, are enums, or have constructors that don’t have optional parameters.  Once we realize we have a constructor we want to deal with, we use the Child method, that sets either a property or a constructor argument (for our case, it’ll always be a constructor argument), and then we set it’s value to the parameter’s default value, as provided by the ParameterInfo object, for each optional parameter.

Minor Details

Curious about the implementation of GetGreediestCtor or the *OptionalParameters methods?  If not, skip this section.

The Usage

Here’s how to use your new convention.

Now, when we pull the LogCommand out of the container, the level parameter gets defaulted to Level.Info, just like we specified in the constructor.  Sweet!

Conclusion

This implementation is somewhat limiting, but the version I have in my github repo is a little more open and configurable.  It allows you to customize the instance key/name you use when registering your type, and also allows you to do additional, non-standard registrations if you need to.

Also, this doesn’t work if you’ve selected a constructor using the SelectConstructor config API from StructureMap, I’m not sure how to tap into that facility to look for that constructor rather than the greediest.

Am I missing something?  Did something not make sense?  Leave me a note!

A couple years ago I brought up the idea of doing a book club here at SEP because I had participated in a couple before coming to SEP, but we called them SEDG (coined by Steve McConnell in Professional Software Development).  I don’t really like that term, so we called it book club instead.

We start up a new round a couple times a year, and small groups (3-8) break off and read different books (normally technical) that are interesting to them.  We normally get together for an hour once a week to discuss/debate the chapter(s) we read for that week.  I’ve participated in several including DDD (Evans), Code Complete 2 (McConnell), Programming Clojure (Halloway), and now Pro Git (Chacon).  It’s a lot of fun, and I always learn a lot about the content of the book, and about the people I participate with.

I’d highly recommend starting one at your company, or in your community, it’s a great way to connect with people and learn new things at the same time.

The Book

First off, the book is available for free, online at progit.org.  It’s also hosted in a repository on github, and there is an easy script to get it onto your kindle (with a little hacking of the script), so that was a win for me: free AND kindle-ized.

I participated with Matt (@spraints) and Todd (@snibble) (both of which know more about git than I do… Matt wrote git-tfs, and Todd is working with git on a REAL project).

I’ll follow Raman’s Recipe to keep this short and simple.  I’ll also mix-in the book club aspect to each section.

What’s the point?  Become a git ninja (or at least be able to play one on TV at work).  Learn how to use git effectively, and give you the tools (ideas, knowledge, know-how) to give you a framework on how to effectively use it in your context.  The cool thing about git, is that it gets out of your way and lets you work the way you and your team want to… not the other way around like SVN, TFS, P4, etc.  It was also a great way to leech off of Matt and Todd’s knowledge.

How was it?  Great.  Scott (author) certainly knows how to git down (I’ll be here all week ).  I feel comfortable participating on a project that uses git (hey look, I am already!), and also feel comfortable making recommendations about using git (e.g. “You should use git!”), though, I do still get lost in hairy situations every once in awhile (thanks Matt for always saving me!).  We had some good discussions on how it relates to us as company, and how we might use it.  We also had some good discussions on schoolin’ me, so that was always good.  The book contains lots of examples, with corresponding diagrams to help n00bs like myself understand what’s going on.

Who should read it?  Any developer planning on staying a developer for the next few years.  DVCS seems to be on an up-tick, and I don’t really see it going away anytime soon (but hey, what do I know?).  I don’t think you’ll be able to get by effectively in a DVCS world unless you’ve done at least some reading on the subject.

I was privileged enough to be a speaker alongside some other ridiculously awesome regional speakers (and even had a few of them IN my presentation!)… star struck having @dburton, @timwingfield, @skimedic, and other community leaders like @myotherpants and @maggielongshore in the audience.  I am truly humbled.  Thanks to the organizers for allowing me to practice my teaching, and thanks to those that sat through my talk for supporting me (and also, thanks for the positive feedback from those I talked to afterwards!).  [Side note: If you want to see my slides:  http://github.com/jonfuller/presentations/tree/master/mongo/]

The best part, however, had nothing do with any presentation at the event.  It had to do with the amazing conversations we had in the Open Spaces area hosted by @alanstevens.  I hung out there ALL day (except for when I was presenting), and got more out of any one open space topic than I have at entire conferences before.

We talked about Ruby on Rails, IronRuby, Public Speaking, Technical Speaking, Running a User Group, Linchpins, Alt.Net, Software Craftsmanship, DVCS (hg and git specifically)…

I’ll pause and let that list of topics sink in.  For me, that list is like a holy grail of a developer conference.

Most of this was deep discussion about the topic at hand by some great minds/leaders in the area.  All of the aforementioned folks plus @jayharris, @alanbarber, @jademason, @garrinmf,@arktronic, @browniepoints were together having these conversations, and it was really exciting (at least for me) hanging out with these guys and learning so much from them.

For me, this year, IndyTechFest was about the people and the interactions I had with them.  What was it for you?

I can’t wait for next year.

One of the replacement systems is “one-on-ones”, a peer feedback mechanism. Periodically, everyone in the company is expected to reach out to a peer who has good visibility to their work and (hopefully) more experience to get some candid feedback. No form, no manager (unless that’s who you ask), no reporting other than the fact that it happened.

We published some good topics for one-on-one discussion on our internal HR sharepoint site, but they are largely focused on the softer stuff, not much on actual engineering. Then we ran across this Programmer Competency Matrix. If you’re a software engineer, take a look … it’s a fantastic resource for self-evaluation and guidance. We haven’t formally incorporated it into our systems, but we’re exploring it.

The power of communities was strongly evident in the feel of two conferences I attended within a three-week period. The first was the Lean Software and Systems Conference and the other BIO Chicago.

LSSC is a newer conference formed in the middle of this community trend. I told David Anderson the conference chair that LSSC is a response to an existing community almost like people said, “Hey, let’s get together.” It’s a big open forum to some extent. Many of the attendees already knew each others’ work from blogs, articles and presentations. LSSC even has its rock stars. You put people together and they talk content. It’s organic.

I’m hoping LSSC can continue this way. As it grows it seems like growing the conference through the community and strongly encouraging attendees to participate will help keep the feel.

BIO is older and there really isn’t anything wrong with it. It’s like most conferences, trying to quickly catch up with this “social media trend”. They provide tools and forums to attendees encouraging people to connect. The conference feel was much more scripted. People were there to “do business”, not exchange ideas.

These conferences, very clearly represent the Old and New Ways. In social media it is not ok to Push. It’s instead about supporting the community and helping it advance – a many to many relationship. When people come to LSSC pushing their products and services too much it’s like having bad breath. The old way was all about pushing – one to many, and has little room for community.

Like businesses, professional and trade groups are struggling to change. The truth is though it’s difficult to build communities intentionally and when you want to. They defy control. To some extent they just develop around common cause and interest. Communities are living organisms that grow organically. All we can do is connect and encourage.

SEP has been all about “building a place” since we started in 1988. We use the word Culture a lot and our vision uses Environment. Lately, it feels like we should replace all these words with Community. That feels like a much better word.