The Dip

Seth Godin has written a best selling little book called The Dip. In this book he strongly encourages his readers to quit stuff that doesn't get them closer to their goal, and to not quit stuff that has long term benefits even when it is difficult in the short run.

Gerry Weinberg wrote about a similar idea quite a while ago, and I often reference this idea in speaking with clients about embracing change and agile development in particular.

The basic idea of the dip is to understand where you are on a project, and make decisions based on your location. If the project interests you, and you feel like you can continue to grow with it, then press through the tough spots. But if you are on a dead-end project that is shriveling your brain and career, it is time to quit - even if it hurts.

This applies to trying a new software development process like agile. There will be times when it is tough to learn something new, but the advantages of pressing through the tough times are tremendous. Agile has been around long enough now, and many people have shared their experiences to the degree that the cost of learning has become significantly cheaper than it was a few years ago.

So, if you are struggling with your software development process, maybe it is time to quit what isn't working for you and try something new. After working through a couple of dips you will have a process that works.

Open-Source and Apple

Now that I use a Mac as my primary development machine, it is becoming apparent the degree to which Apple uses open-source software. For example, the iCal program was one of the first desktop calendar systems that adopted the iCalendar standard. Another well known example is Mac OS X itself, which is based on FreeBSD 5.0 and the Mach 3.0 microkernel.

The adoption of so much open-source enables Apple to focus on developing software and hardware products, rather than support an infrastructure. This, of course, is great for developers as we have a solid, non-proprietary environment in which to work, plus we get all the benefits of the Apple software. I use Eclipse, MySQL, Apache, and Tomcat for Java web-app development, and Eclipse and the MPowerPlayer emulator for J2ME development. These tools are mostly the same tools I used in my XP development.

Check out the OS X Technology Overview for more information.

Human Tetris

Watch the movie, it speaks for itself ...

Hee Ah Lee's Story

I am constantly in awe of folks who overcome significant disabilities and are able to do what seems to be impossible. Hee Ah Lee is no exception.

Design, Design, or Both

The iPhone is now available, and though it has been called "the most hyped gadget in history", it is looks pretty cool, and some of the apps Steve Jobs demonstrated earlier this week have a lot of people talking.

I have to wonder though, why is it that Apple continues to produce products that create such a huge following? I think it is because they "design" the products in both sense of the word.

When I speak with graphic artists about design, they refer to aesthetics - how or what an image communicates, the feelings of the artist, the impact on the viewer, etc. The engineer in me wonders about structural integrity, efficiency, and usability. What is the purpose of this "design"?

However, the software engineers I work with on a day-to-day basis are so focused on the functional design of a product, that they forget that real people have to use what they build. Though their products run with few bugs, the products they build are ugly, and are often difficult to use.

So, it seems that what Apple has managed to do is come up with a process that encourages their product designers to do both - make the product run extremely well, and look good too.

Tools for Peace of Mind

In her book, Embracing Uncertainty, Susan Jeffers provides a list of tools that can promote peace of mind. A few of these "tools" follow:

1. “Un-set" your heart - Let go of trying to control things over which you have no control. In doing so you have no more reason to worry: The things you can control, control - don't worry about them; things you can't control, let go - don't worry about them.

2. Choose the path of trust. When you realize you have little control over the external world, you can choose to see yourself as victim or as a response-able person - able to choose your response. I'm reminded of Victor Fankel, in his book Man's Search for Meaning he speaks of coming to understand that even in a Nazi concentration camp he can choose his response to various situations in life.

3. Focus on learning. I like this one in particular from an agile perspective. All situations in life are opportunities to learn. Jeffers illustrates:

• War............a way of learning
• Peace..........a way of learning
• Poverty........a way of learning
• Wealth.........a way of learning
• Depression.....a way of learning
• Joy............a way of learning

4. Get involved. Positive action has an amazing effect on our psyche. If you don't take action to improve the things in life you can control, it is much easier to get down and worry.

Jeffers covers other tools as well, but by focusing on these few we can take great steps toward developing peace of mind.

Skip the Honeymoon - Go Agile

I recently met a couple that had been married for over 40 years. As we talked, I asked them where they went on their honeymoon. They said that they didn't have any money when they got married, so didn't take one. Yet, they had a wonderful life together in spite of not taking a honeymoon. According to this couple, a long-lasting relationship is built on working through small conflicts as the come up rather than waiting until one person gets angry enough to deal with the issue. This got me thinking about other long-term relationships, including those of an agile team with project managment.

Typical project management follows a three step cycle: the honeymoon stage, major conflict, product release.

Honeymoon
In typical project management, the developers are assigned tasks according to some arbitrary schedule that they have little input on. Often the delivery date of a system is fixed, and the project manager feels like she is coercing the uncooperative developers into doing their jobs, regardless of how unreasonable the goal may be. However, at a weekly status meetings the project manager gets a feeling of tasks being somewhat completed each week. She may see the schedule begin to slip, but deceives herself into thinking that they will make up the difference later in the project.

Major Conflict
As the project continues, it becomes more and more apparent that the developers are not going to meet their date. The project manager finally decides sit down with the developers and find out how things are really going and what they can do to call the project a success.

Release
After a few delays pairing down the scope of the release, the product finally goes out. The PM is left feeling like she was deceived from the beginning and makes a few mental notes for future translation:

• When a developer says something is "done" it probably means it is 50% complete.
• When a developer says something is a problem, it probably means that the whole project is doomed.
• When a developer says he is working on something, it probably means he is surfing the web 4 hours a day.

So, along comes our open, conciliatory, and collaborative agile team. At the first iteration plan we set expectations for the first week's iteration, and at the end of the week we communicate that all of the stories planned for that iteration are complete except for one that we'd like to move to the next iteration. What does this project manager hear? She hears that we have half of all the tasks completed, and one task slipped already.

In the mind of the PM, by having one task slip, we have skipped the Honeymoon stage of the project and gone straight to the Major Conflict stage. She isn't ready for this, of course, and may tend to overreact. The unintended message that is communicated: The project is tanking quickly; find a new job right now!

This is to be expected. She doesn't trust the developers at all.

As an agile development team, we have access to useful data beginning with the first week of the project. We know what stories were completed during an iteration, and, very early in a project, we can communicate the impact of unfinished work on a project schedule. Over time the PM will come to appreciate these great qualities of an agile approach, and she will begin to trust the team.

In the mean time, we need to communicate problems as soon as they are discovered so they can be dealt with as soon as possible. We also need to communicate genuine successes on the project to provide an accurate view of the state of affairs. Give your PM time to become accustomed to having this high-fidelity information. It is information she has always wanted, never had, and doesn't realize what she has at the beginning of the project.

So, I guess the point of all this rambling is that when developers communicate with PMs, we have to remember that they inherently don't trust us. We need to try our best to ensure that the PM is understanding us. True communication may take many discussions and some education. We have to have the courage and persistence to push through the misunderstanding and hope that in the end everyone has a better view of the state of a project and benefits from the open communication and collaboration.

Skipping the honeymoon may be better for everyone.

Tricks of the Trade

While speaking with a client today about various approaches to interaction design, a short list of tips came to mind. Here is the list I came up with earlier, plus a couple I added for this post:

• Make all interaction decisions within the context of one or more specific personas who fulfill a specific role, act out a scenario, or perform some task.


• Clearly represent what the user is trying to accomplish. This can be done through a story board, user story, workflow description, etc.


• Keep the user goals in mind as the interaction is being designed. People often don't know why they perform certain tasks. By keeping the goal in mind, you may find places to eliminate waste.


• Be sure to design the primary tasks well. Developers often focus on the edge cases of a project because that is where all the interesting problems lie. However, by ensuring that 75% of a user's interaction with your system is designed well, you have designed a system that is easier to use than a large number of the systems the user interacts with.


• Use wireframes to spell out an overall direction for a UI before you start writing code. Test the layout with some user, anyone is better than no one.


• Use color judiciously. A small color palette can work well for accents. Too much color can quickly turn your UI into a kindergartner's finger painting.

Make a Difference

An unusually personal post follows:

About a year ago, I was working with a client that we had done a lot of work for in '03 and '04. We had built two major products for them, and they were both a big success from a software quality perspective (2 bugs per 1000 LOC) and a market perspective (over 500,000 users). I had a passing conversation with the product manager in which she mentioned that the products were going to be discontinued in May of '07 (right now) and unsupported in May of '09.

This news coming only 18 months after I had poured my life into these products sent me into a time of real soul searching. I've had some pretty cool experiences working with robots, big name brands (Major League Baseball, FedEx, etc.), startup companies, and fortune 100 companies. But what is the real benefit of all this software that I write? Helping the economy churn away?

So, I took last summer off from writing/speaking and decided to figure out what I really want to do when I grow up. I discovered that Wright State University was awarded an NSF grant to fund PhD students who focus on Assistive Technologies - technologies to support the disabled. In November I applied for the program; then in March, I was accepted into the program, and awarded an IGERT grant which will offset some of the costs of pursuing a PhD. This fall I'll begin to work with the Assistive Technologies Research Center at Wright State and pursue a PhD full time, and continue to work with SDS part time.

While this will be a lot of work, I hope to begin to write software that lasts longer than a couple years, and even if it doesn't, hopefully it will make a greater difference while it is in use.

Refactor the Fence

We had a privacy fence installed yesterday. It is a simple fence - just on one side of the yard to keep the big ugly dog from barking at the kids. The fellow who installed the fence didn't install it to code - the good side was facing in, and is supposed to face out. So, about 20 minutes after he left, the city inspector showed up and told us we needed to have it turned around.

It turns out the neighbors with the big ugly dog called the inspector and reported that our fence broke the law. (Two side thoughts on this: 1. I can't wait until I'm old and retired and have nothing better to do than report fences that break the law. 2. I've never called the cops on the big ugly dog barking loudly at 11:30 at night, and I still won't, but don't know why.)

So, anyway, this morning a couple friends and I took the fence down and turned it around so that it is now up to code. The problem with turning it around was that the guy who installed the fence is not a craftsman. So, the vertical support poles were not evenly spaced. When we attempted to turn it around we had to rehang each individual panel on the same two vertical supports as it was originally hung. This created some gaps at the joints and caused me significantly more work.

I share this story only to point out that part of easily refactoring something is building the original with craftsmanship. Craftsmanship facilitates simpler refactoring. So, if this fellow had evenly spaced the vertical supports, moving the panels from one side to the other would have been no big deal. Since he didn't, I had two choices: dig up the poles that were in the ground with concrete, or cut smaller fence boards to fill in the gaps. I chose the second option, even though it is uglier, it is way less work.

I guess ultimately I didn't choose the road of craftsmanship either, as I probably 'should' have dug up the poles and replaced them so that everything looked the best. Isn't it interesting that one person's poor craftsmanship, led to refactoring, and others to have poor craftsmanship also.

As software developers let's try to pay attention to those coming behind us who are going to fix our stuff, and ensure they have the easiest time possible.