Problems and Solutions

Problems finding solutions.
Solutions finding problems.

Both are valid ways to uncover new ground. But remember which you are doing. If you have a problem and are looking for a solution - explore many solutions. You want to understand the best fit for this problem.

If you are a solution looking for a problem - explore many problems. You are looking to see if this solution solves any of the problems you currently have.

Business is Personal

I often hear the expression "It's nothing personal it's just business".

Really? In our culture we tie our jobs very closely with our personal life.

Our business relationships are built on trust. We are dedicated to our work. We work well in evironments that are fun and friendly. When work goes badly we are stressed. Most people I know think about work in their spare time, trying to make it better.

We live, and expect people to move, close to work. We expect people to spend 40 hours a week with their coworkers. Many companies try to create an atmosphere where work is another family.

Business is personal. People who are laid off (for financial reasons) take it personally. Why did you choose me instead of them?

As a leader you must understand business is personal. The decisions you make affect people personally. Although you must make them for business reasons, you must realize the personal impact.

Refinement

Courtesy Colin Cassies and Colin Jones:

The reason we revisit code is to refine it.

This is the same you would do with a word document, or a powerpoint presentation. The first time you write your words on a page, they lack form and often substance. They do not flow together well. You write and rewrite until the points you make are clear, concise and meaningful.

Welcome to refactoring.

Strategy 8 - can't move anything

You don't like how the code looks. Your methods are eight lines long, but they only call methods in your current object. Moving those methods is not easy because they reference the current object.

Refactor by Inlining. You need to find different ways to break up the methods, so that dependency on the current object is broken. Once you've inlined everything, try moving stuff around grouping it different ways. Then extract methods and see if you can move them elsewhere.

Strategy 7 - Method longer than 10 lines

If your method is longer than 10 lines you might be on the verge of being procedural.

Try using the extract/compose method refactoring (basically your method indentation should be a most one deep). Then look to see if those pieces you removed could be moved elsewhere.

Strategy 6 - Still too many ifs

You tried moving stuff around and still ended up with ifs.

Refactor the ifs into the setup - you may find a factory allows you to create the appropriate object for the appropriate if.

Strategy 5. Make your code sound like the business

If your code sounds nothing like the business problem you're implementing you're going to have trouble refactoring. You have implementation concepts mixed with business concepts.

Convert your code to sound like the business and your changes will be a little bit easier.

Strategy 4 - Too many loops

If there are too many loops in your code the responsibility is in the wrong place.

Refactor. Each method should have about 1 loop. I find drawing a sequence diagram here quite useful. Usually you need to inject another object or push the inner loops elsewhere.

Strategy 3 - A bunch of Ifs

If you see too many ifs in your code and if you can't understand it and if the ifs are used all the time (you get my point)...

Refactor. Maybe subclassing or delegation will help. Look at what the ifs are operating on - if they are on another object you probably need to move responsibility to another object.

Strategy 2 - Code doesn't reflect conversations

If your code and your conversation about how things work are different...

Refactor. The code is trying to do stuff in a different way. Probably it has evolved from a point where it described exactly what the user specified. Along the way special cases were added and more functionality. Now that your understanding has evolved so can your code.

Strategy 1 - Lots of bugs

Testing finding lots of bugs in your code?

Refactor for clarity. Look at the method names. Look for ifs and loops as places to refactor. Look at responsibility - is the guy with the data doing the work, or is someone else?

Sophisticated Software Development

When I'm out, it is nice to be sophisticated every once in a while. However, in general I'm an ordinary guy with a wife, two kids and a dog who enjoys some terrible TV shows.

My coding is about the same. Sometimes I can write really, really nice code. Small, tight and sophisticated. A bunch of the time I'm just an ordinary guy. Being sophisticated is work, and really, like most people I can't (No matter how much I try) pull it off all the time. Yes, duplicate code is bad. But I think 2 duplications is better than 3 duplications. I'll try harder on the third duplication to make them all the same than the second.

Sophistication is a sign of maturity. Most of the code I write is new and hot off the press. Making it sophisticated is really hard when it's new. My code will get more sophisticated (read less duplication, more intention revealing) as it gets older and more experienced (ok, more used, refactored).

Sometimes I think the XP community is just trying to move the problem around from: "you need to be really smart to design" (waterfall) to "you need to be really smart to code" (XP - no duplication, write intention revealing code). Agile will fail if all the projects need the top 10% of developers. Agile must work for ordinary development teams.

I think we need to stop telling ordinary developers they need to get smarter about writing code and start showing them how to help their code get sophisticated as it gets older. Strategies for figuring out how and when to refactor AND redesign AND where to move the responsibility will help a lot more than asking them to get it "right".

Your code should mature as it ages. Maybe I'll write down my strategies...

Smaller objects

We're getting rid of a bunch of the visitors in one part of our code. It is interesting to see how a pattern that is extremely useful and concise in an early stage of a project can become a lead weight around your neck later in the project.

Additionally, the FIT test are also coming into play as we make these deeper refactorings. They point out change that our functional test are missing. The integration of FIT throws up automated warning bells as our refactoring has unexpected side effects. Generally, fixing these mistakes are relatively easy, since our functional tests catch the big errors.

Finally, the code is becoming more distributed among the object, responsibilities shifted to the people who control the data. All in all, its fun to do and eliminates hundresd of lines of complex code.

Expect to be informed

What can you expect of those who work for you:

1) You can expect to be informed

What can you do for those who work for you:

1) You can mentor them to show them new skills and strategies

What you can't do for those who work for you:

1) Tell them how to do their jobs - why did you hire them?
2) Tell them they're not doing it right - you really have little idea