Finger pointing

In the Agile dev world, there is a rule saying 'no finger pointing'. This means not rubbing people's nose in something when they made a mistake. This to assure people don't become afraid of touching some code or making mistakes. I think it's also a way of being professional. Now here's the thing. Most people want to know when they made a mistake. So you need to tell them. It's about how you tell them of course. Polite and calm is the manner it should be. This works for most people, but the rule has a couple of disadvantages: What do you do when someone really doesn't give a f*ck? You already told him 10 times to run the tests before check in and he still doesn't do it. What do you do then? I say finger point away! Finger point till he cries :)

Proposal based

A month ago I followed the ScrumMaster (CSM) course of Jeff Sutherland and I'm an official ScrumMaster now. It was interesting to hear the guy that invented SCRUM - a former Phantom fighter jet pilot in Vietnam - expressing his vision on the IT industry. A couple of things stood out in the WAY he said them. He likes to formulate things differently. In the Passionate Programmer they talk about the transistion of being technology-centric to being solution-centric. You could tell that Jeff had an infinite respect for the developer (more than for management) but made an interesting statement: 'Developers are always whining and complaining about what's not right. In stead they should offer management clear choices'. For instance in stead of complaining 'we don't get the time to write tests' we as a community should say: 'Either we test and it will save (x-amount of) money in the long run or we don't and it will us cost money'. He's right. I've seen a lot of peers whining :)

Another thing a lot of developers don't do which I always try to, is the way we report issues. Before I communicate a problem to management or the customer, I try to have a list of possible solutions in my mind to propose to them. Not everyone does this, even if the answer to the report of a problem mostly is 'ok, what can we do about it?'.

Code that glows in the dark

I'm currently enjoying the Pragmatic Programmer (T.Hunt), which reads fluently thanks to the fact that it's build out of tips in the form of small chapters. Currently stranded at tip 15, I discovered a principle that I've already applied on a couple of projects, never realizing that it was a principle. Here's a distilled summary out of the chapter, shortened and mixed with an example:

Summarized book quote:

"There are two ways to fire a machine gun in the dark. You can find out what the target coordinates are. Then determine the environment conditions (wind, temperature, humidity, ...). After that investigate the specs of the cartridges and bullets and their interactions with the model of your gun. You can calculate the bearing and elevation of the barrel by a program. If all your tables of data are correct and the environment doesn't change, your bullets should land pretty close to the target.

Or you could use tracer bullets...

A tracer bullet is loaded on the ammo belt at intervals. When fired in the dark, their phosphorus ignites and leave a trail to what they hit, providing the gunner with instant feedback.

When you're starting a new project or building something that hasn't been built before and you're dealing with multiple layers/tiers/rpc's/libraries/ languages,... there are a lot of unknowns. The classic solution is to specify the system to death, clarifying each unknown. One big calculation of everything up front, then shoot and hope. Pragmatic Programmers tend to use tracer bullets."

Example:

For instance, let's say you have multiple clients on different platforms, calling your new webservice that needs to access some info in the DB, used to shoot an external webservice. Before the last step, giving back the result of this external webservice, it has to be transformed to another format and placed on a queue towars another system.

For each client, you could create simple tests firing a soap request asking about the one row present in the DB. A mock webservice deployed on a local or dev server, always returning the same (validated) result, could act as an external service. Maybe some sort of a persistent mean, like a file could act as a queue to see if the mock answer got transfered in the proper format.

Functionally there are few or no requirements implemented, but you've built a framework that allowed you to find out how the application hangs together as a whole (testing the different libs, marshalling, serialization, db access, soap calls, ...). You can show the users the interactions in practice and provide your development team an architectural skeleton on which to hang code.