Duh, now I get it.

Why don't our customers get incremental development? Because they work in a waterfall environment.

Some of their processes currently takes days to run. They will get all the numbers late in a month. And then they must report on the results of running the process by the end of the month. Missing a deadline is monetarily costly.

Checking and rechecking their setup and data makes sense because of the time cost of running the process. Upfront work and preparation in their business is cheaper.

Unfortunately, it isn't in ours.

Somewhere there's a balance

When working in a team you need to improve both the quality of your code as well as the quality of your teammates.

The highest yield comes from having your most experienced teach your teammates. Your teammates make better decisions and write better code. However, it is the most time consuming and incremental. (I guess this is why people say only hire the top 10%, by the way who are the other 90% working for?).

The fastest yield comes from code improvements. By dedicating experienced resources to improving code quality you get immediate results.

The trick is the people you haven't brought up to speed will soon be in that code.

Somewhere there's a balance.

Changing an agile process...

Changing an agile process is important. However the changes you make should improve your agility, not reduce it. Ask yourself these questions:

• How do I communicate better because of this change?
• How does this change guarantee that I learn from my mistakes?
• How does this make the what we do more testable?
• How does this change evolve?
• How does this help me deliver earlier?

You're going to have people (other than you) trying to change your process. It is important to let them make change, but also let them know the criteria on which their poroposed change will be evaluated.

Software Terrorists

Courtesy Colin Jones...

http://68.236.189.240/article/column-20050501-01.html

"Valuable tools in the hands of experts become dangerous weapons in the hands of terrorists. The terrorist doesn’t understand how to use generics, templates and casts, and so with a single click on the “refactor” button he destroys the program’s carefully crafted typing system. "

Task specific editors...

One has to remember that most of our colleagues still live in another world - which text editor is good? Is it as good as emacs?

http://www.markroseman.com/blog/2005/05/textmate.html

Wow. Those seem like the dark ages. When text editors didn't support the tasks you were performing. They provided you with the basics, nothing more (Ooo look I can highlight a rectangle!). Really, Eclipse and IntelliJ have changed the way I work. It's just a matter of time before all editors do the same thing. How do you change your code if you don't have refactoring tools?

I might choose my next language based on the tools. Languages aren't that big a deal. (Well okay, Smalltalk might be a big deal).

Dealing with it...

Interesting. I have just begun Enbrel (for my arthritis) again after a several month absence.

For the last month I have been experiencing continuous distracting pain again. Even is you lie down, the pain doesn't go away. Pain is an interesting thing, it makes you foggy. You think you are dealing with it until it goes away. When it clears, you look back and go "holy cow, how did people live with me?". You look at how it changed things you do everyday and decisions you make. (anyone spot the patterns in my blog?) You realize how blind you were to its effects because you were "Dealing with it...".

It makes me wonder about Pain in your code. You really can't tell how much it hurts until the pain is gone because "You're dealing with it..."

In search of...

We're searching for a new variant on our model. Our code is getting more complex and complicated than I would like.

We're looking for new ways to express some of our ideas where we see the cracks. I'm interested in how much will change. Will ideas that fundamentally changed the way we worked six motnhs ago disappear, or simply morph? Or will they become enhanced.

We're on the journey, beefing up those refactoring skills again. No constraints. No fear.

We have 4200 functional tests to watch our back.

Good blog on private methods.

http://homepage.mac.com/keithray/blog/2005/04/23/

Bug Advocates

One of the important roles of a tester is to be an advocate for bugs.

As a team lead/architect advocate/mentor I have many demands on my time. If people don't talk about something I often assume it is in good shape. An important role of a tester is to be an advocate for their bugs, to make sure I assign an appropriate amount of the teams time to fixing things that are problems.

I *like* it when testers find problems with our code. I need your input to tell me how the system is doing, how important it is to fix something, what is getting in our way. If I need to figure it out for myself, I might miss, delay or ignore important stuff.

How our users think...

In our system we have a bunch of medium grained objects, and a bunch of visitor type stuff.

Visitors are essentially procedural code designed to integrate nicely with objects. So, really, we have OO code mixed with some procedural code.

Our Visitors generally do work our customers describe in a series of steps e.g. allocate at the top, go one level down do the same thing to all the children, go another level down and do the same thing. Rinse, lather, repeat. Nice work for a visitor.

I'm currently debating, with myself, the merits of trying finer grained OO objects in this domain. The code reflects how the customer thinks about the domain. A set of medium grained objects, that do a bunch of procedural calculations. Making finer grained objects will break the natural translation of what they give us, but may give us reuse.

Of course it may be a bad idea, but I'm certainly going to try it. I'll learn something.

Models, Models everywhere ...

When you're working in a domain there can be many models on which you base your domain model. The domain model must reflect a proper balance of the various models a user sees (although it may all appear as one to them).

In our project we have three or four models, each competing with one another.

The Gui model reflects how users want to do data entry and control the workflow.

The Physical model reflects the "things" are users are performing accounting on (in this case, our things are wells and meters and oil and gas...)

The Accounting model reflects how they report on those activities. e.g. converting what really went on into ownership and taxes and revenues. Then telling the government all about it.

Our Domain model must reflect an appropriate space that allows all three of the things to be easy - as well as allowing for ease of development.