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.