switched on

I am preparing a coding techniques workshop for the dev area at work.

I've been reading and researching coding techniques for over two years now and I want to share the knowledge that I've learnt. It seems to me that it's not so much the lines of code you write (although that is still important) but it's more the way you structure your code.

One developer on our team was interested to see what I was going to present, so I ran some of the concepts by him. He was keen to give them a try.

He seemed to "get" the reasons why this concept is important. So much so that in the next task he was working on, he was applying them. It was amazing to see how the change had effected his coding.

He was switched on.

performance

Sometimes the illusion of performance is enough.

Here's an example:
I just tried to copy a DVD full of files over to my hard drive. It got part way through and then it threw an exception. Some of the files got over, some didn't. So now, I'm copying the files one by one. This is a slow (and annoying) process.

But copying them as a group seems faster.

I'm not sure that the actual time taken by the computer will be that different, more that my interaction will slow the process down.


This is a great example of how the time involved is similar, but the effort and inconvenience is higher when moving over files one by one.

This is demonstrating is that by using a "natural break" in the process, it seems easier and faster.

This is a lesson for application design. Look for
- breaks in the workflow that can be unobtrusive to the user
- ways to group actions without involving the user (could be as simple as multiselect in a list)
And this will help your application appear to be efficient.

Try to avoid:
- frequent pauses and halts to in workflows
- lack of feedback about what the computer is doing
These make your application annoying and slow.

Some simple rules:
- always give feedback to the user, especially where the delay could be more than half a second
- show them that the process is still executing
- if possible tell them exactly the progress of the task and the expected completion

testers

I like testers.

I used to think that they were only for testing the application to make sure that I'd completed the task correctly.

What a naive view on the true power of testers.

Testers can make your project so much more successful. You should include testers from the very inception of the project. They can help with:
- analysis of the issues
- define the scope of the work
- define successful (and unsuccessful) conditions
- show you what's necessary to complete the task
- provide a different point of view on the issue and how it fits into the application/project

"How? " I hear you ask.

Well, quite simply, get them to analyze the requirements, write test plans/test cases in the initial stages of the project/task. This effort almost the same as them writing the test plans/cases when they are delivered the application for test, but if that information is available to the developers, then they can use it to determine how much work there is to do. It can also be useful for the project lead/manager to help in creating a "block plan" of the tasks involved.

functions vs workflow

I worked on a project a few years ago where the project requirements were in a Business Requirements Specification (BRS). The end result is usable, but it's difficult to get value from it - all the information is in the system, but bringing it together is tricky.

Had the requirements been defined in user stories/use cases, then I believe that the end result would have been much better. (It's important to note that the project was run in a waterfall fashion, so the users didn't see it until it was complete and that was too late...)

I can really see how analyzing a requirement/issue/project focusing on use and purpose rather than discrete functionally makes such a difference to the end result. Requirements analysis is still necessary - but it should be in context of use.

practice vs theory

We had our first team estimation meeting today.

It's a technique from Agile Estimation and Planning.

Basically, the whole team provides estimates for the development and test component of each issue. The idea behind it is that as a group we should be able to better estimate the work that if just one does it. Additionally, since the work is not allocated a resource until just before it's started, anyone on the team may get the issue, so assuming that X will be responsible may skew the estimate.

It's interesting to see how things work when you are doing them for the first time and the team and the business are not experienced with particular techniques.

Several team members added very relevant points and I think that more agile concepts became understood by the team.

It went rather well.

where next?

What's next for me?

My boss keeps telling me that his type of job, a manager, is the next logical step for me.

Hmm... I'm not too sure. I can see quite a lot of options, but I'm not drawn to be a proper manager, one that has to manage budgets, staffing issues and the like.

It's not that I wouldn't do it, but, I don't currently see the appeal.

I really like managing teams and being a technical specialist. That can lead into many jobs, including roles like:
- project management
- trainer (in team management, development techniques, etc)
- consultant (yes, like you Mitch)
- development specialist
- architect
- others that I can't think of because it's late and I've had a few drinks...

I guess my point is that the process shouldn't just be:
- developer, then
- team lead, then
- manager.

It's OK if that makes sense for you, but remember that people who are keen to step up have many options in their career. Find what you like to do, or are good at and work at it - you'll be amazed what you can do...

co-location

We had a move today at the office. All seats were re-organised so that teams were co-located.

I was the bunny that was responsible for organising it. Several people complained.

Why do I have to move?

It's such an inconvenience!

What's the point?

Within an hour or so of moving, I overheard a conversation on an issue that I have to report to the business on on Tuesday.

Whammo!

This is the reason why it's important to sit with your team. The cost of communicating must be as low as possible. This can deliver real benefits to the immediacy of information and help.

There will always be nay-sayers. Ignore them and know the truth!

quote of the week

I gave a presentation the other week about how we want to improve the current situation of the interaction between the support group and the business.

I had a slide that had the following line:

"more transparent and more visible"

Apparently the Business Analysts section decided that it was their quote of the week...

I know it sounds contradictory, but I'm wasn't after the literal meaning of those words. What I meant was:
- more transparent, so that the business can see exactly what we're doing, when we're doing it. This helps to improve trust.
- move visible, so that the business sees that we are there and know what we do for them. This helps to improve communication.

Both communication and trust are very important if you want to improve the acceptance of agile methods and get the business to become more involved and receptive.

Without trust and communication, you're fighting an uphill battle to get positive changes made.

more ducks, more rows

After getting things in order as described in the ducks in a row post, things seemed better.

But recently I was feeling out of control again. So I set out to work out what the problem was...

It was those damn ducks again. The ones that I knew about were in a row, but several new had ones turned up.

I determined what information that I wasn't in control of and I made it visible - I had to get out my trusty duck herder and herded them into a row.

Much calm has returned.

(Hi to Nick if you're reading this!)

more on crystal clear

I wasn't too enthused about Crystal Clear in my last post.

I've read some more since then and I think I misjudged it. It certainly gets better, but I still have the feeling I've read it all before.

I'm sure that that's because in the bit that I've read, it's all similar to other agile processes...