Sunday, January 30, 2005

Is the project stuck on convergence?

Just finished Mary Poppendicks book. Good discussion on convergence of the project.

Our project is stuck with a convergence problem. The developers are getting ansi that we won't get the application running and that we may be worrying too much about the last 20% of features.

These are the interesting features for our customers, but also fall out of scope of this first project.

I think we need real data ASAP. That will drive some focus and hopefully early convergence.

Saturday, January 29, 2005

The gulf

We have eight customers on site.

We have eighteen developers.

Everyone is intelligent, doing their best to get the job done. However, there is distance between the teams, physical and understanding. I think the physical distance leads to misunderstanding, misinterpretation and makes the gulf wider.

We all need humility.

Specification won't be perfect. Implementation won't be perfect. There are too many translation layers. Customer -> tests & developer -> code. Each translation introduces error.

It's important to understand that it's not just broken telephone, but translation between English and French. The words can be understood but there are "cultural" differences as well, subtleties and nuances are missed. Eric Evans domain driven design is an attempt to close the communication gap. So are frequent releases and having the customer on site.

Writing it down will solve none of the communication problems. Being humble, and getting closer will make it easier.

More team growth...

The team is starting to take responsibility for itself.

Our tests started slowing down. One of the members turned around and said they need to be fixed. I suggested, that someone should take responsibility, they did.

The second time the tests slowed down, the team member didn't even turn around, they just made them faster.

Other good signs. People are taking over design and architecture.
  • Rado has reexamined contracts, coming up with better designs.
  • Zach had his first experience showing people how to refactor the code, rather than rewrite.
  • Zach has been examining a weak part of the system (TaksResults).
  • Chart has identified some of the problems with and asked to be involved in its refactoring.
  • No more bootcamps. As new people come onboard the team absorbs them and teaches them how we work.
Nice. I think the project belongs to them.

Be absent

Wonder how your team is doing?

Be absent at a critical moment, see what happens. THen you'll know the gaps you need to fill.

Monday, January 24, 2005

Think Responsibility

If you want to be a better OO developer, you need to think about responsibility. Answering the question "which object should be responsible for this behaviour?" will put you in the top 20% of OO developers.

Stay on target...stay on target

Had an interesting conversation with Joseph this evening and we arrived at an interesting conclusion about scope creep. How do you stay on target?

Developers stay on target by confining themselves to making the tests pass. Often we fail (we are all human) and stories get bigger, but it does keep us within reach of "reasonable".

How do customers keep on target? By concentrationg on the wrong things a user can accidentally focus on the most difficult 5,10 or 20% of a system, that takes 80% of the time to build.

A product backlog, maintained by a project manager, can help keep things on target. I have used a spreadsheet and an orange bar that indicates when funding runs out, to minimize business scope creep. Business users must make hard decisions about when stuff goes above (in scope) or below (out of scope) the orange bar. However, customers often don't feel the urgency untilo the money runs out.

Alternatively, users can use actual examples to drive their progress. By choosing examples in order of frequency/difficulty/(insert appropriate criteria here) users can ensure the system is evolving along lines that will be useful to them, and avoid spending 80% of the time solving 5% of the problems.

Wednesday, January 19, 2005

PasFit

Stephan created a test suite of 7 tests - running various allocation methods in our system. In those 7 tests there are 7000 asserts about what the data should look like.

This makes the tests a "warning system".

This is interesting, because it will not be a precision target missle. So an assert failed - what caused it will not be answered by the test. It's a warning flag, the testers need to explore because something has changed in the system .

Another goal should be to "certify" a daily build as worthy of exploratory testing.

Present solutions not problems

Had an interesting talk with Zach last night. As a person running a larger team, I now have some insight into that phrase "Present solutions not problems".

When you're running a larger team, you need to rely on your developers to generate new ideas and run with them. (see ask permission not forgiveness). There are going to be problem areas in your code, some you know about some you don't. What doesn't help is when people say the code in area 'X' is terrible and needs to be refactored.

As a leader of a large team, it feels like people are asking you to agree with them about something you may know little about. You are being asked is it is OK to refactor this code, and help prioritize it. As a leader you are missing critical information that will help you judge return on investment. I know I used to present problems to management, I was seeking permission to explore them. Well, this is explicit permission to explore the problems you find. After that few hours present the steps to solution and the ROI.

If you find a piece of code that is troubling be prepared to show the first steps in cleaning it up, show how it will help (simplify/generalize/reduce bugs) as well as the refactoring steps to get it there. This shouldn't take more than a few hours to put together. Turn a problem into a solution.

Keep on eye out

for opportunities.

Trevor and I were beginning to import our customers exports from their current systems. We began down a path that would talk us a couple of weeks. We pursued this for a number of hours and after reviewing the code realized it looked very much like our current code for importing.

We abandoned our current strategy and re-evaluated. By doing things slightly differently I think we saved ourselves a couple of weeks worth of work.

Friday, January 14, 2005

Thanks Stephan

Stephan - one of the testers at our shop - spends a lot of time with the developers making sure he's in contact and reporting everything he knows about the application. His patience and willingness to pursue abug to its conclusion are admirable.

I appreciate the time and effort he puts into communicating and assisting developers take bugs out of the system. His approach and style are very noteworthy. Thanks Stephan.

Is FIT project dependant?

Stephan set up a FIT test in the framework I wrote for this project. He had over 600 asserts, which I found amazing. He actually just grabbed a working example and was able to paste the asserts into the PasFIT Spreadsheet.

Interestingly, to generate that many numbers it only takes 30 or so input values, in our system plus a pile of fixtures. The web interface for FIT would never work here, although I still use the red colours to denote errors in the spreadsheet.

It makes me wonder if FIT is just a concept...and that on lany projects it will need to be implemented differently. I know ClearStream at Transcanada implemented their own version as well.

Thursday, January 13, 2005

Ruby Web testing tool

Another scripting tools for testing through browsers. This one is written in Ruby - an OO scripting language.

http://rubyforge.org/projects/wtr/

Oops.

Spelt Brian Marick wrong in the links. Thanks go to Jonathan Kohl (via Stephan) for the pointer.

Leadership: Direction not control

One of the things I've learned raising children and am trying to apply to leadership is how to direct rather than control. By controlling you have two side effects. The first is you create opposition - people will directly argue and fight with you. The second is you can create followers, rather than leaders. People will believe they can't fight the system, give up with new ideas and just follow whatever is the current standard even if it is stupid.

You need to give people room, ask questions, and explain to them what is concerning you about the current situation. You may or may not be able to presuade them to change their course of action. Better yet, you may arrive at a compromise or something completely different.

The key is you are not in control, just trying to direct.

Testing Progress

Project has 3000 Junit tests - we will probably go over 10,000 on the project.

We're beginning to see some momentum in the project. Colin Jones was able to add a new product in a few days, and generalize the code.

PasFit is now being evaluated. One of the QA peoploe dropped over 300 asserts into a PasFit test. Interestingly, it took less than 20 GUI actions to generate that many results. This might be useful.

Wednesday, January 12, 2005

Yuk

-30. -43 with Windchill.

Time to say Goodbye

I'm now officially entering middle-age. I'm turning in my Red 1988 Mazda RX-7 sports car for a Pontiac Montana mini van.

I bought the car 10 years ago for $5000, and am getting about $2000 for it now. The car has a great following and people want it. I personally, never want to see the thing again. However I had a lot of fun in it over the years. It's gone across the country twice driving and once on the train. It's been hit by a garbage truck, an SUV and a falling rock on HIghway 1 around lake superior (always repaired). It took my wife to the hospital with our first child, when the other car broke down on the way to the hospital. It took me and Mark Roseman through the mountains on more than one occasion.

When I was a lot younger I did 180km/h in it - and scared my self silly when I thought about hitting a deer. Various people (including myself) have squeezed into the back hatchback, because it only seats two. Rado was the latest "in the hatch".

It drove me to all my fulltime jobs - OTI, U of C, Rightsmarket, Teamwave, EFA, Presslogic, ClearStream, and now CGI. It has been occupied by various cohorts in which we've discussed development and making a better product on a drive home or to a restaurant. Many of those friendships and working relationships continue to this day. In fact Alan and Joseph are working with me at CGI.

Goodbye RX7.

Refactoring Fun

I had fun refactoring the code to the Snapshot pattern with Zach. Between us, we figured out how to make a fairly large design change through refactoring. We moved a whole lot of behaviour around in critical classes in our system isomorphically. Together we built on one anothers ideas to figure out how to do the refactoring. I really enjoyed working with Zach and look forward to the next time I pair with him.

Monday, January 10, 2005

An interesting take on our project and domain driven design

http://www.codeblueconsulting.ca/blog/index.php?p=22

Selenium

Courtesy of Colin Jones.. a thoughtworks tool for test automation through the GUI...

http://selenium.thoughtworks.com/index.html

Interesting. It provides a simple script for writing GUI level tests. There's a simple scripting language for controlling the browser html. There are additional scripting elements for soing simple asserts agains the browser html.

This looks interesting. The PasFit stuff I wrote works through spreadsheets. It has a simple scripting language for performing actions like clicking buttons and such. A second spreadsheet then contains a list of asserts against the database. If you get errors, it highlights those errors in Red.

Might be an interesting way for Mark Roseman to automate test of courseforum.

Sunday, January 09, 2005

A good refactoring

How do you know a refactoring is good? Are you moving code around or creating the perfect design, or are you actually making the current code base easier to use?

For myself, I can tell the difference between a good refactoring I'm doing and a navel gazing one early on.

In small refactorings:

1) Very quickly the refactoring cleans up a small amount of code.
2) You feel you can read the code quite easily
3) Generally it involves only four to five methods
4) It takes about ten minutes

In large-scale refactorings

1) You're usually refactoring to an existing pattern, either in your code or one thats known
2) Within a couple of hours the code is feeling better as it cleans up.
3) You have experimented with the code for at least a few weeks previously, and have arrived at the preferred pattern.
4) As you refactor the code cleans itself up, as the pattern has wide spread effects on your code.
5) The refactoring has unexpected benefits, things you didn't think of are better now.
6) It large refactoring is really a series of small refactorings that you apply over and over. YOU NEED TO FIGURE OUT WHAT THAT SEQUENCE IS, AND IT WILL TAKE LESS TIME.
6) It can take anywhere from a day to a couple of weeks.

I am lightly nerdy

This was fun to take:

http://www.wxplotter.com/ft_nq.php
Somewhat nerdy. I mean face it, you are nerdier than about half the test takers.

I am nerdier than 57% of all people. Are you nerdier? Click here to find out!


Face it, if you takes this test you're already in trouble.


Friday, January 07, 2005

Dumb things to say...

Usually, I find Joel on Software to be quite interesting, however occasionally his biases of how the world works is, uhm, well, not what I would have thought.

"Learn C before graduating"

When I was going through school I was told to really understand computers I needed to understand Assembly language - because I really wouldn't understand computers. Well I learned it and used it in my career a couple of times at the beginning. I learned C, and no longer use it. Return on my investment since then? About zero.

If you know why while (*s++ = *t++); copies a string I probably won't hire you. The next guy (which may be you) to maintain it would spend a long time figuring out what the hell you're doing. strcpy works just fine. Obfuscation of code is dumb.

" you'll never be able to create efficient code in higher level languages. "

Uhm. I thought tectronics dispelled this myth when it sold commercial oscilliscopes with Smalltalk as the engine - in the 80's. I've helped write real time collaboration software in Tcl/Tk. This argument is way old and should be made by someone with a beany.

"a medical doctor who doesn't know basic anatomy, passing out prescriptions based on what the pharma sales babe said would work"

Uhm drug history is essentially, we tried this, it made them better, and they had these problems. Like any good professional, doctors and developers need to rely on their colleagues. They can't understand the exact chemistry of each drug, they generally know what it does and what it helps. They rely on others who put the drug together to have done their job.

So enough ranting - what do I want in developers just out of school?

How to talk - be precise and clear in your thoughts. Practice being a short winded as possible.
Excited about learning. When you come out of college you think you know a lot. Well, in about 20 years you'll figure out the truth. Like me - you're an idiot.
Knowledge of the latest languages. You better know .NET and java.
Knowledge of some esoteric language you learned. Show me you know why they taught it to you. Why is it important? What has it taught you about the latest languages?
A willingness to listen. The only way you learn is to listen.
Ability to identify computer sciency stuff. Like, what is a pattern? Why are refactoring and redesign different?

With those skills I trust you'll learn the rest on your own.

Thursday, January 06, 2005

Reading...

Lessons Learned in Software Testing. States stuff we all know concisely in one place. I like when people summarize like this, it makes things clear. Clear is really hard.

Keep your Goals in mind

It's important to remember when you're in the code refactoring or implementing a new feature to keep the goal in mind.

With the goal in mind you can make decisions more quickly. The following glaringly obvious mantra is important: "How does this help me do....". Ask yourself frequently. Like every 5 minutes.

Tuesday, January 04, 2005

Bring something to the table

Some contractors I've met in past projects have been concerned about being paid for every hour they work on a project. I don't work that way, I try and share the risk - bring something extra to the table. After all aren't they paying me for my "expertise"?

Sometimes that expertise comes with experience, and sometimes that experience must be gained by being a day or two ahead of the project you're on (something I learned from Shaun Smith). This means learning stuff on your own time, and experimenting with new stuff.

On this project, I have been experimenting with the FIT framework and figuring out how to run toplink in memory. In one case, I'll only charge the project for the tools I build - if they are useful (accept the risk). In the other I want to keep the code, so I traded it for access to some other code I had written on the project (build your own library). In both cases I learned stuff that will be useful beyond this project, and provided something that has/may change the way we work.

Snapshot refactoring

Heres the step we figured out to create a snapshot out of an object that has date effective logic.

  • Create a superclass called XMaster and have X extend it.
  • Pull up the instance variables from class X
  • Encapsulate the local variables
  • Change the super class of X to Snapshot ( a class that contains the date context + a pointer to the master), and introduce a local variable of type XMaster (you will have compile errors)
  • Use the delegate refactoring in eclipse to generate the getters and setter for the master.
  • In the O/R layer rename the class descriptor for class X from "X" to "XMaster". Cleanup any broken mappings
  • Any other master objects that refer to "X" in the system must be changed to refer to "XMaster"

Refactoring in small steps

In our current refactoring we are moving the business logic from a "Date Effective" object to a snapshot. Unfortunately, the first attempt at creating the Snapshot was unsuccessful, leaving business logic in two places, and the system being tightly coupled with both the snapshot object and the backing master object.

Zach and I are trying to tease the two apart, and this requires changing the contract on the backing master object, so that no one can call it and all the non date-effective logic can be moved into the snapshot. The first thing we did was identify the contract and minimize the number of other object that were allowed to play with the master, they were forced to go through the snapshot.

We followed a couple of setps in Java to change the contract - forcing object to deal with the snapshot rather than the master object.

1) Each method we wished to removed from the contract we made protected

2) We found all references to that method, which were now broken and forced them to go through the snapshot if possible. Occasionally, this was not possible as a few methods would have a large impact on other pieces of code - we deferred those.

3) After each method change run all tests, repeat

There were then two cases two deal with to move the method to the correct class...
i) The method already existed in the snapshot. We made sure it delegated to the master. We found all the methods that referenced the one to be moved, and sent it to the one on the snapshot. We then inlined the master method.

ii) The method existed only on the master. We added the snapshot as a parameter to the method, and then moved the method to the snapshot.

All in all pretty tidy.


Sunday, January 02, 2005

Ask forgiveness not permission

Very important principle in innovation. Make sure to try new stuff. If it doesn;t work throw it away. If it does work let your coworkers know.

Remember anyone can find a million reasons why something won't work or be useful.

It will only take one reason to make it useful.