Pomiet

The Dip

2007-06-27T17:18:00.000-04:00

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

2007-06-24T14:21:00.000-04:00

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.

Design, Design, or Both

2007-06-15T08:02:00.000-04:00

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

2007-06-11T05:44:00.000-04:00

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

2007-06-08T08:57:00.000-04:00

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

2007-06-05T17:19:00.000-04:00

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

2007-05-31T22:20:00.001-04:00

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 Fellowship 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

2007-05-25T23:09:00.000-04:00

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.

Think More Often

2007-05-20T19:08:00.000-04:00

George Bernard Shaw once said, "People hate thinking. They will do almost anything to avoid it. I have made an international reputation for myself by doing it once or twice a week."

It seems that in a world of sound-bites, deep thinking is a lost art. People's attention span are short (7 minutes, so I'll keep this short). We, as a society, like rules and laws rather than looking at a context and trusting that we will have good judgment.

This is why software development shops often like high methodology, process, and lots of documents. They hope there is safety in the documentation - management is hoping to find someone to blame when the software sucks.

An agile approach causes people to begin to think. You have to think to respond to change; you have to think to prioritize on a weekly/monthly basis; you have to think to be able to contribute daily and have something to report in a stand-up meeting. I'm sure one reason people don't like agile processes is that they make you think more often.

Universal Design is Better Design

2007-05-15T22:16:00.000-04:00

Universal design is the idea that everyone, even those with disabilities, should have access to the use of a facility, a web site, etc. When something is designed with universal access in mind, the designer is operating under a great number of constraints that are otherwise not required. It seems that these maximum amount of constraints requires a maximum amount of creativity, and therefore leads to a better design.

Take for example the entry lever. The entry lever was originally designed to enable a person to open a door without the use of a hand. The lever has now become more widely used because even people with the use of their hands think it is easier to use. The lever has more aesthetic value also, and so has been employed in decorative situations as well.

Another example is a wheelchair accessible shower. Most people these days like to shower rather than take a bath. However, typical showers installed for home use have tight quarters and are not as enjoyable to use as a traditional bath tub due to the claustrophobic experience. A wheelchair accessible shower, however, provides a nicer experience for the non-wheelchair bound person, and provides a huge benefit to the wheelchair bound person as he/she would not have to get out of the chair and into a bathtub to bathe.

So, while designers and engineers may not like the extra constraints that are placed on them when universal design in a requirement, I wonder if universal design is better design.

iMac Now

2007-05-07T16:07:00.000-04:00

Last fall I was entrenched in a .NET project, struggling through things that I don't have to struggle through on a Java project. At that time I swore more than once that I was going to buy a Mac and just become a Java programmer.

Well, the mother board on my Sony VAIO died recently, so I bought a MacBook Pro to replace it. Of course, the very next opportunity that came along was a .NET project. Since I do like to eat, I took the gig, and bought Parallels to run Vista in a virtual machine on my Mac. So far, it's working out great. Below is a photo of Studio running on Vista running in Parallels running on my Mac.

Early Mistakes

2007-05-04T15:25:00.000-04:00

A friend of mine sent me this beauty today. It turns out that the company he is working for has hired a two junior level people to fill some slots they have in their staff. While everyone needs to learn the ropes, and everyone makes mistakes, I often wonder: How early in ones career can you tell if a person should choose a different career path?

This is an actual code snippet from one of these folks:

public static boolean isNumber(long qty)
{
  String qty_str = String.valueOf(qty);
  char[] strArr = qty_str.toCharArray();
  for(int i=0;i < strArr.length ;i++)
  {
    if(strArr[i] <> 57 )
    return false;
  }
  return true;
}

Testing Tips

2007-04-30T16:04:00.000-04:00

I was think a bit today about unit testing. Though there has been many articles written on unit testing, I continue to find people need guidance in writing good unit tests. So, here are a few tips that may help you find unit testing nirvana:

Every program statement must be executed at least once.

Relational operations must be tested for pass and fail conditions.

Boundary conditions must be tested for pass and fail.

State changes should be predicted and verified.

Implement the test code as you write the function. (It's frustrating to even write this one, but I still find many people writing unit tests after the code is written.)

Place the test code in the same package/namespace as the target code.

Healthy Dissent

2007-04-26T22:16:00.000-04:00

Agnostics are people who believe that God exists, and that He is not involved in our day-to-day lives. People who know me at all know that I am A-political - meaning, I know that there are politics at every level of society, but I try to ignore them as much as possible.

However, Cass Sunstein has a very interesting book out entitled Why Societies Need Dissent. His basic premise is simple: “Organizations and nations are more likely to prosper if they welcome dissent and promote openness.” For an Agile team, this implies that when team members reveal what they know – or don’t know – to the rest of the team, the team becomes healthier and more productive.

This takes a lot of courage. Yet when you get a group of great programmers together, you are going to have dissent. I like dissenting opinions presented in humility. I learn the most, and become more confident in what I know, when I have healthy discussions with coworkers about the project at hand. Without these discussions, I don't grow.

However, when an arrogant, insecure person is on the team, he tends to talk down to team members and the healthy banter goes away. The best thing a team lead can do is identify this person as early as possible and get them off the team. If you are not in a leadership position, and realize that you don't have healthy dissent, perhaps it’s time to look for a new team.

Mind over Machine

2007-04-23T10:13:00.000-04:00

In Mind over Machine the Dreyfus brothers describe five steps that a person or machine must follow from novice to expert. These steps remind me of my own stages of growth that a programmer must follow.

Novice. Operates by learned context-free rules. Lacks any sense of the overall task.

Advanced beginner. Uses more sophisticated rules, which refer to situational elements as well as context-free ones. These situational elements are features such as the pattern of behavior which distinguishes a person walking vs a person running.

Competent. Can now recognize many context-free and situational elements. Still lacks any sense of their overall importance to the task, and becomes easily overwhelmed. Tries to overcome this by hierarchical decomposition of the task.

Proficient. Performs task intuitively, approaching a state of flow. When new problems with the task become apparent, hierarchical analysis begins again.

Expert. Performs his task intuitively, in a state of flow. When a new problem presents itself, the analysis is on the intuition, rather than on the hierarchy.

This demonstrates a progression from rule-based problem-solving to an experience based approach. Classic AI systems are extremely rule-based, and assume the mind also divides problems up into small manageable pieces. It is in these small details that an experienced based system becomes overwhelmed. An experienced based system needs to derive contextual rules based on the details, regardless of the details themselves - more of a holistic pattern matching.

It seems that these same observations apply to human behavior as well. An 'expert' is someone who has screwed up enough to formulate a set of rules that apply to a large set of problems. These experienced based 'rules' enable a person to intuitively solve problems. When applied to programming specifically, they help a person engage mind over machine.

Just Say No

2007-04-20T10:51:00.000-04:00

Yesterday at a talk I gave on Agile Software Development, a man said that his management didn’t want them doing agile development, and asked what he should do. I told him about a team at another client who followed some of the agile practices, but didn’t tell anyone. When it came time to estimate portions of the project, they budgeted time to make sure they could do what they knew worked, and still meet the expectations that the project manager had. This of course takes courage.

Every time this question comes up at a talk, I'm reminded of a passage out of the Decline and Fall of the American Programmer by Ed Yourdon: (page 212)

If they ask you to “speed up testing”, just say “no!”

If they say, “don’t worry about a few bugs…,” just say “no!”

If they say, “don’t worry, this is just a beta test, it can have a few bugs in it,” just say “no!”

If they say, “I don’t care if there are bugs in it, we gotta get this out by Jan 1”, just say “no!”

None of this will make you popular. Indeed, you need to be prepared to vote with your feet. But wouldn’t it be more fun to work for a company that cares about quality as much as you do?

So, maybe I'll add a slide to my agile talk that says, "Just say no!"

Step Back to Chase

2007-04-18T13:53:00.000-04:00

I hate chasing problems. I spent quite a bit of time yesterday and today working out how to get a database connection to be established in using an Oracle native connection while unit testing through Eclipse. It turns out that the native connection is not serializable, and therefore won't work in Eclipse. If I'd taken a step back earlier, I may have discovered this sooner.

A great programmer generally has a high self-esteem, a handy state-of-mind when tough problems arise. A person with little self-confidence will give up easily, where another will persist until a solution is discovered. Unfortunately, self-esteem often inhibits a person's ability to recognize new facts. If the facts show that you have not done something correctly, you may not want to admit it. If false information makes you look good, you are more likely to believe it.

Great programmers balance this high view of themselves with a large dose of humility. The humility comes from many long hours working with and admitting their own mistakes. Sometimes though this isn't enough. Sometimes you have to fake humility, so that you can continue to chase a problem until you reach the point where you have to admit to yourself that you screwed up.

And sometimes when searching out a problem you need to take a step back and think about the simplest solution that works. It all leads to the same place where you smack yourself on the forehead, and say "Doh! I hate when that happens."

Simplicity is Hard

2007-04-12T22:12:00.000-04:00

With John Maeda, and others promoting simplicity, it seems that the time has come for us to begin to develop simpler products, that actually do less, yet do it extremely well. Traditional software development is expensive and resource-intensive. Simple products need less money to build, fewer abstractions to maintain, and nothing to break.

I've heard of three-member teams designing and building products. The product definition is paired down so that three people can complete the project in a reasonable amount of time. The theory is that when you have fewer people and less time, you don't have time to think about over-engineering the product. By building a simple product there is less to maintain.

I'm all for small teams, less engineering, and only implementing what is needed today - these are all standard agile fair. Having the discipline to stay a three person team under market pressure has to be really hard, but staying agile is hard at times too.

Maybe it's just that simplicity is hard.

Don't Fool Yourself

2007-04-09T22:01:00.000-04:00

As I wrap up another project this week, I'm beginning to get feedback from my client about the software we released last week. It turns out that we have had over 3000 unique users, and only two bugs reported in the first 8 days. My client is very happy with these results. I guess I've come to expect these kinds of results given that many of the people I work with are great developers.

I'm reminded again that personal software development habits and discipline are the most important ingredient in having a successful project. The overhead-heavy Personal Software Process and the travel-light Pragmatic Programmer perspective both agree: Programmers must be scrupulous, not just enthusiastic.

Integrity to yourself and your customers is probably the most important discipline a software developer can have. Don’t tell people the project is going to be on-time if you know it’s not; your customer may admire your desire to accomplish miracles by sheer will power, but they no longer believe in fairy tales. You can't tell them you’re totally committed to quality if you’re not; they’ll know you’re lying the first time they see you sacrifice quality to meet a deadline.

You can deceive yourself into thinking you are doing what is right, when in reality by cutting quality you are hurting everyone. As Richard Feynman said, "You must not fool yourself - and you are the easiest person to fool."

UI Design - Always Learning

2007-04-02T21:38:00.000-04:00

About a month ago I wrote a little about personas. While personas are helpful, placing a specific persona into a specific scenario or use case can be even more helpful.

To create a scenario, the designer must discover the various tasks that a user performs to fulfill a goal. For example, the user goal could be to order a book. The tasks then are broken into finding/selecting the book, paying for the book, and having it shipped to the correct address. The tasks can be rearranged and create different scenarios.

It can be difficult to break up a goal into a series of tasks. So, I may start with a design that is a bit harder on the user, but works as a prototype, and can be used to validate the overall approach. By taking what I learn from this initial guess, I may change the design significantly. Hopefully, I get to the point that each task's interaction improves with each iteration. Though I've never really kept track, my intuition tells me that as more functionality is added to the system, the interaction improves since I can exploit/implement features that weren't available earlier.

The problem with this approach is that the pile of interaction design related stories never really gets done. When I finish a set of stories, a new set are introduced. This doesn't bother me, but customers and developers like to see the pile get smaller. Paying attention to interaction design in this way doesn't help shrink the pile.

The only way we could have interaction design play well with a truly agile development approach is if the design was completed before the programmers began. Of course, this flies in the face of an agile team. So, we still attempt to work out the details.

That is one downside of an agile approach - I am always learning.

Interaction Design and Agile

2007-03-30T23:40:00.000-04:00

Many agile developers may not be aware that incorporating interaction design into an agile process has been a problem for many years. Alan Cooper and Kent Beck debated this issues 5 years ago.

So, while many people have tried various ways of incorporating the two, you should understand that an agile team working hand-in-hand with a interaction design team can be tricky. However, there are two things to keep in mind to keep things going a little smoother:

Design before code. Design by its nature occurs before writing code. So, let the interaction designers work an iteration or two ahead of the developers.

Test Design on Users. Any process that is concerned with usability must include some form of usability testing. Give the interaction designers time to get some feedback before code needs to be written.

An agile approach that is concerned with usability is going to work out how to get these important aspects of product design built in. Jeff Patton is one of the leading experts in this area.

Keyboard vs Mouse

2007-03-26T22:36:00.000-04:00

While working with a client recently, I spoke with one of the data entry folks who adamantly states that the application needs to be fully operable without ever touching the mouse. As she said this, I thought about all the work that would need to be done to fulfill this one request.

After looking a little deeper I discovered that the "whole application" really means two screens. Fortunately, she is not familiar with the whole application, and the whole application does not need support keyboard navigation, only the two screens the data entry people use.

Power users learn keyboard shortcuts like <Tab> to go to the next field or <Alt>+<Tab> to switch to a different window. For this client, we need to implement the <Return> key to go from one field to the next. These shortcuts are learned, and in a sense become tribal knowledge. There is little or no relationship to their literal meaning. They are not in any reasonable sense intuitive.

Windows apps and Web forms need to support <Tab> and <Shift>+<Tab> not only because it's the standard but because many users expect it. The ones who don't know about it are unaffected but the ones who routinely rely on it are greatly affected if it is left out.

It seems that the preference for keyboard vs mouse is not only an individual choice, but it is also affected by context. Some studies have shown that users shift between using the mouse and keyboard based on the task at hand. One technique is not necessarily faster than the other. In general, most people can type successive keystrokes faster than moving the mouse, but this is not always the case.

So, just like most things in product development, the keyboard vs mouse debate boils down to it depends. In a data entry intensive environment, keyboard navigation is faster than a mouse. However, studies have shown in most other applications it doesn't matter.

No More Excuses

2007-03-22T21:39:00.000-04:00

An Agile team that is working to incorporate usability design into the product may struggle with regularly testing the UI. Here are a few tips on incorporating UI testing into your daily routine.

Test what you can. There are aspects of the UI that can be tested using automated tools like Jemmy: tab order in forms, global navigation, etc.

Test feature sets. It may be difficult to test across feature sets, so begin with testing individual features/stories and build from there.

Look for things to test. Teams should look for ways of automating tests that validate stories from a users perspective. These tests may not be run as acceptance tests, and may be small, but that's OK. I have never encountered a team with too many tests. Basically, what I'm trying to say is, don't make too many excuses to not automate tests.

Promote Flow

2007-03-17T22:01:00.000-04:00

Last week I moved my home office from the basement up to the main floor. I'm hoping to make it work in spite of the noise, but am struggling with maintaining a state of flow. As a result, I've begun to wonder about Peace of Mind (POM) in a distracting environment.

Part of maintaining peace of mind is being able to focus on a few things in general, and only one thing at a time. From a whole life point of view, it's when you own fewer things and are involved in a few activities that you enjoy. This is the essence of simplicity. The more stuff you own, the more stuff owns you. The more activities/commitments you have the greater the stress. By simplifying your life, you have less that owns you or stresses you out. Fewer commitments/concerns enable you to more easily focus on your current task – which promotes peace of mind.

Taking this another step further, if you don’t have that peace of mind you build those distractions into the systems you work with. However, when you have peace of mind, you do the same - build peace and confidence into your systems. [Systems being used very generally here to mean anything in life.]

In a software development project in particular, a programmer may add a needlessly complex component to a software system, and force his will onto the system. Often you find a developer wants to try some new Microsoft application block, or similar component, and implements it rather than implementing what is best for the system. Deep down in his gut, the developer knows that something about the implementation doesn’t promote peace within the system, but leaves it because he got learn more about some useless widget.

So, how do you promote POM in a system, when you design/build using tools that are unfamiliar or actually building systems that are unfamiliar? Good question. An obvious suggestion is to work as quickly as possible to get up the learning curve, so that you know what POM looks like in that context. Prototyping and experimentation are key to this. You continue to prototype/experiment until you are at peace with the major components of the system, and have the discipline to not start building until this peace comes.

I'm not talking here about the common unknowns in building a system. A strong commitment to refactoring can help mitigate those problems. I'm talking about developing a solid understanding of the approach you are about to take. Incorporating a spike into your iteration can save you a lot of headaches later.

So, there are tools that we all use to help maintain flow, and keep a bunch of complex interactions in our head at any point in time. Unfortunately, we can't keep too much in our head at any one time, so we use paper and pencil, graphs, numbers, charts, maps, etc., to help us. However, the best guideline to help with this is actually a lack of guidelines.

It seems to me that organizations very often castrate good programmers through insisting on certain programming practices. In my experience, the real value of a programmer (how much quality work he can turn out in a given time period) is inversely proportional to his needing guidelines. Rarely, I find a good programmer who is also able to follow methodologies, create documents, etc. - this is the exception not the rule. Generally, the best programmers act intuitively. I’ve even noticed in my own work, I do my best and fastest work when I'm in a state of flow. Answers to complex issues seem to just come to me. However, when I’m bogged down with project leadership, personal problems, or other issues, I get distracted, and wind up churning out stuff that I'm not all that proud of.

I wonder if one big difference between the good and the great programmer is his ability to maintain this state of flow, and working in an environment that promotes it.

Role Playing

2007-03-14T21:32:00.000-04:00

Today the customers on our team were having a hard time working out how to describe a story in a way that the programmers could understand enough to code. After the meeting we had one of the programmers pretend to be a customer, and role-played the customer-programmer interaction. I had heard about programmers that do this with object modeling, so I thought I'd try it with customer interaction. It sounds kinda hokey, but it helped, and there were two clear benefits of role-playing.

First, the programmer who played the role of customer got to experience what it's like on the other side of the table as a customer. This role reversal had a positive effect on the programmer, and seemed to facilitate a kind of training in "people interaction" that he had not had before.

Secondly, the programmers who interacted with the "customer" got to try out some new ideas in a safe environment. It allowed us to practice saying things and asking questions that we haven't asked in a real customer interaction.

So, based on my one sample survey, I'd say a good training technique is role-playing.