and another one down

I've just finished reading "Object Thinking" by David West. Quite an interesting read. He proposes that the true intent of OO has been misinterpreted by many and that the true path will set you free...

If anyone else has read it, I'd love a chat about it.

another one down...

I just finished reading "Effective C#: 50 specific ways to improve your C#" by Bill Wagner. Definitely worth a read. Not too long, and each point is only several pages so you can just read a bit and put it away, read a bit and put it away, read a bit, and - you get the picture.

I've started Refactoring by Martin Fowler. Seems like another great book.

I really wish I'd started reading these much earlier in my career. Although I'm finding that a lot of what I'm reading I'd already picked up from other sources, but it's nice to read a comprehensive coverage of each topic.

more is more

We've recently had seven people join our team. We recently only had 5 full time developers in our team, so that's a big increase (sure, I could have worked it out as a percentage, but you can do that in your spare time).

The change has been great, I always like meeting new developers to get their perspective on how they approach their work.

It also gives us the chance to do stuff we've been too busy to do - like more pair programming.

Welcome to Richard, Michael, David, Kyle, Mark, Goran and Andrew.

less is more...

I've been reading/watching/thinking about this recently. Everyone's saying less code is better and I agree. The less code, the less chance for bugs, the less the program has to do and the less code paths makes the code more robust.

Now the art of writing less code is easy - understand exactly what is required and implement it the simplest way possible. Also, avoid duplication of code or functionality like the plague and you're on the way.

Get on board and write less!

swimming upstream

Anyone with experience (or knowledge, Mitch ) will know that the more time you spend on upstream tasks will pay large dividends further into the product cycle.

I know there's no easily identifiable point when you know you've done enough analysis and design, but it's better to overspend in this area then suffer the consequences later.

It's amazing how just one extra class or one decision can save hours (or weeks!) of work.

You're never going to get it completely right, as the details are never immediately obvious. But that's no excuse not to try.


Right now, I'm doing a bit of swimming upstream...

Object Orientated Design (OOD).

OK, I am a big fan of OOD. Why? Well, it makes your life easier. Yes, it can be a bit harder to understand and grasp what's actually going on, but the payoffs are immense. Once you get into the concepts, you really see how it's just logical.

If you want to know more, read http://blog.objectmentor.com/ArticleS.UncleBob.PrinciplesOfObjectOrientedDesign

Please.

Epiphany

Epiphany: the comprehension of the meaning of something through a sudden intuitive realization.

Had one just the other day.

It's strange. You read something and go "yeah, that's good." And you acknowledge that it's something that you "should" do, but you don't.

And then, some time later, you're discussing it with someone else, thinking about it in the shower or the realization just pops into your head from your subconscious. And you just suddenly get it. A total and utter understanding of WHY you should do it.

Wow.

best book ever

No, I'm not going to tell you that the best book ever is "The Davinci Code". It's good, but not that good.

What I am going to say is that the best book ever is "Code Complete 2" by Steve McConnell. If you're a developer (or even just someone involved in the whole IT industry), then please, do yourself a favour and read this book.

'Nuff Said.

Process, Process, Process

Sorry. I should have made this more obvious in my last post. I do think that process is important. Very important. I would have to say that I prefer Agile type processes to waterfall for a few reasons:
- it helps you identify progress and problems early and frequently
- it accepts what IS going to happen and embraces it (i.e. iterations)
- more team focused and skilling orientated.

That's not to say that you can't do all that in a waterfall project. Infact, I bet that the waterfall projects that are classified as successfull actually implemented those points, but not in a formal fashion.

wondering

There's so much talk around at the moment about how many projects are failing and the quality of the result when they do succeed.

The main thing that industry experts suggest is that the issue is the process. I.E. Waterfall projects tend to fail and XP projects do not.

Hmmm.....

salt and vinegar chips

Seems there's a new player in the almost full to bursting point salt and vinegar chips market. Arnott's have been advertising their "Tasty Jacks". They say that if you try them you'll never go back.

Well I did, and although they're pretty good, I'd say that they come in at #3 on my list. So what's my list? Glad you asked:

#1: Kettle Sea Salt and Basalmic Vinegar. Fantastic!
#2: Smiths Salt and Vinegar crisps. The thin slices really add to the enjoyment
#3: Arnotts Tasty Jacks Salt and Vinegar. Great attempt, but can't quite match the taste of #1 or #2.
#4: Smiths ridged Salt and Vinegar. Good regular chips.
#5: Pringles Salt and Vinegar. Ok.
#6: any other brand. No one really cares at this level.

I also have very fond memories of a chip called the BIG Salt and Vinegar. I think that they were only available in about 1985. Probably because the flavour was so strong and the chip so thick that several children were admitted to hospital with salt and vinegar flavour poisoning.

Anyway...

testing...

I used to always feel ashamed that I'd missed something when the testers came back with issues. I have now changed my mind.

Testers are experts in their area and I'm an expert in mine (I hope!). It's their role to check everything to ensure quality. Besides I should spent less (yes, less*) time testing and more time coding. I should not try to write code that will pass all possible tests (functionality, uat, random, etc) in the first instance. Almost all apps will fail testing to some degree in the first run. Why not accept this and move onto a smaller and more frequent develop/test cycle?

So now, I'm happy that the testers find things. It means that they're doing their job and I'm doing mine.

* Less time, but more effectively.

am I geek enough?

It's strange. I'm kind of in between being a full geek and not quite. I really like what I do and technology and stuff, but most nights I still like to sit in front of the telly and do absolutely nothing.

The guys I know who I would classify as Fully Geek (and that's a compliment) seem to spend every available moment researching something technically cool whether related to their employment or not.

I guess I haven't got what it takes to be Fully Geek. Maybe I could be just Mostly Geek...

hello

hi.

i've been thinking about starting a blog for a while now. in fact, some friends/colleagues think that i'm opinionated enough to have a talkback radio show. they're probably right.

i will probably not be a daily poster, but lets see...

i always like to ask people what they do for fun as an icebreaker, so i guess i'll start:
- i like to mountain bike
- i like to ride a unicycle (not well though)
- i like to juggle (again, not well)
- and for something completely different, i like to write code (c#.net) and think about things.

and you?