one more book

I've just finished "The Pragmatic Programmer". This is another excellent book in the Pragmatic series. I highly recommend that you read it.

I've just started "Applying Domain Driven Design and Patterns". It seems quite good from the 10 or so pages I've read so far.

That's two down from my current stack of 10 that I'm getting through...

hey

I've been quiet lately. There's several reasons for this - none too exciting:
1. Busy at work. The usual excuse.
2. Reading. I've finished "Crystal Clear" By Alistair Cockburn. Much better than I originally thought.
3. Stumble. Check it out. It'll suck you in...
4. Bought 10 more books. I've read the first (practices of an agile developer), and onto the second (the pragmatic programmer). Got to say that every pragmatic book I've read has been great.
5. Lazy. No excuse for that one.

So I'm sure that I post a bit more frequently from now.

Yeah, right.

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...

another book done

Today I finished Agile Estimation and Planning. Quite a good book.

I am hoping to try out planning poker, but the work that we have on at the moment isn't really suitable for this.

The book has some good ideas and practices for dealing with estimation in an agile environment. Recommended.

I've just started with Crystal Clear. So far, I'm not enamored with it. I don't know why. I've been looking forward to it for quite a while. Perhaps because I'd read lots of stuff about it on the web that it feels like I already know the good bits, much like a trailer for a movie that has all the funny bits in it... Pity.

But I'll continue. I almost always read every book I start.

Tomorrow I'll be ordering some more from Amazon.

bonsai

I'm an extrovert. I like to talk.

But sometimes I think that I can go too long. I also think that others do the same.

I have a thick skin and am not easily offended, but I know that others aren't. People interpret things in ways that upset them, even when that was not the intention.

Enter "bonsai".

It's a stop word. What I'm suggesting is that this is a substitute for asking someone to stop. But because the recipient can interpret in a way that causes them no offence, then there's no miscommunication.

It's a benign word that can mean:
- we're off topic now, can you please stop
- I have other important things to do
- I'm not interested
- you're boring me and others
- that's very good information, but we need to keep moving

Or anything - it's up to the recipient to interpret it in any way that they want. This means that it's less likely to cause an issue. The point is that everyone knows what the purpose of the word is.

You could use any word that was sensible for you. It's just thought that bonsai was suitable...

ducks in a row

I've got a new team and role at work.

In the first week, I felt odd - something wasn't quite right. I felt, well, out of control. I couldn't work it out. I've been the lead on two previous projects and I knew that I could manage those. What was it that was giving me that uneasy feeling...?

On Thursday last week, I worked it out:

I was blind.

I couldn't "see" what the project was doing. I could fumble around and get bits of information, but not a decent overview.

So, I took the project and shook it about. I pushed it until I got what I wanted from it - visibility. I got my ducks in a row.

From then on, I've been feeling much better.

It's amazing how decent reporting has made everything much, much better.

I wholly recommend that if you're managing a project that you spend some time getting the right information at your fingertips. Once you do that, you'll be much happier.

simple things first...

I was working on a small financial app the other day (to work out where all my money goes) and I found that I started to struggle to make progress.

While I was watering the garden, I was mulling over how I was going to get the automatic categorisation and difference between actual and budget amounts working and then BAM, I suddenly realised that I wasn't starting out with the simplest thing I could do.

I decided that categorisation could come later, I needed a win and I needed it now. So I decided to just break down all income and expenses by each month and graph that. Easy. Anything with a minus is an expense and anything with a plus is an income. Within an hour I had it working.

I realised that the power of starting off in a simple way and getting a success is very important to being productive.

It's amazing how the stuff that you read is true, sometimes you need it to experience it for yourself...

extreme programming adventures in c#

Just finished the above book. I quite liked it, although it felt a bit long. I had to force myself to read it as it seemed to be labouring the same point over and over towards the end.

I'd still recommend a read, however.

Is it just me, or do technical books that are over 500 pages seem too long? I've read shorter ones and found that I blitzed through them.

I like books that:
- are short (300 pages or less)
- are very short (100 ish pages)
- have loads of useful stuff in them (this keeps them fresh to the end)
- or cover lots of specific topics so it feels shorter, like the 50 effective tips in C# book.

So if I ever write a book, I should remember that.

agile cooking!

I had to cook dinner tonight as my wife is busy at work.

And since I had to drop off and pick up the kids it meant that I was under time stress to meet my dinner deadline.

How to expedite the cooking process? How?

I knew that I needed the oven hot to cook the frozen delights, but I didn't know the required temp.

Right, time to be agile!

Step 1, turn on oven to approx temp
Step 2, search for suitable frozen delights for consumption
Step 3, determine exact temp for cooking and adjust thermostat.

Fantastic, I dealt with my riskiest concern first, got started with it, then adjusted when I know exactly what I wanted.

What an analogy!

silver bullet

I wish that there was one simple thing that I could do to ensure success of my projects.

I know more than I used to. I read and think and experiment. These things help.

But there is no one thing that ensures success. There is no silver bullet.

There are lots of things that will help:
- constant feedback
- constant review
- constant planning
- improving communication

But these are comprised of many more things/techniques. There is so much to consider and each project is different, so your concepts and tools will need to be adapted.

All I can suggest is to improve your knowledge and experience and talk to anyone that can assist. Ask to anyone that has experience. Ask anyone you respect. Ask anyone anything...

Don't be surprised if the quietest member of you team holds some gems that can help.

(If you do have a silver bullet, then please let me know)

management overhead

A while back I was asked if the effort expended to determine your progress/position in a project was worthwhile.

Well...

In almost all cases the answer is YES.

If you don't measure/review, then you cannot know if you're moving in the right direction. I won't bore you with an analogy of a boat a sea without a GPS... I'm sure you can imagine that.

So how do you determine how you're going? This is really something that is different from project to project, but assuming that you've got a project goal, you can assess your position against that. You do have a project goal, right?

An I'm assuming that from your goal you've worked out milestones? Yes, of course you have. So all you have to do is work out how you'll move from milestone to milestone, all the wile moving in the direction of your goal.

Easy.